Aldrin, You are DC operator. It is best for you to answer the questions. IP/MPLS VPN in WANs mainly use LSP tunnels although GRE tunnel is standardized, but rarely deployed as far as I know. (I may be wrong, which some SP operator clarify it).
Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Aldrin Isaac Sent: Tuesday, September 25, 2012 11:07 AM To: Lucy yong Cc: John E Drake; Thomas Nadeau; [email protected]; Thomas Nadeau; Balus, Florin Stelian (Florin); Stiliadis, Dimitrios (Dimitri); Joel M. Halpern; Jon Hudson Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane Is it true that today's DC-grade ToR silicon support MPLS over UDP or GRE? Are there examples of silicon that does not support this? On Tue, Sep 25, 2012 at 10:45 AM, Lucy yong <[email protected]> wrote: > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
