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.