[Int-dir] Re: [mpls] draft-ietf-mpls-mna-ps-hdr-13 telechat Intdir review

[Rakesh Gandhi <[e-mail]>]

Hi Ted,

Thank you for the Intdir review.

Please see a comment inline with <RG>...

On Sun, Aug 2, 2026 at 4:03 PM Ted Lemon via Datatracker <[e-mail]>
wrote:

> Document: draft-ietf-mpls-mna-ps-hdr
> Title: Post-Stack MPLS Network Action (MNA) Header Specification
> Reviewer: Ted Lemon
> Review result: Ready with Issues
>
> This is an intdir review of draft-ietf-mpls-mna-ps-hdr-13. This review is
> not
> coming from a place of knowledge of how MPLS works, so I'll briefly
> explain my
> understanding of what this document does: it extends the MPLS Network
> Action
> (MNA) header by providing a way to include additional data _after_ the
> rest of
> the MPLS headers so that the fast-path-readable headers come first in cases
> where the post-stack headers would, if included inline, potentially push
> some
> MPLS labels out of the readable label depth of the header.
>
> Because the point (again, as I understand it) of MPLS is to do label-based
> routing and avoid routing on the IP header, and because this is
> essentially an
> OAM extension to MPLS (again, as I understand it) this document should not
> have
>


<RG> The MNA encapsulation can be carried by data packets or OAM test
packets.



> any new implications for the IP layer or layer two, with one exception: the
> size of the MPLS header can be increased through the use of this
> mechanism, so
> in principle it is possible that this could lead to a packet that fit in
> the
> MTU of the MPLS path to no longer fit.
>
> The document addresses this case by requiring that the node adding the PSMH
> header must not increase the size of the packet above the path MTU.
> However,
> the mechanism for discovering the path MTU described in RFC 3032 relies on
> ICMP
> too-big messages, so this is a bit circular, particularly if the packet to
> which the MNA post-stack header is being added is not an IP packet.
>

<RG> MPLS Ingress node requires to know the Path MTU, which is an existing
requirement.

<RG> Agree that adding a MNA PSH can cause MPLS packets to exceed the path
MTU, so the ingress node needs to account for it.

<RG> Hence, the draft contains following text:

* The encapsulating node MUST ensure that the packet with all PSMHs added
does not exceed the path MTU, as specified in Section 8 of [RFC9994].*

Thanks,
Rakesh (for authors)



>
> Given that the post-stack header can in principle be fairly large, this
> feels
> like something that ought to be addressed explicitly, even if in current
> practice it's simply not an issue (as a non-expert I obviously have no clue
> whether or not this is the case).
>
> I'm marking the document "ready with issues" on this basis. This is not an
> assertion that there is a problem—it's just that I can't confirm from my
> reading whether or not there is a problem, so it feels worth mentioning.
> Aside
> from this the document makes sense and appears useful.
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>