[mpls] draft-ietf-mpls-mna-ps-hdr-06 early Rtgdir review

[Loa Andersson via Datatracker <[e-mail]>]

Document: draft-ietf-mpls-mna-ps-hdr
Title: Post-Stack MPLS Network Action (MNA) Solution
Reviewer: Loa Andersson
Review result: Has Nits

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.