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

[Rakesh Gandhi <[e-mail]>]

Hi Eric,

Thank you for the review of the document and the suggestions.

I just wanted to comment on the intended status discussion from the
author's side.
A poll was conducted by the WG chairs and it was concluded to make this
document PS.

FYI: The following email summarizes this WG decision.
https://mailarchive.ietf.org/arch/msg/mpls/cmg1a1SZDXPj5R4n53_31244Rq8/

Thanks,
Rakesh (for authors)



On Thu, Feb 5, 2026 at 6:16 AM É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 ;-)
>
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>