IETF Last Call Review of draft-ietf-mpls-mna-ps-hdr-08
review-ietf-mpls-mna-ps-hdr-08-opsdir-lc-xie-2026-06-16-00
review-ietf-mpls-mna-ps-hdr-08-opsdir-lc-xie-2026-06-16-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-ietf-opsawg-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-ps-hdr-08] - Reviewer: [Chongfeng Xie] - Review Date: [June 17, 2026] - Intended Status: [Proposed Standard] --- ## Summary Choose one: - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis > This document defines a mechanism to influence packet forwarding decisions based on the additional information in the MPLS packet, or perform user-defined operations. While the technical approach is sound, the document lacks the consideration on how the mechanism would be deployed and managed, and it is recommended that a section on operational considerations be added to aligh with RFC57606 bis. ## Major Issues > No major issues found. --- ## Minor Issues List non-blocking but important clarifications (e.g., ambiguous terminology or incomplete examples). > This document currently uses full terms and their abbreviations interchangeably (e.g., “Post-Stack MPLS Header” and “PSMH”). To avoid redundancy, it is recommended to adopt a single consistent form throughout, otherwise, defining the abbreviation is unnecessary. > It is recommended to change the definition of IHS as below, OLD: IHS (2 Bits): The In-Stack NAS for each scope with the P bit set has a corresponding Post-Stack MPLS Header. NEW: IHS (2 Bits): The scope of all the network actions for the In-Stack NAS with the P bit set. > In section 3.1, the definition of the S flag should be relocated to precede that of the U flag, and the text can be changed to "Same to the definition of S flag in section 4.2 of [I-D.ietf-mpls-mna-hdr]" > Regarding the title of section 3.2.1, since the struct in figure 2 contains not only header type, but also PFN and PSMH-Len, it is more suitable to use "Post-Stack MPLS Base Header", instead of "Post-Stack MPLS Header Type". >In section 3.2.3, I think the addreviation of "PSMHT" can be removed, too many abbreviations, particularly those without substantive meaning, do not contribute much to the draft. >The title of section 4.1 can be simplified as, OLD: In-Stack Network Action Opcode for PSMH Start Offset for MNA NEW: Opcode for PSMH Start Offset for MNA >The title of section 4.2 can be simplified as, OLD: In-Stack Network Action Opcode for Offset of End of Post-Stack MPLS Header for MNA NEW: Opcode for Offset of End of Post-Stack MPLS Header for MNA > In section 5.3, "ingress node" is used to refer to the node that adds a Post-Stack MPLS Header, to avoid duplicative terms., it is suggested to change it to "Encapsulating node" , and the terms of "participating node" and "egress node" can be changed to "encapsulating node" and "decapsulating node" repectively. --- ## Nits > No Nits found. --- Chongfeng Xie