[mpls] Re: Éric Vyncke's Discuss on draft-ietf-mpls-mna-hdr-19: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Eric,

I would like to provide some background on the "experimental" track aspect.
This was something that was debated during the WG phase of this document -
quite a lot actually.

One of the key points that came up during that debate was that the base
special purpose MPLS label (bSPL) that is required by this solution is a
scarce resource and allocation is possible only via "Standards Action" -
https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml#special-purpose

There was no appetite (IIRC) in the WG to loosen that criteria to allow
allocation for experimental specs. Doing this as experimental with a
different proposal would make such an experiment very different from what
is in the spec today and hence become a hurdle in a seamless upgrade from
experiment to standards track in implementations and deployments. This is a
very high-level summary and I'll let the authors, WG chairs and responsible
AD add/clarify.

That said, I am wondering if there is some process for the IESG to make a
special one-time allocation from this registry for an experimental document
if that is what the WG desires.

Thanks,
Ketan


On Thu, Feb 5, 2026 at 4:45 PM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-mpls-mna-hdr-19: 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-mpls-mna-hdr/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke INT AD comments for draft-ietf-mpls-mna-hdr-19
> CC @evyncke
>
> Thank you for the work put into this document. This work looks very
> similar to
> the IPv6 extensions headers and to SRv6 Network Programming. So, as INT AD
> and
> working with IPv6 extension headers for 15+ years, I am afraid that I have
> some
> real concerns about this document. And, as usual, I will be happy to stand
> corrected.
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points/nits (replies would be appreciated even if only for my own
> education).
>
> Special thanks to Tarek Saad for the shepherd's *detailed* write-up
> including
> the difficult-to-reach WG consensus *BUT* it completely lacks the
> justification
> of the intended status even if the 2nd WGLC was about the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> Note: this ballot comments follow the Markdown syntax of
> https://github.com/mnot/ietf-comments/tree/main, i.e., they can be
> processed by
> a tool to create github issues.
>
> ## 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.
>
> ### Intended publication status
>
> With a single implementation from one University (i.e., no vendors), I do
> not
> think that this I-D should be a "proposed standard" but rather an
> "experimental" one. Gunter Vandevelde hinted also to this issue.
>
> An 'experimental' status would also transform my blocking DISCUSS points
> below
> in COMMENT points.
>
> ### Section 2.2
>
> Some acronyms have wrong references, e.g., I cannot find BOS in RFC 3032.
>
> ### Section 4
>
> It is completely unclear to me how can a MPLS node know how to parse a LSE,
> i.e., how can it know that this is format B, or C ? The reader can *guess*
> that
> format A is the first one identifed by bSPL.
>
> Normative text, including a figure having a complete NAS (with multiple
> LSEs)
> and key fields would be welcome. Section 5 has some hints that could be
> re-used
> to do EARLIER in the text. Or an example from the appendix.
>
> ### Section 7
>
> `If the NAS is to be processed by a downstream MNA-capable node, then the
> entire NAS MUST be placed so that it is within RLD by the time the packet
> reaches the downstream MNA-capable node` is missing a normative reference
> on
> how a node knows about the RLD of the downstream node.
>
> ### Section 7.1
>
> For very good reasons, IPv6 extension headers cannot be inserted on the
> path,
> so, how is the MTU change handled/signalled when a node increases the label
> stacks as in `n MNA-capable node may need to push additional labels as
> well as
> push new network actions onto a received packet.`
>
> ### Section 14.4
>
> While the section 12 (security consideration) rightfully contains `The
> semantics of a network action are unbounded and may be insecure ... The
> IETF
> needs to ensure that only secure network actions are defined`, the section
> 14.4
> only mentions `Registration requests should comply with Section 10.`
> (i.e., no
> security review).
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### Section 3
>
> In a PS (but see my DISCUSS points): s/This document describes how network
> actions/This document *specifies* how network actions/
>
> ### Section 5.2
>
> I fear that the last paragraph is really opening the door for heavy
> troubleshooting a network that has assumed not to do ECMP but actually
> doing
> it...
>
> ### Section 5.3
>
> With all the issues (and discussions) related to the IPv6 HbH options
> extension
> header, I am unsure whether it is wise to re-introduce the same concept.
> OTOH,
> the MPLS domain is usually under a single operator, so, perhaps safer.
>
> ### Section 5.4
>
> Per
>
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
> ,
> there should be guidance when using a SHOULD such as in `the node SHOULD
> maintain a local counter for this event``
>
> ### Use of SVG graphics
>
> To make a much nicer HTML rendering, suggest using the aasvg tool to
> generate
> SVG graphics. It is worth a try especially if the I-D uses the Kramdown
> file
> format ;-)
>
>
>
>