Skip to main content

Telechat Review of draft-ietf-mpls-mna-ps-hdr-13
review-ietf-mpls-mna-ps-hdr-13-intdir-telechat-lemon-2026-08-02-00

Request Review of draft-ietf-mpls-mna-ps-hdr
Requested revision No specific revision (document currently at 19)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2026-08-02
Requested 2026-07-13
Requested by Éric Vyncke
Authors Jaganbabu Rajamanickam , Rakesh Gandhi , Royi Zigler , Jie Dong , Jisu Bhattacharya
I-D last updated 2026-08-06 (Latest revision 2026-08-06)
Completed reviews Rtgdir Early review of -06 by Loa Andersson (diff)
Rtgdir Early review of -07 by Matthew Bocci (diff)
Genart IETF Last Call review of -08 by Roni Even (diff)
Opsdir IETF Last Call review of -08 by Chongfeng Xie (diff)
Secdir IETF Last Call review of -08 by Yoav Nir (diff)
Intdir Telechat review of -13 by Ted Lemon (diff)
Comments
As MNA is vaguely the MPLS equivalent of SRv6 network programming and MPLS sits somewhere between layer-2 and layer-3, a INT review will be useful. Thanks.
Assignment Reviewer Ted Lemon
State Completed
Request Telechat review on draft-ietf-mpls-mna-ps-hdr by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/QFh8ISALzlpXtYGa264Cb-Qkbkk
Reviewed revision 13 (document currently at 19)
Result Ready w/issues
Completed 2026-08-02
review-ietf-mpls-mna-ps-hdr-13-intdir-telechat-lemon-2026-08-02-00
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
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.

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.