Sorry. Please neglect the following email since it just talks about how to facilitate the load-balancing of DCVPN traffic in the core by using multiple tunnel destination addresses in the case where NVEs/PEs run some routing protocol with P routers.
Xiaohu > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Xuxiaohu > 发送时间: 2012年9月5日 10:04 > 收件人: Somesh Gupta; Balus, Florin Stelian (Florin); Ivan Pepelnjak > 抄送: [email protected] > 主题: Re: [nvo3] Support for multi-homed NVEs > > Totally agree. > > For those DCVPN approaches which use BGP as a control plane protocol (e.g., > BGP/MPLS IP VPN), the mechanism defined in this draft > ( http://tools.ietf.org/html/draft-xu-idr-tunnel-address-prefix-01) can be > used > to advertise multiple IP addresses per NVE/PE automatically. For those DCVPN > approaches which use IS-IS as a control plane protocol, an IS-IS TLV extension > can be used to advertise multiple IP addresses per NVE/PE as well, as has been > mentioned in a previous email > (http://www.ietf.org/mail-archive/web/nvo3/current/msg01346.html). > > Best regards, > Xiaohu > > > -----邮件原件----- > > 发件人: [email protected] [mailto:[email protected]] 代表 > > Somesh Gupta > > 发送时间: 2012年9月5日 7:45 > > 收件人: Balus, Florin Stelian (Florin); Ivan Pepelnjak > > 抄送: [email protected] > > 主题: Re: [nvo3] Support for multi-homed NVEs > > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
