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
