Comments inline. Yours irrespectively,
John From: [email protected] [mailto:[email protected]] On Behalf Of Sunny Rajagopalan Sent: Wednesday, September 26, 2012 11:11 AM To: Kireeti Kompella Cc: [email protected]; Aldrin Isaac Subject: [nvo3] use of RD vs MPLS label for VNID encoding (was Re: comments on draft-drake-nvo3-evpn-control-plane) 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. :-) JD: In drake-nvo3 the MPLS label is being used as the data plane packet demux at the egress. This is entirely consistent with its usage in all of the existing L2/L3 VPN technologies. In VXLAN and NVGRE, the data plane packet demux has global significance. drake-nvo3 allows this but also allows the data plane packet demux to have local significance, which is more consistent with all of the existing L2/L3 VPN technologies. 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. JD: RD is strictly a control plane construct used to keep BGP happy. It has never been used as a data plane packet demux. 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. JD: You did not read the text carefully enough. The contents of the 3 octet MPLS label field are copied directly into the VNID/Tenant ID field of a packet. -- Sunny From: Kireeti Kompella <[email protected]<mailto:[email protected]>> To: Aldrin Isaac <[email protected]<mailto:[email protected]>>, Cc: Sunny Rajagopalan/Santa Clara/IBM@IBMUS, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[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
