Cloud operators might require gateways to enter and exit from outside -- however, let's consider how operators (raising my hand here) can build internal networks without different closed "encapsulation domains" which would result in meet-me choke-points and the complexity of stitching these together.
On Sep 20, 2012, at 3:39 AM, Stiliadis, Dimitrios (Dimitri) wrote: > +1 > > Even when public clouds are build with only one encap, they will have to > support > interoperability with multiple enterprise clouds that will use their own > encaps > since they use different virtualization stacks. Translations are > unavoidable. > > On 9/19/12 9:12 PM, "Jon Hudson" <[email protected]> wrote: > >> 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 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
