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
