IETF Last Call Review of draft-ietf-mpls-mna-hdr-17
review-ietf-mpls-mna-hdr-17-opsdir-lc-clarke-2025-12-16-01

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-mpls-mna-hdr-17

- Reviewer: Joe Clarke

- Review Date: Dec 15, 2025

- Intended Status: Proposed Standard

---

## Summary

## General Operational Comments Alignment with RFC 5706bis

Given I don't have a lot of experience in large MPLS network deployments, I
wanted to review this document paying close attention to the OPS DIR template
and checklist.  My aim for this review is to be as objective as possible.

The document is a well-written specification for the MPLS Network Action
Sub-Stack. It demonstrates awareness of operational and security implications,
providing clear guidance on deployment, processing, and backward compatibility.
The presence of an implementation is appreciated and shows the feasibility of
the spec. The identified issues are primarily minor editorial suggestions or
areas for slight clarification.  I didn't find any major operational issues.

Explicitly evaluate compliance with operational guidelines (optional but
recommended):

For example the check list:

- Fault Management: Are failure detection/recovery mechanisms specified?

The draft discusses what to do in the case of an unknown network action is
received.  Moreover, if the action to take is to drop the packet, the draft
emphasizes the need for local counters and rate-limited notifications of such
events.

- Configuration Management: Are configuration changes to enable/disable the
feature clearly defined?

No, not explicitly.  Though, for this spec, I don't think it's required.  This
spec focuses more on dataplane aspects.  Config would be left to a different
draft.

- Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly
identified?

With respect to performance and scale, the draft introduces and explains the
NASL and NAL fields, providing mechanisms to scale the amount of in-path data.
The concept of multiple NASes for different scopes (i.e., I2E, HBH, Select)
offers added flexibility.  That said, a **suggestion**: adding a brief
acknowledgment of potential performance implications (e.g., parsing overhead)
of very deep or numerous NASes on high-speed forwarding planes in large-scale
operations could be beneficial.

## Major Issues

No major issues found.

---

## Minor Issues

Not an issue per se, but an additional **suggestion**:

Adding an Operational Considerations section that summarizes counters and
metrics one might want to collect when implementing MNA (e.g., MNA packets
received, MNA packets dropped due to unknown action, per-actions taken
counters, MNA sub-stacks processed), as well as notifications an implementor
may want to generate would be helpful.

---

## Nits

* "process an NAS on to the Label stack" (Section 9.2) is slightly awkward;
"processes an NAS in the Label stack" might be clearer.  And, honestly, I
always read "NAS" as a word vs. N.A.S. so the "an" here and in other places in
the doc was kind of weird.

* "MNA-creates a new dimension" (Section 13) should be "MNA creates a new
dimension" (remove hyphen).

* And maybe less of a nit,
"The node that receives the NAS at the top of the label stack MUST remove it."
(Section 7)...should this node JUST remove the NAS or should it process it as
well?  It's unclear.