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. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-mna-ps-hdr-07 Reviewer: Matthew Bocci Review date: 4-Mar-2026 Summary ------- In general, the draft is clear and readable. Thank you! I appreciate that the draft is the a part of a wider set of protocol extensions required to achieve MPLS Network Actions, so I have primarily reviewed this from the context of the post stack header format and processing that it defines, rather than broader questions of the overall trajectory of the MNA design. In general I believe my comments are fairly minor but these should be resolved before progressing the draft. Please also look at the RTGDIR review and the changes that were made to that draft as a result, as I think it would be good to align the two drafts. There is an outstanding issue of the clarity of what is being requested from IANA, although it should be straightforward to address. Details Comments. ----------------- Comments are embeded below, prefixed by MB>. Line numbers are generated by id-nits. -------------------------------------------------------------------------------- 2 MPLS Working Group J. Rajamanickam, Ed. 3 Internet-Draft R. Gandhi, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 28 August 2026 R. Zigler 6 Broadcom 7 J. Dong 8 Huawei Technologies 9 J. Bhattacharya 10 Cisco Systems, Inc. 11 24 February 2026 13 Post-Stack MPLS Network Action (MNA) Solution 14 draft-ietf-mpls-mna-ps-hdr-07 MB> Can the title of the document better reflect its content? The draft specifies the post stack header encoding to support post-stack MNA but it is not an MNA solution as described in RFC9782 Section 2. I would suggest updating the title to something like: "Post-Stack MPLS Network Action (MNA) Header Specification.", or something along those lines. Note that I made a similar comment for the in-stack MNA header draft which was accepted and it would be good for the two documents to be aligned in this sense. 16 Abstract 18 This document defines the Post-Stack MPLS Network Action (MNA) 19 solution for carrying Network Actions encodings and Ancillary Data 20 after the MPLS label stack, based on the In-Stack MNA solution 21 defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS 22 Network Actions can be used to influence packet forwarding decisions, 23 carry additional Operations, Administration, and Maintenance 24 information in the MPLS packet, or perform user-defined operations. 25 This solution document addresses the Post-Stack network action and 26 Post-Stack data-specific requirements found in RFC 9613. This 27 document follows the framework specified in RFC 9789. MB> I suggest updating the above text to align with my proposed revision to the title above (i.e. talk in terms of a specififcaiton rarher than a solutio). Also, update the title of the MNA sub-stack solution for in-stack network actions and add a proper reference to the draft. 29 Status of This Memo [snip] 112 1. Introduction 114 [RFC3032] defines the encoding of the MPLS label stack, the basic 115 structure used to define a forwarding path. Forthcoming applications 116 require MPLS packets to perform special network actions and carry 117 optional Ancillary Data (AD) that can affect the packet forwarding 118 decision or trigger Operations, Administration, and Maintenance (OAM) 119 logging, for example. AD can be used to carry additional 120 information, such as data for In Situ OAM (IOAM) as described in 121 [RFC9791]. MB> The term "forthcoming" could become outdated very rapidly. Rather than saying "Forthcoming applications" it would be clearer to move the reference to RFC9791 up front and say "There are applications that... ". Note this comment was also made and accepted in the RTGDIR review of draft-ietf-mpls-mna-hdr-17. 123 In some cases, more AD may be required than can be carried in the 124 MPLS header, so these kinds of network actions and their AD are 125 encoded after the Bottom of Stack (BOS). This network action with AD 126 is called the Post-Stack (PS) MNA. [snip] 208 3. Overview 210 The Post-Stack MNA solution contains two main parts: MB> I suggest rephrasing the above to: "Two main parts are specified to support post-stack MNA:" 212 * Post-Stack MPLS Header Presence Bit Carried in In-Stack MNA Sub- 213 Stack MB> s/Post-Stack MPLS Header/The Post-Stack MPLS header 215 * Post-Stack MPLS Header Encoding that includes Post-Stack MPLS 216 Header Type and Post-Stack Network Actions MB> s/Post-Stack MPLS Header/The Post-Stack MPLS header encoding MB> Also add full stops/periods to the end of each bullet above, or go throuigh the draft and check consistency of the use of these at teh end of bullet lists. 218 3.1. Post-Stack MPLS Header Presence Bit Carried in In-Stack MNA Sub- 219 Stack 221 Bit 20 in LSE Format B carried in the In-Stack Network Action Sub- 222 Stack (NAS) described in [I-D.ietf-mpls-mna-hdr] is defined as the P 223 bit in this document to indicate the presence of the Post-Stack MPLS 224 Header in the packet after the BOS. 226 0 1 2 3 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Opcode | 13-bit Data (Format B) |P|IHS|S| NASL |U| NAL | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: Post-Stack MPLS Header Presence Bit Carried in In-Stack 232 MNA Sub-Stack 234 The following flags are carried in In-Stack NAS as defined in 235 [I-D.ietf-mpls-mna-hdr] and shown in Figure 1. These flags are also 236 applicable to Post-Stack MNA: MB> s/carried in In-Stack NAS/carried in an In-Stack NAS 238 * IHS (2 Bit): Indicates the combined scope of the In-Stack and the 239 Post-Stack Network Actions. In-Stack NAS for each scope with P 240 bit set has its corresponding Post-Stack MPLS Header. MB> I suggest rephrasing the sentence above to: "The In-Stack NAS for each scope with the P bit set has a corresponding Post-Stack MPLS Header. 242 * U (1 Bit): Indicates the combined Unknown Action Handling of the 243 In-Stack and the Post-Stack Network Actions. 245 3.2. Post-Stack MPLS Header Encoding 247 The Post-Stack MPLS Header (PSMH) for MNA is encoded after the LSE 248 for which Bottom of the Stack (BOS) bit is set, either immediately 249 after the BOS (i.e., start offset of 0) or after any other Post-Stack 250 headers that follow the BOS (i.e., start offset of non-zero), as 251 described in Section 4. 253 The PSMH for MNA carries one or more Post-Stack Network Actions and 254 their Ancillary Data. 256 The PSMH for MNA consists of two main parts: 258 * Post-Stack MPLS Header Type 260 * Post-Stack Network Action Encoding 262 3.2.1. Post-Stack MPLS Header Type 264 The Post-Stack MPLS Header type is the top-header for all the Post- 265 Stack Network Actions that are encoded in the PSMH for each scope as 266 shown in Figure 2. 268 0 1 2 3 269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | PFN |Reserve| PSMH-LEN | TYPE = MNA-POST-STACK-HDR = 1 | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 2: Post-Stack MPLS Header Type MB> I suggest just saying 'Type = MNA-POST-STACK-HDR' without the numerical value (as this is subject to IANA allocation). MB> Also, not sure why you capitalised the field name. 276 * PFN (4 bits): The Post-Stack First Nibble (PFN) [RFC9790] 277 identifies the start of the PSMH. The PFN is set to 0x00b for the 278 Post-Stack MPLS header. MB> The IANA registry for the Post-stack first nibble is expressed as a hexadecimal MB> ranging from 0x0 to 0xF (it is 4-bits). I am not sure what value is implies by the notation 0x00b, MB> Do you mean to request 0x0? Also see my comment in the MB> IANA considerations section. 280 * Reserve (4 bits): Reserved bits. 282 * PSMH-LEN (8 bits): The PSMH total length in 4-octet units that 283 includes Post-Stack Network Actions. The length excludes the 284 4-byte PSMH type header. 286 * TYPE (16 bits): Type is set to 1 to indicate Post-Stack MPLS 287 Header Type for MNA. See Section 8.2. Note that other types of 288 Post-Stack headers (besides MNA) can be defined in the future and 289 is outside the scope of this document. MB> I think just 'Type' is sufficient instead of 'TYPE'. 291 3.2.2. Post-Stack Network Action Encoding 293 The format shown in Figure 3, encodes a single Post-Stack Network 294 Action. By repeating this format, multiple Post-Stack Network 295 Actions and their corresponding Ancillary Data can be encoded. 297 0 1 2 3 298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | MNA-PS-OP |R|R| PS-NAL | POST-STACK DATA | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ CONTINUED POST-STACK DATA ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Post-Stack Network Action Encoding MB> I am not sure why the field names are capitalised if they are not acronyms. MB> I suggest replacing with 'Post-Stack Data' and 'Continued Post-Stack Data'. MB> This comment applies to the figures and field names throughout the draft. 307 * MNA-PS-OP (7 bits): Post-Stack Network Action Opcode. See 308 Section 8.3. 310 * R (2 bits): Reserved bits. 312 * PS-NAL (7 bits): Post-Stack Network Action Length in 4-octet 313 units. This excludes the first 4-octets starting with MNA-PS-OP. 315 * POST-STACK DATA (16 bits): Post-Stack Data associated with the 316 Post-Stack Network Action. 318 * CONTINUED POST-STACK DATA: Further Post-Stack Data associated with 319 the Post-Stack Network Action, as indicated by the value of PS- 320 NAL. The padding rules for Post-Stack Data that does not fill a 321 multiple of 32-bit units are described in the document that 322 defines the NA indicated by the MNA-PS-OP value. 324 3.2.3. Example MPLS Packet with Post-Stack MPLS Header for MNA 325 0 1 2 3 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 327 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 328 M | MNA Label | TC |0| TTL | N 329 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A 330 L |Opcode=2=NOOP| 0 |1|IHS|0| NASL=0|U|NAL=0| S 331 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 332 H ~ |0| ~ 333 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 R | |1| | 335 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 336 P | 0x00 |Reserve| PSMH-LEN | TYPE = MNA-POST-STACK-HDR = 1 |PSMHT 337 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 338 M | MNA-PS-OP |R|R| PS-NAL | POST-STACK DATA | | 339 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PSNA 340 | ~ CONTINUED POST-STACK DATA ~ | 341 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 342 ~ ~ 343 ~ Payload ~ 344 ~ ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 4: Example MPLS Packet with Post-Stack MPLS Header for MNA MB> See comment above about capitalisation of text and the value of the type. MB> Is this really an example, or is it a specification? Maybe rephrase the section to MB> 'Encoding of an MPLS Packet with a Post-Stack Header for MNA'. Also clean MB> up the use of the term 'example' throughout this section. 349 An example of an MPLS packet encoding that carries an MPLS header and 350 a Post-Stack MPLS header for the MNA Post-Stack Header type is shown 351 in Figure 4. The encoding contains the following fields. 353 * MPLS HDR: MPLS Header containing an MPLS label stack and MNA Sub- 354 Stacks (NAS). 356 * NAS: Network Action Sub-Stack. It has the P bit set to 1 to 357 indicate the presence of a Post-Stack MPLS header for the MNA 358 Post-Stack Header type in the packet. An MPLS packet may carry 359 more than one NAS, not shown in Figure 4. 361 * PSMH: Post-Stack MPLS Header. This includes the Post-Stack MPLS 362 header type (PSMHT) and Post-Stack network actions (PSNA). 364 * PSMHT: Post-Stack MPLS Header Type. This includes the type of 365 Post-Stack MPLS header, version, and Post-Stack MPLS Header 366 length. In this example, the type is set to the MNA Post-Stack 367 Header. 369 * PSNA: Post-Stack Network Actions. Applicable only when the type 370 is set to the MNA Post-Stack Header. An MPLS packet may have more 371 than one Post-Stack Network Action, not shown in Figure 4. [snip] 474 6. Node Responsibilities MB> I suggest aligning the title of this with the equivalent section of draft-ietf-mpls-mna-hdr: MB> "Processing the Network Action Sub-Stack and Post-Stack Header". MB> I think this section also needs to say something about which parts of draft-ietf-mpls-mna-hdr MB> apply in the post-stack case. 476 This section defines the specific responsibilities for nodes along an 477 MPLS path for processing a Post-Stack MPLS Header. 479 6.1. Encapsulating Node Responsibilities 481 The encapsulating node MAY add a Post-Stack MPLS Header to the packet 482 in accordance with its policies, the placement restrictions, and the 483 limitations. MB> I am not sure the above sentence is clear. Do you mean?: "The encapsulating node MAY add a Post-Stack MPLS Header to the packet. The location of the header MAY be in accordance with local policy. The location may also be subject to any placement restrictions inherent in the implementation." 485 The encapsulating node MUST NOT add a Post-Stack MPLS Header to the 486 packet if the decapsulating node does not support Post-Stack MPLS 487 Header. 489 If the encapsulating node is also a transit node, then it MUST also 490 respect transit node responsibilities. MB> Perhaps the above sentence is not necessary from a functional perspective and can be removed. 492 The encapsulating node MUST add the Post-Stack MPLS Header in the 493 same order as the corresponding In-Stack NAS in the MPLS header. 495 6.2. Transit Node Responsibilities 497 A transit node MAY modify the Ancillary Data in the Post-Stack MPLS 498 Header. 500 A transit node MUST respect the Unknown Action Handling flag encoded 501 in the corresponding NAS when processing the PSMH. 503 A transit node that removes an NAS with the Select scope, MUST also 504 remove the associated PSMH. 506 6.3. Penultimate Node Responsibilities 508 In addition to the transit node responsibilities above, the 509 penultimate node MUST NOT remove an HBH or I2E NAS 510 [I-D.ietf-mpls-mna-hdr] and the associated PSMH when the NAS is 511 exposed after removing the forwarding (transport) label. This allows 512 the egress node to receive and process the NAS and the associated 513 PSMH. 515 6.4. Decapsulating Node Responsibilities 517 The decapsulating node MUST remove the Post-Stack MPLS Headers from 518 the packet when it removes the NASes. 520 7. Security Considerations 522 The security considerations in [RFC3032], [RFC9789], and 523 [I-D.ietf-mpls-mna-hdr] also apply to this document. 525 System designers must be aware that information included in Post- 526 Stack Ancillary Data may be transmitted "in the clear." Network 527 actions that require the exchange of sensitive data, must be defined 528 in such a way that the data is encrypted in transit. 530 8. IANA Considerations 532 8.1. First Nibble for Post-Stack MPLS Header 534 This document requests that IANA update the the "Post-Stack First 535 Nibble" registry created by [RFC9790] to include the PFN value 0x00b 536 for the Post-Stack MPLS Header. 538 +==========+=======+========================+===============+ 539 | Protocol | Value | Description | Reference | 540 +==========+=======+========================+===============+ 541 | MPLS | 0x00 | Post-Stack MPLS Header | This document | 542 +----------+-------+------------------------+---------------+ 544 Table 2: Post-Stack First Nibble Registry MB> The above section is not consistenty with the registry specification, and I MB> am not sure what value the notation '0x00b' refers to. Perhaps this is "0x0"? MB> Please clarify/correst this and correct the value in the table above to "0x0" MB> if that is what it being requested. MB> I would also rephrase the paragraph to be something like: This document requests that IANA update the the "Post-Stack First Nibble" registry created by [RFC9790] to include the PFN value 0x0 for the Post-Stack MPLS Header. This should be added as a new entry in regsitry. [snip]