Early review of draft-ietf-mpls-mna-ps-hdr ========================================== Version: 06 Date review started:2025-01-26 Target Date: 2025-02-08 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. This earl review is done immediately prior to or ib parallel to the Working Group Last Call the comments should be treated as any other WGLC comments. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-mpls-mna-ps-hdr-06 Reviewer: Loa Andersson Date review started: 2026-01-26 Target Date: 2026-02-09 Date the review was completed: WGLC End Date: 22 January 2026 Intended Status: Standards Comments: The document are close to be ready for publication, the comments I have is things the RFC Editor will capture. I have gone through the proto col mechanism and believe it is sound. I have a couple of "questions", since it hard to see where the questions might end up in the classification (major - minor - nits) I have put them under "Minor". I have placed two comments under "Major Issues", the comments are minor, but I always place comments on IANA registries under "Major". Major Issues: ------------- 1. First Nibble registry allocation The IANA registry for first nibbles have a one step identification of first nibble, based on that the context is known +----------+-------+---------------------------------+-----------+ | MPLS | 0x1 | MPLS Generic Associated Channel | [RFC5586] | +----------+-------+---------------------------------+-----------+ We could do this for Post Stack MNA +----------+-------+---------------------------------+-----------+ | MPLS | 0x0 | Post Stack MPLS Header |[RFC to be]| +----------+-------+---------------------------------+-----------+ I.e. PSMH is not the protocol, protocol is still MPLS. 2. The Post Stack MPLS Header Type Registry I think we want it to look like this Post Stack MPLS Header Types Reference [RFC to be] Range Registration Procedures Note 0 Reserved, not to be assigned 1-65520 IETF Review 65521-65524 Experimental Use Reserved 65525-65535 Private Use Reserved Post-Stack MPLS Header Value Meaning Reference 0 Reserved [rfc to be] 1 Post-Stack MPLS Header [rfc to be] 2-65520 Unassigned Reserved 65521-65524 Unassigned Reserved Note 1: The document did not assign value 1 for "Post-Stack Header" even though this is a new registry and an assignment is possible. Note 2: I doubt that we will need 65k codepoints, strictly we could do with only the 16 PFN values for MPLS. Note 3. We have for other registries discussed adding "not to be assigned after reserved, the conclusion was that "reserved" in itself is strong enough. I am ambivalent and will not object if the authors want to do that. Minor Issues: ------------- 1. BOS, LSE and TTL This document has references to RFC 3032 for these abbreviations, the one of these abbreviations expanded in RFC 3032 is TTL, but rfc 3032 also have a discussion about the relationship between MPLS-TTL and IP-TTL. I guess that a TTL abbreviation could be to the IP-TTL, but I amn fine with a reference to rfc 3032 in MPLS context. The documents that I found (with a little bit of help) that accurately expands BOS and LSE are: RFC 6790 for BOS RFC 5586 for LSE 2. BOS The Bottom of Stack concept is discussed in rfc 3032, but if refers to bit 23 in the last LSE of the MPLS encapsulation, not to the LSE containing the S-bit. I suggest that: s/is encoded after the Bottom of the Stack (BOS)/is encoded after the LSE for which Bottom of the Stack (BOS) bit is set/ 4. IPR Poll I think the chairs should verify that everyone that are expected to respond to the IPR poll have done so. Questions . . . . . Note: Questions is something I want authors/reviewers/chairs to think about and agree if something need/should be done. Q1: The abbreviation PS for "Post Stack" is never (in this document) expanded independently, only used in composite abbreviations like MNA-PS-OP and PS-NAL. One way to handle this could be to tweak the beginning of the first sentence in the abstract: s/This document defines the Post-Stack MPLS Network Action (MNA) solution/This document defines the Post-Stack (PS) MPLS Network Action (MNA) solution/ Another possible way would be to just includ "PS" in the abbreviation list in section 2.2. In the RFC Editors list of abbreviation expansion there are two entries of "PS" Parametric Stereo (PS)and Proxy Signature, none is listed as "well-known". I do not think there is a real risk serious confusion, but I guess we should aim for clarity. And also open up the RFC Editor to include Post Stack (PS) in their abbreviation list. Q2: I'm also uncertain about what follows in the second part of the first sentence of the abstract "for carrying Network Actions and Ancillary Data after the MPLS label stack", Network Actions in general and MPLS Network Actions in particular are the name of the technology, and thus include Ancillary Data. Maybe: s/for carrying Network Actions and Ancillary Data after the MPLS label stack/for carrying Network Actions encodings and Ancillary Data after the MPLS label stack/ Nits: The output from nits tool is fairly clean, there are two down-refs, but I guess what is required is that the Shepherd put this info into the shepherds write-up. This document appears to be very near to be ready for publication.