> -----Original Message----- > From: Thomas Nadeau [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 4:18 PM > To: Balus, Florin Stelian (Florin) > Cc: John E Drake; Joel M. Halpern; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > 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
[FB>] Agreed there are not too many NVO3 DCs today let alone with multiple encapsulations. > so that is > unlikely to happen in the wild. [FB>] If we talked about the future a combination of two encapsulations could be very likely in my opinion: regular EVPN and one of the VXLAN/NVGRE at the NVE GW. > 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. [FB>] Definitely the case of multiple encaps needs to be addressed even if it is just for the mis-configuration case. > > --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
