MPLS Network Action (MNA) Post-Stack Header Specification
draft-ietf-mpls-mna-ps-hdr-19

Thanks to Yoav Nir for their secdir review. 

Section 7:  I agree with Ketan's comment, if moving network action data past the BoS introduces additional security concerns, they should be covered here.

Thanks for the work done in this document and addressing my previous [DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/mpls/PiQyEDKJEraO5lo_C1cN5769TRk/) and addressing [Ted Lemon INT-DIR review](https://mailarchive.ietf.org/arch/msg/int-dir/QFh8ISALzlpXtYGa264Cb-Qkbkk/).

I would still have preferred an experimental publication status though, but won't oppose further.

Regards

-éric

Thanks for preparing this I-D, I did not see any issues relating to transport protocol operation.

Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-mna-ps-hdr-16

Many thanks for producing this draft. I've identified 4 items i would like to bring to your attention. I was originally planning these as DISCUSS, but then realized that Ketan made similar observation on the same items, hence i present them to you as another set of feedback on same topics. 
(needless to say that i support Ketan's DISCUSS items)

#COMMENT1: Sections 2.3 and 5.3: changing the meaning of RLD

Section 2.3 explicitly changes the definition of Readable Label Depth from a number of LSEs to a number of 4-octet words. This is a normative change to RFC 9789, but the document header, Abstract, and Introduction say only that RFC 9994 is updated.

This is more than a terminology change. RFC 9789 defines RLD as an LSE count, assigns IGP MSD-Type 3 to it, and describes how advertised RLD and ERLD values are selected. The new definition potentially extends that advertised value beyond the BoS and across other post-stack headers before reaching the PSMH. 

Please either:
* define a separate post-stack readable-depth capability, with its own units and signaling; or
* formally update RFC 9789 and explain how existing and new RLD advertisements are interpreted, including backward compatibility and the treatment of intervening headers such as a control word, G-ACh, or BIER header.

If RFC 9789 is updated, it needs to be mentioned.

Section 5.3 also says that the encapsulating node “needs to learn” these capabilities, while all mechanisms are out of scope. RFC 9613 requires the solution to allow an LER to determine that the NAI and AD can be processed by the relevant LSRs. Please make the encapsulating-node requirement explicit and describe at least one viable compliance path: configuration, management, or a specified control-plane advertisement. See RFC 9613 requirements 47 and 48.

#COMMENT2: Sections 4.1 and 4.2: offset encoding and validation remain ambiguous

There are several related interoperability and parser-safety problems.

First, both offsets are defined in 4-octet units, but the validity checks compare the offset directly with “the size of the MPLS packet minus the size of the label stack”. Packet size is normally measured in octets. The test should compare 4 × offset with the available post-stack octets, or explicitly express both quantities in 4-octet units.

Second, Format B provides 13 data bits and Format C provides 20 data bits, but the offset uses only the rightmost 11 bits. Please state that the unused high-order bits MUST be zero on transmission and define how non-zero values are handled on receipt.

Third, the meaning of the End Offset is unclear. The equation:

End Offset - Start Offset = PSMH-Len

suggests that End Offset identifies the start of the final 4-octet word. However, “the PSMH ends at 20 octets after the BoS” sounds like an exclusive byte offset immediately following the PSMH. Those interpretations differ by one word. Please say explicitly whether the field identifies:

the first word after the PSMH; or
the final word belonging to the PSMH.

The ranges and arithmetic must then consistently follow that definition.

Fourth, the consistency check is specified only when TBA1 is present. When TBA2 is present without TBA1, the start offset defaults to zero, so the End Offset still needs to be checked against PSMH-Len.

Finally, a receiver needs an explicit check that the complete header is present:

start offset + base-header size + PSMH-Len <= available post-stack data

The current checks validate the offset and internal length sum separately, but do not clearly require the complete declared PSMH to fit within the received packet.

#COMMENT3: Sections 3.1, 5.1, and 6.2: U-bit semantics conflict with RFC 9994

Section 3.1 says that the U bit in Format B indicates the combined unknown-action handling for all NAIs in both the NAS and associated PSMH.

RFC 9994, however, defines a U bit in each Format B or Format C action LSE. It determines what happens when the action represented by that particular LSE is unknown. It is not defined as a combined NAS-wide value. 

The new text does not explain:
* how the “combined” value is calculated;
* whether the Format B U bit overrides the individual Format C U bits;
* which U bit controls an unknown MNA-PS-OP;
* whether one unknown PSNA causes the complete PSMH to be skipped or processing to continue with the next PSNA;
* how U applies to an unknown PSMH Type;
* how U applies when a node recognizes P but cannot read the complete PSMH because of its readable-depth limitation.

A simple resolution may be to state that the U bit in the Format B LSE governs the associated PSMH as a whole, without changing the meaning of the U bits belonging to other in-stack actions. If something more complex is intended, the aggregation algorithm and processing rules need to be specified explicitly.

#COMMENT4: Sections 3.2.2.1 and 9.3: contradictory applicability of opcode 127

Section 3.2.2.1 says that a packet carrying opcode 127 in the PSMH MUST be dropped, regardless of U. Table 5 nevertheless gives opcode 127 the applicability “In-Stack and Post-Stack”.

Those statements are contradictory. The current IANA Network Action Opcodes registry describes 127 as “Opcode Range Extension Beyond 127”. RFC 9994 says a packet is dropped if that extension opcode is not supported; it does not make the opcode permanently unusable.

Please either:
* mark opcode 127 as In-Stack Only or Not Applicable for Post-Stack; or
* define how the extension mechanism works in Post-Stack and use the RFC 9994 conditional “if unsupported” behavior.

Kind Regards,
Gunter Van de Velde
Routing Area Director

Thanks to the authors and the WG for their work on this document.

Especially thanks for the productive discussion and the changes to address my concerns. A few comments remain, but we are almost done.

Section 9.3, Network Action Opcodes:

828 >    The IANA table with RFC-ietf-mpls-mna-nrp-selector-07 is to be
829 >    updated to reflect [I-D.ietf-mpls-mna-nrp-selector].

I can't parse this sentence. "RFC-ietf-mpls-mna-nrp-selector-07" isn't a
real identifier -- it mixes the RFC prefix with an Internet-Draft name -- and
the draft it's presumably pointing at (draft-ietf-mpls-mna-nrp-selector-07)
is an Informative reference in this document, not something this document's
own IANA Considerations should be issuing update instructions for. If the
intent is that opcodes 3-5's Applicability entries in Table 5 are
provisional pending that draft's progress, say so in those words; as written
IANA has no action it can actually take from this sentence.

---

Section 4.1 and Section 4.2, Data field range:

479 >    Data: The data value of the LSE contains the offset from the BoS in
480 >    4-octet units.  A data value of 1 indicates that the PSMH starts at 4
481 >    octets after the BoS.  Valid range for 13-bit data in Format B LSE
482 >    and 20-bit data in Format C LSE is 0 to 2047.

523 >    Data: The data value of the LSE contains the offset from the BoS in
524 >    4-octet units.  A data value of 5 indicates that the PSMH ends at 20
525 >    octets after the BoS.  Valid range for 13-bit data in Format B LSE
526 >    and 20-bit data in Format C LSE is 1 to 2048.

Both opcodes cap their Data value identically -- 0-2047 for TBA1, 1-2048 for
TBA2 -- regardless of whether the carrying LSE is Format B (13-bit field,
natural max 8191) or Format C (20-bit field, natural max 1048575). That's a
real restriction below what either field can represent, applied identically
to two fields whose native range differs by two orders of magnitude. I don't
think this is wrong, but the document doesn't say why 2047/2048 specifically,
or why the same numeric bound applies to a 13-bit and a 20-bit field alike.
A sentence on the rationale -- an MTU-driven sanity bound? some relationship
to PSMH-Len's own 8-bit reach? -- would help an implementer who's wondering
whether they can actually rely on the full 20-bit range in Format C.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit.

Section 5.1.1, Pushing Labels:

580 >    When an MNA-capable node pushes labels as described in Section 7.1 of
581 >    [RFC9994], and copies the network actions (including their AD) from
582 >    the received topmost NAS with HbH scope in the new NAS with HbH
583 >    scope, the P bit and the PSMH start and PSMH end offset opcodes and
584 >    their ADs containing offset values from the received NAS MUST also be
585 >    copied in the new NAS In this case, more than one HbH NAS with the P
586 >    bit set share the PSMH, and is identified by having the same offsets
587 >    in the duplicate copies of the NASes.

Missing sentence break: "...MUST also be copied in the new NAS In this
case..." needs a period (or semicolon) after "new NAS".

---

Section 9.2:

779 >    This registry is added under "MPLS Network Actions" because the
780 >    container is defined by an MNA document.  Note that adding this
781 >    registry there makes discovery easier, but the Type space is not MNA-
782 >    specific, the document itself anticipates non-MNA PSMH types whose
783 >    codepoints would then be allocated from a registry added under MNA.

Comma splice: "...is not MNA-specific, the document itself anticipates..."
would read better as two sentences, or with a semicolon before "the
document".

Thank you to Roni Even for the GENART review.