Agreed. It may be a practical matter for entropy over older devices (depending on the encap) which is likely a requirement.
Peter On Sep 4, 2012, at 7:45 PM, "Somesh Gupta" <[email protected]> wrote: > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
