[bess] Re: Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT)

[Rishabh Parekh <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, October 22, 2025 7:41 PM
> *To:* Éric Vyncke <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> *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 <
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>