Jon, > However it is very common to see multiple hypervisors in use (esx, > hyper-v, xen, kvm) > > People will choose the hypervisors first, then choose from available > supported encapsulation methods. > > And while we could see those four end up using the same encapsulation > method I think is more likely that at least two will remain from > the pack of VXLAN/NVGRE/STT and now DOVE. > > We must also keep in mind that while the "public cloud" providers > may make more logical measure choices, all the "private cloud" shops > will be wanting to build overlays between the two. Encapsulation > choices may end up being more fragmented in the private space.
Does it mean that all of these encapsulation choices should become IETF Standard ? Yakov. > > On Sep 19, 2012, at 8:40 PM, "Balus, Florin Stelian (Florin)" <florin.balu [email protected]> wrote: > > > > > > >> -----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 multip le 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 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
