I had an offline discussion with Joel and he suggests using the term 'encapsulation selection' rather than 'interworking'
Yours irrespectively, John > -----Original Message----- > From: Kireeti Kompella [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 5:47 PM > To: Thomas Nadeau > Cc: Kireeti Kompella; Balus, Florin Stelian (Florin); John E Drake; > Joel M. Halpern; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > Hi Tom, > > On Sep 19, 2012, at 4:17 PM, Thomas Nadeau <[email protected]> > wrote: > > > > > On Sep 19, 2012:11:28 AM, at 11:28 AM, "Balus, Florin Stelian > (Florin)" <[email protected]> wrote: > > > >> John, > >> I think more details need to be added here. What happens if one PE > advertises nvgre encap while the other advertises only vxlan? Do you > allow asymmetric encapsulations? > >> What if one NVE supports all 3 which one is chosen, advertised? Just > a few examples.... > > > > That is just not how data centers are built today so that is > unlikely to happen in the wild. With that in mind, this is an > interesting corner case that we should handle just in case something is > misconfigured or someone in the future decides to build such a DC. > > As I've said, I like this draft. However, "interworking" is fraught > with misinterpretations and pitfalls, and perhaps at this stage > distracts from other more pressing concerns. > > Might I suggest the following reworking of Section 4: > > 4. Multiple Encapsulations > > The Tunnel Encapsulation attribute enables a single control plane > to oversee a number of different data plane encapsulations. This > can > manifest itself in several ways: > > a) a data center may use a single common encapsulation for all > EVIs, but > different data centers may make independent choices. > b) within a single data center, a given EVI may use a single > encapsulation, but different EVIs may choose different > encapsulations. > c) a single EVI may use multiple encapsulations, one for each PE-PE > pair, > and maybe even use a different encapsulation in each > direction. > > Going from (a) to (c ) increases generality, but also increases > complexity. > The initial focus will be on (a) and (b); further details for (c ) > will be added if > there is sufficient interest. > > In all cases, a PE within a given EVI knows which encapsulations > other > PEs in that EVI support, and, when sending unicast traffic, it MUST > choose > one of the encapsulations advertised by the egress PE. > > For case (c ), an ingress PE that uses shared multicast trees for > sending > Broadcast and Multicast traffic must maintain distinct trees for > each > different encapsulation type. Further details will be given in a > future version. > > The topic of interworking encapsulations and "gateway" functions > will also be > addressed in a future version. > > > > Kireeti. > > > --Tom > > > > > >> Thanks, > >> Florin > >> > >> On Sep 19, 2012, at 9:04 AM, John E Drake <[email protected]> > wrote: > >> > >>> Joel, > >>> > >>> From section 4, the section you referenced in your note below: > >>> > >>> "Note that an ingress PE must use the data plane encapsulation > specified by a given egress PE in the subject MAC Advertisement or Per > EVI Ethernet AD route when sending a packet to that PE. Further, an > ingress node that uses shared multicast trees for sending Broadcast and > Multicast traffic must maintain distinct trees for each different > encapsulation type." > >>> > >>> Aldrin also recast this into English in his reply to Lucy: > >>> > >>> "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." > >>> > >>> Yours irrespectively, > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:[email protected]] > >>>> Sent: Wednesday, September 19, 2012 6:52 AM > >>>> To: John E Drake > >>>> Cc: [email protected] > >>>> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > >>>> > >>>> Looking at the draft, there seems to be a very reasonable question > >>>> about section 4. The text starts by noting that the presence of > >>>> the Tunnel Encapsulation attribute allows for supporting a range > of > >>>> tunnel encapsulations. Sounds good. It then asserts that this > >>>> allows interoperability across the encapsualtions. That does not > >>>> seem to follow. > >>>> > >>>> Normally, when we allow multiple encpsulations, we specify one as > >>>> mandatory to implement in order to enable interoperability of the > >>>> devices. > >>>> Communicating the encapsulation type does not magically enable a > >>>> device that uses one encapsulation to communicate with a device > >>>> that only supports some other encapsualtion. > >>>> > >>>> I presume that there are steps missing in section 4. Could you > >>>> elaborate? > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 9/19/2012 4:11 AM, John E Drake wrote: > >>>>> Lucy, > >>>>> > >>>>> Why didn't you ask your question of the authors? I had taken it > >>>>> as a > >>>> given that the capability to have an EVI spanning MPLS, VXLAN, and > >>>> NVGRE endpoints was a given. If the network operator does not > want > >>>> to deploy this capability, that is their option. > >>>>> > >>>>> Yours irrespectively, > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [email protected] [mailto:[email protected]] On > >>>>>> Behalf Of Lucy yong > >>>>>> Sent: Tuesday, September 18, 2012 1:19 PM > >>>>>> To: Kireeti Kompella > >>>>>> Cc: [email protected] > >>>>>> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > >>>>>> > >>>>>> 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- > >>>>>> pl > >>>>>>>>> ane-00 > >>>>>>>>> .txt > >>>>>>>>> Status: > >>>>>>>>> http://datatracker.ietf.org/doc/draft-drake-nvo3-evpn- > control- > >>>> plan > >>>>>>>>> e > >>>>>>>>> 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 > >> > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
