That is what we've been saying all along: with this approach you have
more flexibility to handle all of the use cases.
--Tom
On 9/26/12 6:03 PM, "Aldrin Isaac" <[email protected]> wrote:
>A globally significant data plane VNID is lobotomized -- it can only
>support one topology (i.e. full mesh) out of the gate and forever.
>E-VPN allows the VNID to be globally significant or simply used as a
>local context ID selected by the NVE. This allows the operator to be
>more expressive with VN topology. The actual MPLS label is 24 bits
>long -- I don't see any reason (not knowing pre-existing hw/sw
>limitations) why we couldn't just use all 24 bits of it as Kireeti
>suggested many emails ago.
>
>On Wed, Sep 26, 2012 at 2:10 PM, Sunny Rajagopalan
><[email protected]> wrote:
>> Hi, Kireeti, Aldrin
>> The MPLS label was originally meant to identify a link, and got
>>overridden
>> in rfc4364 as a _local_ identifier of VPNs and has now further morphed
>>in
>> draft-drake-nvo3-evpn-control-plane to be a _global_ identifier of VPNs
>>to
>> accommodate the VNID. As a semantic conservative, this drift worries
>>me. :-)
>> The RD is meant to distinguish between routes, just like the VNID is
>>meant
>> to distinguish between routes from different tenants. If using a type 0
>> bothers RD purists, maybe we could define a new type for it? The VNID is
>> typically administratively assigned, just like the RD. It's true that
>>the RD
>> has never been seen before on the wire, but the VNID has already broken
>>that
>> taboo. It's time to call the VNID what it really is - an RD.
>>
>> Semantic arguments aside, the chief reason I preferred using the RD
>>instead
>> of the MPLS label is that it would allow us to encode the complete 24
>>bit
>> VNID in the BGP route, instead of truncating it to 20 bits to fit
>>inside the
>> MPLS label field.
>>
>> --
>> Sunny
>>
>>
>>
>>
>> From: Kireeti Kompella <[email protected]>
>> To: Aldrin Isaac <[email protected]>,
>> Cc: Sunny Rajagopalan/Santa Clara/IBM@IBMUS, "[email protected]"
>> <[email protected]>, "[email protected]" <[email protected]>,
>>"[email protected]"
>> <[email protected]>, "[email protected]" <[email protected]>,
>> "[email protected]" <[email protected]>,
>> "[email protected]" <[email protected]>, "[email protected]"
>> <[email protected]>, "[email protected]"
>> <[email protected]>, "[email protected]" <[email protected]>
>> Date: 09/26/2012 09:39 AM
>> Subject: Re: [nvo3] comments on
>>draft-drake-nvo3-evpn-control-plane
>> ________________________________
>>
>>
>>
>> Thanks, Aldrin!
>>
>> More inline.
>>
>> On Sep 25, 2012, at 21:23, Aldrin Isaac <[email protected]> wrote:
>>
>>>> 1) I would suggest *not* altering the semantics of the MPLS label in
>>>>the
>>>> BGP
>>>> route.
>>
>> Note that no one is suggesting altering the semantics of an MPLS label.
>> What's proposed is altering the interpretation of a three-byte field in
>>the
>> NLRI.
>>
>>>> Instead, use the route distinguisher to carry the 24-bit VNID (this
>>>> is arguably better since the semantics of the RD align better with the
>>>> semantics of the VNID). I would suggest encoding this as a type 0 RD,
>>>> with
>>>> the VNID going into the Assigned number sub-field. In addition, call
>>>>out
>>>> that an MPLS label value of 0 in the BGP route is a valid value, and
>>>>will
>>>> be
>>>> used by PEs which do not support MPLS encap.
>>>
>>> The RD was not intended to be used to signal data plane bits. That's
>>> what the label field is for.
>>
>> Exactly. Worse than that, the RD is responsible for _distinguishing_
>>routes.
>> If VNIDs are locally generated (an option well worth holding on to), all
>> manner of hell will break loose.
>>
>> Kireeti
>>
>>
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
