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
