Aldrin, We closed earlier today on a twenty four bit globally or locally significant MPLS label for VXLAN and NVGRE encapsulations.
Yours irrespectively, John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Aldrin Isaac > Sent: Wednesday, September 26, 2012 3:04 PM > To: Sunny Rajagopalan > Cc: Kireeti Kompella; [email protected] > Subject: Re: [nvo3] use of RD vs MPLS label for VNID encoding (was Re: > comments on draft-drake-nvo3-evpn-control-plane) > > 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
