IETF Last Call Review of draft-ietf-mpls-mna-hdr-17
review-ietf-mpls-mna-hdr-17-opsdir-lc-zhou-2025-12-08-00

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: Tianran Zhou

- Review Date: 2025/12/8

- Intended Status: Standards Track

---

In general, this document is consice and clear after many revisions. However,
from the operational point of view, I think it's not ready. As MPLS has already
been deployed for many years in carrire networks, the MNA is a big change to
existing MPLS. So we should be very careful about the impact to existing MPLS
networks. I appreciate the Backward Compatibility section is included as a
first step. However I think a more comprehensive operational considerations
should be included instead. My conserns are follows:

1. I've followed the lifecycle of MNA. There is rare real requirement from
operators/customers from the very beginning. I am afraid the MNA hdr design
would be just paper work.

2. It's not clear why ISD is necessary. Is it for legacy devices with
software/easy upgrade? The current ISD can only be implemented with new chips.
Is it for future proof applications? It’s not as easy and elegant as PSD.

3. ISD has many restrictions. So the solution described in the draft has to
provide many types with different formats. The hardware has to implement many
branches. The operations may be difficalt.Espcially, the ISD is not SR
friendly. ISD has to be repeated every hop. We cannot ignore the damage.

4. This draft includes two parts: the ISD and the basic hdr, which PSD will
depend on. At the same time, the working group are working on both ISD and PSD
in parallel. An operator need to know how ISD and PSD can work together. I
think more considerations should be discussed in this direction.

5. As described in the Backward Compatibility section, "An MNA-encapsulating
node MUST ensure that the MPLS Network Action Sub-Stack indicator is not at the
top of the MPLS label stack when the packet arrives at an MNA-incapable node".
Moreover, for the operational reason, an operater may need information on which
device is MNA incapable or capable? How the MNA incapable device will behave
when dealling with MNA packet(e.g. ECMP)? How the MNA incapable device will
impact the deployment(e.g. one node or two nodes? engress node or trasit
node?)? How the operational complexity will grow when the network scale out?