Lucy, What exactly do you mean by 'mp2mp' and why do you think it is needed in this context?
Yours irrespectively, John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Lucy yong > Sent: Wednesday, September 19, 2012 6:56 AM > To: Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > Tom, > > I am not auguring if NVO3 should support different data encapsulations. > I question that the proposed solution is proper in a mp2mp situation. > Using a gateway for this case is much simpler, which can still be done > in a single control plane. > > However, in NVO3, encapsulation is done at NVE not end system, right? I > don't know the intention of your second sentence. > > Lucy > > -----Original Message----- > From: Thomas Nadeau [mailto:[email protected]] > Sent: Tuesday, September 18, 2012 6:10 PM > To: Lucy yong > Cc: Kireeti Kompella; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > There is definitely a requirement to do different encapsulations > simultaneously. There is even support coming from NIC vendors to > support multiple VMs with different encapsulations at the same time. > > --Tom > > On Sep 18, 2012:1:18 PM, at 1: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-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]> 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
