That seems to hit the nail on the head. I don't think we want to deal
with inter-working in the classic sense.
--Tom
On Sep 20, 2012:3:12 AM, at 3:12 AM, John E Drake <[email protected]> wrote:
> I had an offline discussion with Joel and he suggests using the term
> 'encapsulation selection' rather than 'interworking'
>
> Yours irrespectively,
>
> John
>
>> -----Original Message-----
>> From: Kireeti Kompella [mailto:[email protected]]
>> Sent: Wednesday, September 19, 2012 5:47 PM
>> To: Thomas Nadeau
>> Cc: Kireeti Kompella; Balus, Florin Stelian (Florin); John E Drake;
>> Joel M. Halpern; [email protected]
>> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane
>>
>> Hi Tom,
>>
>> On Sep 19, 2012, at 4:17 PM, Thomas Nadeau <[email protected]>
>> wrote:
>>
>>>
>>> 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 so that is
>> unlikely to happen in the wild. 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.
>>
>> As I've said, I like this draft. However, "interworking" is fraught
>> with misinterpretations and pitfalls, and perhaps at this stage
>> distracts from other more pressing concerns.
>>
>> Might I suggest the following reworking of Section 4:
>>
>> 4. Multiple Encapsulations
>>
>> The Tunnel Encapsulation attribute enables a single control plane
>> to oversee a number of different data plane encapsulations. This
>> can
>> manifest itself in several ways:
>>
>> a) a data center may use a single common encapsulation for all
>> EVIs, but
>> different data centers may make independent choices.
>> b) within a single data center, a given EVI may use a single
>> encapsulation, but different EVIs may choose different
>> encapsulations.
>> c) a single EVI may use multiple encapsulations, one for each PE-PE
>> pair,
>> and maybe even use a different encapsulation in each
>> direction.
>>
>> Going from (a) to (c ) increases generality, but also increases
>> complexity.
>> The initial focus will be on (a) and (b); further details for (c )
>> will be added if
>> there is sufficient interest.
>>
>> In all cases, a PE within a given EVI knows which encapsulations
>> other
>> PEs in that EVI support, and, when sending unicast traffic, it MUST
>> choose
>> one of the encapsulations advertised by the egress PE.
>>
>> For case (c ), an ingress PE that uses shared multicast trees for
>> sending
>> Broadcast and Multicast traffic must maintain distinct trees for
>> each
>> different encapsulation type. Further details will be given in a
>> future version.
>>
>> The topic of interworking encapsulations and "gateway" functions
>> will also be
>> addressed in a future version.
>>
>>
>>
>> Kireeti.
>>
>>> --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
