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]> 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]] 代表 > > Xuxiaohu > > 发送时间: 2012年9月21日 10:00 > > 收件人: Aldrin Isaac; Lucy yong > > 抄送: Kireeti Kompella; [email protected] > > 主题: [nvo3] 答复: draft-drake-nvo3-evpn-control-plane > > > > > > > > > -----邮件原件----- > > > 发件人: [email protected] [mailto:[email protected]] 代表 > > Aldrin > > > Isaac > > > 发送时间: 2012年9月19日 5:24 > > > 收件人: Lucy yong > > > 抄送: Kireeti Kompella; [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]> > 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]] > > > > Sent: Monday, September 17, 2012 8:18 PM > > > > To: Lucy yong > > > > Cc: [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]> 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]] On > Behalf > > Of > > > Aldrin Isaac > > > >> Sent: Monday, September 17, 2012 2:18 PM > > > >> To: Stiliadis, Dimitrios (Dimitri) > > > >> Cc: Thomas Nadeau; [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-07suggests > > > >> 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]> 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]> > > > 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] > > > >>>> 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 > > > _______________________________________________ > > > 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 > -- "Do not lie. And do not do what you hate."
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
