Hi Eric, Thanks again for raising this. You’re absolutely right that the “MPLS Label” field name is misleading, since it can also carry SRv6 SID bits. No disagreement there.
Your DISCUSS currently says: “Keeping the field name ‘MPLS Label’ is misleading as it can contain SRv6 SID. Did the WG/authors consider updating RFC 6514 to change the field name?” There are precedents in BESS for reusing the same field to carry SID or VNI information, and this has been common practice in that WG. Since your question is really about whether the WG should revisit this naming choice, the natural place to address it is the ongoing (but currently stalled) rfc6514bis [1] effort. There is a concern that changing this field name too casually, could overlook existing uses and create confusion across implementations, tooling, and management models. If we move your observation to rfc6514bis, it can be handled cleanly and with the proper level of WG attention as part of the broader revision. Does that address your DISCUSS concern? Brgds, G/ [1] BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs (https://datatracker.ietf.org/doc/draft-zzhang-bess-rfc6514bis/) From: Eric Vyncke (evyncke) <[email protected]> Sent: Friday, October 31, 2025 8:16 PM To: Rishabh Parekh <[email protected]>; Gunter van de Velde (Nokia) <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello Rishabh, Thanks for your message. About RFC 9252, it indeed contains `in the existing label fields specific to that service encoding` and underspecified “label” did not trigger my attention indeed. If the field is actually “Label” and not “MPLS Label”, this is less annoying than in this draft. Else, errors in the past are not a reason to repeat them in the future. Regards -éric From: Rishabh Parekh <[email protected]<mailto:[email protected]>> Date: Friday, 24 October 2025 at 11:09 To: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Cc: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>, The IESG <[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]>> Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) Eric To add to Gunter's point, RFC 9252 Transposition scheme (Section 4<https://www.rfc-editor.org/rfc/rfc9252.html#name-encoding-srv6-sid-informati>) uses "label" fields in other parts of BGP encoding (NLRI, Extended Community) to encode a portion of the SRv6 SID (FUNCT or ARG) to enable efficient BGP update generation and re-use Extended Communities. Rishabh. On Thu, Oct 23, 2025 at 9:54 PM Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Eric, Circling back to this discussion called out during yesterday’s formal Telechat. You’re absolutely right, the “MPLS Label” field isn’t always an actual label and can sometimes carry SRv6 SID bits instead. The name is definitely a bit misleading, no argument there. The PMSI “MPLS Label” field was originally defined in “RFC6514 section 5”. “ If the MPLS Label field is non-zero, then it contains an MPLS label encoded as 3 octets, where the high-order 20 bits contain the label value. Absence of an MPLS Label is indicated by setting the MPLS Label field to zero. “ The current draft draft-ietf-bess-mvpn-evpn-sr-p2mp reuses the “MPLS Label” field to encode part of an SRv6 SID for SRv6-based dataplanes, as explained in Section 5.2. In other words, it extends the original intent of RFC 6514 with the following procedure: “ · MPLS Label: The high order 20 bits of this field carry the whole or a portion of the Function part of the SRv6 Multicast Service SID when ingress replication is used with the Transposition Scheme of encoding as defined in [RFC9252<https://www.rfc-editor.org/info/rfc9252>]. When using the Transposition Scheme, the Transposition Length of SRv6 SID Structure Sub-Sub-TLV of SRv6 Prefix-SID attribute (see below) MUST be less than or equal to 20 and less than or equal to the Function Length. When Transposition scheme is not used, the label field MUST be set to zero and Transposition Length MUST be zero. “ Finally RFC9252 section 6.3 (https://datatracker.ietf.org/doc/html/rfc9252#section-6.3) provides following SRv6 SID dataplane encoding procedure: “ MPLS label: This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when ingress replication is used and the Transposition Scheme of encoding (Section 4<https://datatracker.ietf.org/doc/html/rfc9252#SIDENCODE>) is used; otherwise, it is set as defined in [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>]. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL. “ @Éric Vyncke<mailto:[email protected]> your observation is correct. The “MPLS Label” name is indeed misleading. As I understand it, the current document is simply reusing the existing “MPLS Label” definition from RFC 9525. From a process point of view, there doesn’t seem to be a strong reason to block this document over that. That said, it’s definitely worth flagging this observation to the BESS WG. Using a term like “MPLS Label” to carry SRv6 SID bits isn’t ideal, and it might be good to discuss whether there’s consensus to revisit and adjust such dataplane-specific naming in the future. Would that work for you to resolve the DISCUSS? G/ From: Rishabh Parekh <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 22, 2025 7:41 PM To: Éric Vyncke <[email protected]<mailto:[email protected]>> Cc: The IESG <[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]> Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. Eric, Responses inline @ [RP] Thanks, Rishabh. On Wed, Oct 22, 2025 at 7:29 AM Éric Vyncke via Datatracker <[email protected]<mailto:[email protected]>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-mvpn-evpn-sr-p2mp-15 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Stéphane Litkowski for the shepherd's write-up including the WG consensus *and* the justification of the intended status. Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/reviewrequest/22937/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Sections 3 & 5.2 Keeping the field name of "MPLS Label" (singular) is really misleading as it can contains SRV6 SID. Did the WG/authors consider updating RFC 6514 to change the field name ? [RP] No, we did not because RFC 9252 Section 6.3 already set a precedent of using the "MPLS Label" field to transpose some part of the End.DT2M SID. I can change the title of the Section to "MPLS Label field" and add clarifying text to the SRv6 sub-section. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Abstract s/This document describes/This document specifies/ ### Section 1 s/allow a Service Provider/allow a network operator/ s/This document describes/This document specifies/ [RP] Done. While the statements `The reader is expected...` are valid in a RFC, they do not help the IESG review by a non expert. [RP] Maybe, but much of this document is based on work done in other RFCs which are a prerequisite for understanding this document. Based on another comment, I have converted some of this text to a Terminology section, but the prerequisite understanding is still required. ### Section 3.1.2 To be honest, I failed to follow the procedure... A decriptive figure would help a lot. The same comment for the whole section 4. [RP] The next revision is going to reorganize and restructure this document based on Ketan's comments; I hope it will improve readability and clarity. Section 3.1.2 is based on Section 4 and 6.1.3 of RFC 9252. We have added a diagram and high level explanation of the solution in Section 2 and Section 4 (or at least the detailed Auto-Discovery procedures) have been simplified. ### Section 7 Please properly define `IMET`. No need to define twice the "BUM". [RP] These are now defined in the Terminology section. What is a `NVE`? [RP] Text related to NVE has been removed in next revision. ### Section 8 Having a list of implementations is nice, but if the document refers to RFC 7942, then it should follow section 2 of this RFC rather than having a very succint description. [RP] May I ask what is lacking in this section? ### Section 9 Please add also a URI for "SRv6 Endpoint Behaviors" registry. [RP] Done. _______________________________________________ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
