Ivan, See in-line... > -----Original Message----- > From: Ivan Pepelnjak [mailto:[email protected]] > Sent: Tuesday, September 04, 2012 12:03 PM > To: Balus, Florin Stelian (Florin) > Cc: Somesh Gupta; [email protected] > Subject: Re: [nvo3] Support for multi-homed NVEs > > A) Not per prefix (at least not without serious amount of end-to-end > BGP multipathing+BGP AddPath or multiple RDs) > > B) There's no liveliness check in *VPN (apart from LISP) [FB>] How are the VPN specifications (IP VPN, VPLS, VPWS or incoming EVPN) connected to LISP? Also can you be more specific on the absence of liveliness check in *VPN. Are you talking about a certain deployment/implementation environment? Thanks, Florin
> > In MPLS/VPN we rely on the host route to PE loopback and/or LSP to the > /32 prefix to indicate next hop validity. That won't work for > hypervisor-based NVEs > > On 9/4/12 8:00 PM, Balus, Florin Stelian (Florin) wrote: > > AFAIK the text in NVO3 framework and requirements drafts allows > multiple IPs per NVE. We have multiple IPs per PE in current VPN > implementations. This is an implementation matter though in my opinion. > > > >> -----Original Message----- > >> From: Somesh Gupta [mailto:[email protected]] > >> Sent: Tuesday, September 04, 2012 10:51 AM > >> To: Ivan Pepelnjak; Balus, Florin Stelian (Florin) > >> Cc: [email protected] > >> Subject: RE: [nvo3] Support for multi-homed NVEs > >> > >> Florin, > >> > >> Regarding the multi-homing, my assumption is that the NVE in the > >> hypervisor would not (want to) run a routing protocol. So as Ivan > >> points out, the standard would need to accommodate multiple IP > >> addresses per NVE. > >> > >> Somesh > >> > >>> -----Original Message----- > >>> From: Ivan Pepelnjak [mailto:[email protected]] > >>> Sent: Tuesday, September 04, 2012 9:58 AM > >>> To: Balus, Florin Stelian (Florin) > >>> Cc: Somesh Gupta; [email protected] > >>> Subject: Re: [nvo3] Support for multi-homed NVEs > >>> > >>> Ah, that other can of worms ;) Mine was simpler. > >>> > >>> On the underlay side, we might decide that NVEs have a single IP > >>> address or multiple IP addresses (like some NVGRE load balancing > >>> proposals). If we decide NVEs have a single IP address (potential > >>> per virtual network segment), then the rest is implementation > >>> details > >> (and > >>> we're back to MLAG/SMLT land for true redundancy). Alternatively we > >>> might implement the option of having multiple IP addresses per NVE, > >>> and the NVEs might use the IP-address-per-link option (thus no need > >>> for L2 or MLAG at all). > >>> > >>> On the overlay side, the real problem (as you stated) is the > >>> multi-homing of NVO3-to-legacy gateways. I don't see any other need > >>> for overlay NVE multihoming. > >>> > >>> BTW, Nicira has nicely solved the NVO3 gateway multihoming - the > >> whole > >>> NVO3 network works exactly like VMware's vSwitch: split horizon > >>> bridging (thus no forwarding loops through NVO3), with every VM MAC > >>> address being dynamically assigned to one of the gateways, which > >>> also solves the return path issues (dynamic MAC learning in legacy > >>> network takes care of that). Maybe we should just use the wheel > that > >>> has already been invented? > >>> > >>> Kind regards, > >>> Ivan > >>> > >>> On 9/4/12 6:45 PM, Balus, Florin Stelian (Florin) wrote: > >>>> I understand the discussion below is about the NVE multi-homing > >>> towards the IP core, on the tunnel side. > >>>> We did not focus in the framework draft on the core redundancy as > >> in > >>> our opinion there was no need to standardize anything here. There > >>> are no differences from what is available today in regular IP > networks: > >> if > >>> NVEs are multi-homed directly to the next IP router, regular > routing > >>> will take care of it. If there is Ethernet switching in between NVE > >>> and the next IP hop, L2 resiliency mechanisms need to be employed. > >>> From what I read below it looks more of an implementation > >>> discussion than a standardization requirement. Am I right? > >>>> By Multi-homed NVEs one can also understand a set of NVEs > >>>> multi-homed > >>> on the access side to other devices. That is a discussion we need > to > >>> have in my opinion. An use case example: NVO3 network - NVE GWs > >> multi- > >>> homed to external non-NVO3 networks. Handoff can be VLANs, VPLS > PWs, > >>> or BGP EVPN labels... > >>>> I think the latter is worth discussing although there are some > >>> mechanisms and some standardization initiatives in place already. > >>>> > >>>>> -----Original Message----- > >>>>> From: [email protected] [mailto:[email protected]] On > >>>>> Behalf > >>> Of > >>>>> Ivan Pepelnjak > >>>>> Sent: Friday, August 31, 2012 12:23 AM > >>>>> To: 'Somesh Gupta'; [email protected] > >>>>> Subject: Re: [nvo3] Support for multi-homed NVEs > >>>>> > >>>>> This is definitely an interesting can of worms ;) > >>>>> > >>>>> While I don't think we should go down the path of IP-A/IP-B > >>>>> networks similar to some other DC technology, we will face the > >>>>> reality of > >>> some > >>>>> NVE elements (hypervisor soft switches) not being underlay IP > >>> routers. > >>>>> We could either: > >>>>> > >>>>> (A) ignore the issue and expect the network designer to solve it > >>> using > >>>>> any one of the existing NIC teaming/MLAG kludges while retaining > a > >>>>> single encapsulation IP address per NVE; > >>>>> > >>>>> (B) provide support for multiple encapsulation addresses per NVE > >> so > >>> a > >>>>> multi-homed NVE could have one IP address per physical interface > >>>>> and send and receive nvo3-encapsulated frames using more than one > >>> address. > >>>>> Option (A) is the easy way out similar to existing MPLS/VPN > >>>>> behavior and would fit well with existing DC deployments. It > would > >>>>> also > >>> retain > >>>>> all the server-to-ToR multihoming complexity. > >>>>> > >>>>> Option (B) would reduce the complexity of the underlay DC network > >>>>> (which would become a simple L3 network with single-homed IP > >>>>> addresses), but we'd have to deal with a bunch of additional > >>> problems > >>>>> (peer IP address liveliness check). > >>>>> > >>>>> Just speculating ... > >>>>> Ivan > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [email protected] [mailto:[email protected]] On > >>> Behalf > >>>>>> Of Somesh Gupta > >>>>>> Sent: Friday, August 31, 2012 6:58 AM > >>>>>> To: [email protected] > >>>>>> Subject: [nvo3] Support for multi-homed NVEs > >>>>>> > >>>>>> I did not see any mention of multi-homed NVEs in draft-lasserre- > >>> nvo3- > >>>>>> framework-03.txt. NVEs are connected together by an L3 network - > >>> does > >>>>>> that mean only one? > >>>>>> Can it be multi-homes to two L3 networks? > >>>>>> > >>>>>> Somesh > >>>>>> _______________________________________________ > >>>>>> nvo3 mailing list > >>>>>> [email protected] > >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 > >>>>> _______________________________________________ > >>>>> nvo3 mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
