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
