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. On Sep 19, 2012, at 8:40 PM, "Balus, Florin Stelian (Florin)" <[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 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
