Tom, I am point out the consequences and suggest if DC operators can help push a better choice.
Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Nadeau Sent: Tuesday, September 25, 2012 9:33 AM To: Lucy yong; Aldrin Isaac; Stiliadis, Dimitrios (Dimitri) Cc: Thomas Nadeau; John E Drake; [email protected]; Balus, Florin Stelian (Florin); Joel M. Halpern; Jon Hudson Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane On 9/24/12 1:11 PM, "Lucy yong" <[email protected]> wrote: >Hi Aldrin, > >Either a single standard encapsulation or all devices MUST supporting all >the encapsulations will give what you want. The latter will be more cost >for the vendors, which will convert to operator cost later. In addition, >it makes an analysis tool more complex. Both ways need standard effort to >make vendor devices interwork. > >The basic question here is: is there any technical reason to require a >device to support a set of standard encapsulations? If not, could DC >operators help push a single standard encapsulation in IETF standard >instead of approaching a solution that requires a device to support all >the encapsulations. Lucy, Need I point out that Aldrin IS one of those "DC operators" you are referring to and IS providing this input? --Tom > > >Regards, >Lucy > > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Aldrin Isaac >Sent: Saturday, September 22, 2012 8:14 AM >To: Stiliadis, Dimitrios (Dimitri) >Cc: Thomas Nadeau; John E Drake; [email protected]; Balus, Florin Stelian >(Florin); Joel M. Halpern; Jon Hudson >Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > >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 >_______________________________________________ >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
