John and Tom, Yes, your answer is more precisely.
Then I question which following is the purpose of this draft? 1) to allow evpn control plane supporting all data plane encapsulations that nvo3 has to support 2) because all NVEs can support a set of data plane encapsulations, an egress NVE can use evpn control plane to tell other ingress NVEs which encapsulation they should use to send packets. 3) Since some NVEs may support one type data plane encapsulation and others may support another only, evpn control plane can make them interwork together. I know there are several proposals on data plane encapsulation for nvo3, is there a requirement to support all of them in nvo3? Lucy Please let me know your -----Original Message----- From: John E Drake [mailto:[email protected]] Sent: Wednesday, September 19, 2012 9:33 AM To: Lucy yong; Thomas Nadeau Cc: Kireeti Kompella; [email protected] Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane Lucy, Or more precisely, all eight PEs each have to support all three encapsulations. As Aldrin points out this is the same as having PPP and Ethernet encapsulations in the same VRF. Also, as Tom points out, this is a capability that NIC vendors are designing into their products. Yours irrespectively, John > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 7:18 AM > To: John E Drake; Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > John, > > First of all, I mean to say that the proposed solution is not proper in > a mp2mp solution in the reply to Tom. This is my mistake. > > If one egress PE supports NVGRE, one support VXLAN, and one support > MPLS-GRE, then five ingress PEs that need to have tunnels to all three > egress PEs will all need to support 3 encapsulation. > > Using a gateway interwork with different data plane is better on this. > > Lucy > > > > > > > > -----Original Message----- > From: John E Drake [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 9:05 AM > To: Lucy yong; Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > 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
