I think multiple IPs per NVE will have to show up in the solution - we can wait and see.
> -----Original Message----- > From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel- > lucent.com] > Sent: Tuesday, September 04, 2012 11:00 AM > To: Somesh Gupta; Ivan Pepelnjak > Cc: [email protected] > Subject: RE: [nvo3] Support for multi-homed NVEs > > 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
