It's on my list. Yours irrespectively,
John > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Thursday, September 20, 2012 7:22 AM > To: John E Drake; Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > John, > > See below. > > -----Original Message----- > From: John E Drake [mailto:[email protected]] > Sent: Thursday, September 20, 2012 7:57 AM > To: Lucy yong; Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > Lucy, > > 1) & 2) are correct. 3) does not apply because we are stipulating that > that encapsulation selection (nee interworking) requires that every PE > in a given EVI needs to support all of the encapsulations used by each > of the PEs in that EVI. > > As others have pointed out, in practice a given EVI will only use one > or two encapsulations and supporting multiple encapsulations does not > appear to be particularly onerous. > [[LY]] So some description in the draft need to be revised or > clarified. > > Yours irrespectively, > > John > > > > -----Original Message----- > > From: Lucy yong [mailto:[email protected]] > > Sent: Thursday, September 20, 2012 5:38 AM > > To: John E Drake; Lucy yong; Thomas Nadeau > > Cc: Kireeti Kompella; [email protected] > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > 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
