Skip to main content

IETF Last Call Review of draft-ietf-mpls-mna-hdr-17
review-ietf-mpls-mna-hdr-17-tsvart-lc-trammell-2025-12-17-00

Request Review of draft-ietf-mpls-mna-hdr
Requested revision No specific revision (document currently at 20)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2025-12-16
Requested 2025-12-02
Authors Jaganbabu Rajamanickam , Rakesh Gandhi , Royi Zigler , Haoyu Song , Kireeti Kompella
I-D last updated 2026-02-06 (Latest revision 2026-02-06)
Completed reviews Rtgdir Early review of -04 by Acee Lindem (diff)
Opsdir IETF Last Call review of -17 by Tianran Zhou (diff)
Genart IETF Last Call review of -17 by Meral Shirazipour (diff)
Tsvart IETF Last Call review of -17 by Brian Trammell (diff)
Rtgdir IETF Last Call review of -17 by Matthew Bocci (diff)
Opsdir IETF Last Call review of -17 by Joe Clarke (diff)
Secdir IETF Last Call review of -17 by Derrell Piper (diff)
Tsvart Telechat review of -18 by Brian Trammell (diff)
Assignment Reviewer Brian Trammell
State Completed
Request IETF Last Call review on draft-ietf-mpls-mna-hdr by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/9lQD8SWLm9bjeZi5V8XckHVRwNQ
Reviewed revision 17 (document currently at 20)
Result Not ready
Completed 2025-12-17
review-ietf-mpls-mna-hdr-17-tsvart-lc-trammell-2025-12-17-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document, on its own, does not pose any particular concern from a
transport layer standpoint, though of course any network action built with it
that modifies packets at layer 4 would. (Note to users of this functionality in
the future: please do not do this).

Keeping in mind that I do not run an MPLS network (either in production or on
an experimental basis), I remain concerned about how the proposed approach
would work on actual MPLS networks; two issues in particular warrant particular
attention IMO:

I'm... vaguely aware of how MPLS and ECMP work (as the latter does have impact
on transports and applications whose performance is sensitive to packet
reordering), and this vague awareness leads me to be concerned that load
balancing entropy can be carried in MNA ancillary data, and I don't really
understand how this will interact with ECMP as it is used in the Internet
today. I *think* the guidance in section 11 para 5 ("When adding the Entropy
Label Identifier (ELI)...") is intended to address this but I honestly can't
figure out how this would play out in a mixed deployment or during the rollout
of this functionality.

I will defer to the SECDIR review and Security ADs on security concerns with
this approach, though I note that the Security Considerations section is filled
with enough caveats that I'd be extremely wary of deploying this approach on a
production network. "The IETF needs to ensure that only secure network actions
are defined," in particular, is not guidance that I would know how to follow as
a security AD, and seems to gravely misunderstand the role of the Internet
standards process in ensuring distributed system security.