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?