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]> 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 <[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]> > *Sent:* Wednesday, October 22, 2025 7:41 PM > *To:* Éric Vyncke <[email protected]> > *Cc:* The IESG <[email protected]>; [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. > > > > Eric, > > Responses inline @ [RP] > > > > Thanks, > > Rishabh. > > > > On Wed, Oct 22, 2025 at 7:29 AM Éric Vyncke via Datatracker < > [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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
