Yes, if the active-active multi-homing on a per L2VPN instance basis was desired in some cases, vendors could offer their proprietary schemes like Cisco’s VSS to support that capability. In this way, there is no need to introduce the complexity into the standard, especially on the data plane perspective, and therefore other NVEs (i.e., PE routers) which are not within any active-active redundancy group don’t need to afford that complexity anymore.
As for active-passive multi-homing, I fully agree with you that the active/passive multi-homing on a per physical interface or trunk interface basis is not welcomed. Hence we could achieve load-balancing among the physical interfaces or trunk interfaces which are connected to different NVEs of the same RG (redundancy group) on the basis of VLANs. For example, a dual-homed device (DHD) is multi-homed to NVE1 and NVE2 and it is configured with two VLANs (say VLAN x and y) on its physical NICs in a bond, NVE1’s corresponding interface is active for VLAN x while NVE2’s corresponding interface is active for VLAN y… Best regards, Xiaohu - 发件人: Jon Hudson [mailto:[email protected]] 发送时间: 2012年9月22日 17:16 收件人: Xuxiaohu 抄送: Aldrin Isaac; Lucy yong; Kireeti Kompella; [email protected] 主题: Re: [nvo3] Is the cost of supporting active-active multi-homing on a per L2VPN instance basis sustainable? If we don't do it as part of the standard, vendors will just implement proprietary versions. active/passive anything is not welcomed in the datacenter anymore On Sat, Sep 22, 2012 at 2:02 AM, Xuxiaohu <[email protected]<mailto:[email protected]>> wrote: Hi all, I strongly believe this is an very important question which needs more attentions and discussions. Hence I redefine the subject of the original email so as to avoid this email from being missed. Best regards, Xiaohu > -----邮件原件----- > 发件人: [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] 代表 > Xuxiaohu > 发送时间: 2012年9月21日 10:00 > 收件人: Aldrin Isaac; Lucy yong > 抄送: Kireeti Kompella; [email protected]<mailto:[email protected]> > 主题: [nvo3] 答复: draft-drake-nvo3-evpn-control-plane > > > > > -----邮件原件----- > > 发件人: [email protected]<mailto:[email protected]> > > [mailto:[email protected]<mailto:[email protected]>] 代表 > Aldrin > > Isaac > > 发送时间: 2012年9月19日 5:24 > > 收件人: Lucy yong > > 抄送: Kireeti Kompella; [email protected]<mailto:[email protected]> > > 主题: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > The imported E-VPN route will determine what the next hop entry in the > > EVI will look like -- whether it will have encapsulation A or > > encapsulation B. That is determined by the sender of the E-VPN route. > > This is like having a PPP interface and an Ethernet interface > > connected to the same VRF. > > > > Ideally the other encapsulations would have included support for > > multi-homing by including an additional field for a split-horizon ID > > for use by control-planes and NVE that support multi-homing. Maybe > > it's not too late to add an SH field to these encapsulations since it > > seems that there is some unused bits in nvGRE (maybe not enough) and > > in VXLAN -- just a thought. > > If the SH field is just intended for supporting active-active multi-homing on > a per > VPN instance basis, I suggest it'd better for us to seriously evaluate whether > the cost for realizing that goal is worthwhile since that will make the > solution > itself, especially the data plane process, much more complex. In the > multi-tenant cloud data center environment, isn't it good enough in practice > to > support active-standby multi-homing on a per VPN instance basis while > supporting active-active multi-homing on a per physical interface basis? For > instance, a physical server containing two VMs (say VM1 and VM2) which > belong to different VPN instances respectively is dual-homed to two NVEs (say > NVE1 and NVE2), NVE1 is the active NVE for VM1 and the standby NVE for VM2 > while NVE2 is the active NVE for VM2 and the standby NVE for VM1. > > Best regards, > Xiaohu > > > On Tue, Sep 18, 2012 at 4:18 PM, Lucy yong > > <[email protected]<mailto:[email protected]>> wrote: > > > Hi Kreeti, > > > > > > Regarding interworking capability, Is "a given EVI can support multiple > > > data > > plane encapsulation" equivalent to say "individual NVEs need to support > > multiple encapsulation schemas"? If one NVE only supports VXLAN and > another > > NVE only supports MPLS-in-GRE, two will not able to work in a same EVI, is > that > > right? Will this give more benefit than having one encapsulation in an EVI > > or > > make more complex? > > > > > > Regards, > > > Lucy > > > > > > -----Original Message----- > > > From: Kireeti Kompella > > > [mailto:[email protected]<mailto:[email protected]>] > > > Sent: Monday, September 17, 2012 8:18 PM > > > To: Lucy yong > > > Cc: [email protected]<mailto:[email protected]> > > > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > Hi Lucy, > > > > > > On Sep 17, 2012, at 3:36 PM, Lucy yong > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > >> Read this draft. > > >> > > >> RFC5512 applies a case where two BGP speakers are in a BGP free core. > > Using encapsulation tunnel between two speakers enables one speaker to > send > > a packet to another speaker as the next-hop. > > >> > > >> Using this approach in nvo3 may rise a high scalability concern because > any > > pair of NVEs in an NVO will need to maintain a state for the tunnel > > encapsulation. > > > > > > They would have to in any case. The tunnel encap is a couple of bits; the > > "tenant id" is also needed. > > > > > >> If some NVEs support VXLAN and some support NVGRE, to build mcast > tree > > for BUM, it has to build two distinct sub-trees for each, which is more > complex. > > >> > > >> "This memo specifies that an egress PE must use the sender MAC > > >> address to determine whether to send a received Broadcast or > > >> Multicast packet to a given Ethernet Segment. I.e., if the sender > > >> MAC address is associated with a given Ethernet Segment, the egress > > >> PE must not send the packet to that Ethernet Segment." > > >> > > >> Does it mean using BGP to exchange NVE MAC address that belong to an > > Ethernet segment first? How does this impact other evpn features? > > > > > > Yes to the first question; not at all (imo) to the second. > > > > > >> This needs to be cooked more. > > > > > > I think it's pretty well cooked, although I must confess a predilection > > > for > sushi. > > In effect, these very capable authors saved me the trouble of writing pretty > > much the same draft :-) > > > > > > The only thing I would change is the draft name: I prefer > > "...-nvo3-l2-in-l3-control-plane". Oh, and add a code point for STT :-) > > > > > > Kireeti > > > > > >> Cheers, > > >> Lucy > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: [email protected]<mailto:[email protected]> > > >> [mailto:[email protected]<mailto:[email protected]>] On Behalf > Of > > Aldrin Isaac > > >> Sent: Monday, September 17, 2012 2:18 PM > > >> To: Stiliadis, Dimitrios (Dimitri) > > >> Cc: Thomas Nadeau; [email protected]<mailto:[email protected]> > > >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > >> > > >> I'm not sure that the dust has fully settled on the matter. > > >> http://tools.ietf.org/html/draft-marques-l3vpn-end-system-07 suggests > > >> the use of XMPP. The question is whether there is any sound technical > > >> reason (versus preferences) why leveraging BGP is problematic. I > > >> personally haven't heard a convincing argument. > > >> > > >> On Mon, Sep 17, 2012 at 12:11 PM, Stiliadis, Dimitrios (Dimitri) > > >> <[email protected]<mailto:[email protected]>> > > >> wrote: > > >>> May be I missing something here .. but does this suggest running > > BGP-EVPN > > >>> on the NVE > > >>> that is located in the hypervisor? > > >>> > > >>> Dimitri > > >>> > > >>> On 9/17/12 8:55 AM, "Thomas Nadeau" > > >>> <[email protected]<mailto:[email protected]>> > > wrote: > > >>> > > >>>> > > >>>> A number of us just published this draft and wanted to bring it to > > the > > >>>> NVO3 WG's attention. We will be presenting/discussing this draft at > the > > >>>> interim meeting this week as well, but please discuss here on the list > > >>>> as > > >>>> well. > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Tom, John, et al > > >>>> > > >>>> > > >>>> A new version of I-D, draft-drake-nvo3-evpn-control-plane-00.txt > > >>>> has been successfully submitted by Thomas D. Nadeau and posted to > the > > >>>> IETF repository. > > >>>> > > >>>> Filename: draft-drake-nvo3-evpn-control-plane > > >>>> Revision: 00 > > >>>> Title: A Control Plane for Network Virtualized Overlays > > >>>> Creation date: 2012-09-16 > > >>>> WG ID: Individual Submission > > >>>> Number of pages: 12 > > >>>> URL: > > >>>> > > http://www.ietf.org/internet-drafts/draft-drake-nvo3-evpn-control-plane-00 > > >>>> .txt > > >>>> Status: > > >>>> http://datatracker.ietf.org/doc/draft-drake-nvo3-evpn-control-plane > > >>>> Htmlized: > > >>>> http://tools.ietf.org/html/draft-drake-nvo3-evpn-control-plane-00 > > >>>> > > >>>> > > >>>> Abstract: > > >>>> The purpose of this document is to describe how Ethernet Virtual > > >>>> Private Network (E-VPN) can be used as the control plane for > > >>>> Network Virtual Overlays. Currently this protocol is defined to > > >>>> act as the control plane for Virtual Extensible Local Area > > >>>> Network (VXLAN), Network Virtualization using Generic Routing > > >>>> Encapsulation (NVGRE), MPLS or VLANs while maintaining their > > >>>> existing data plane encapsulations. The intent is that this > > >>>> protocol will be capable of extensions in the future to handle > > >>>> additinal data plane encapsulations and functions as needed. > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> nvo3 mailing list > > >>>> [email protected]<mailto:[email protected]> > > >>>> https://www.ietf.org/mailman/listinfo/nvo3 > > >>> > > >>> _______________________________________________ > > >>> nvo3 mailing list > > >>> [email protected]<mailto:[email protected]> > > >>> https://www.ietf.org/mailman/listinfo/nvo3 > > >> _______________________________________________ > > >> nvo3 mailing list > > >> [email protected]<mailto:[email protected]> > > >> https://www.ietf.org/mailman/listinfo/nvo3 > > >> _______________________________________________ > > >> nvo3 mailing list > > >> [email protected]<mailto:[email protected]> > > >> https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > _______________________________________________ > > > nvo3 mailing list > > > [email protected]<mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > > nvo3 mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 -- "Do not lie. And do not do what you hate."
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
