Hi Sunny, On Sep 26, 2012, at 11:10 , Sunny Rajagopalan <[email protected]> wrote:
> Hi, Kireeti, Aldrin > The MPLS label was originally meant to identify a link, Speaking freely for the inventors of MPLS, the semantics of a label were kept very very loose; the associated signaling told you what the label meant. So, an MPLS label for RSVP-TE might be thought of as a link identifier, but an LDP label was a proxy for a destination (egress LSR). A 2547/4364/EVPN label is a lookup table identifier. > 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. :-) Perhaps less so for 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. RDs have a very specific purpose: to distinguish routes in the control plane. VNIDs and labels are to choose forwarding tables; they are a data plane construct. However, the argument that a separate BGP attribute should have been used to signal the label has been made before, and has validity, but that's water under the bridge. > 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. I've already suggested to the authors that they go back to 24 bits -- there is a 24-bit/three-octet field, just use it. Kireeti. > -- > 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
