MPLS Network Actions for Network Resource Partition Selector
draft-ietf-mpls-mna-nrp-selector-06

# Éric Vyncke INT AD comments for draft-ietf-mpls-mna-nrp-selector-04
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Adrian Farrel for the shepherd's *detailed* write-up including the WG *rough* consensus *and* the justification of the intended status.

Other thanks to Jen Linkova, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-mpls-mna-nrp-selector-04-intdir-telechat-linkova-2026-04-24/ (and I have yet to read a reply by the authors)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Sections 2.1, 2.2, 2.3

I agree with Jen INT-directorate review and raises to a DISCUSS as it is unclear (hence non implementable). The text and the graphics appear to be disjunct and unrelated. Not all header fields are explained (either in this document or by adding a reference to another document). I note that Mahesh's ballot raised similar concerns.

### Section 2.5

A MUST followed by later opposing MAY is a SHOULD with guidance.

```
An NRP-capable node MUST drop a packet by default if the encoded NRPS cannot be mapped to a known NRP. This requirement MAY be overridden by an operator-specified policy, the specification of which is outside the scope of this document.
```

### Deployment (Section 3)

Please be clear whether all devices must have this feature enabled (e.g., if not the case, then traffic is still flowing but without isolation/QoS/...).

### Section 5

Please add some privacy considerations as the NRP itself may leak some information about the packet content (even if transport/application crypto is used). It is also unclear whether the NRP values are opaque.

I will let the SEC ADs to comment further, but I find the security considerations section rather light.

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

I have a few points that I would like to discuss.

#Updated for v05 with removal of points that have been addressed (see email thread for discussion details) - the original numbering has been retained.

<discuss-2> The actions in this document as specified to be "valid for all scopes". Based on my understanding of NRP, I would have expected it to be HBH scope per https://www.ietf.org/archive/id/draft-ietf-mpls-mna-hdr-21.html#section-5.3 ... Note: one of the scopes is "reserved for future" and hence unspecified, so it makes be wonder how the NRPS action can be known to be valid in that scope too. If the action is indeed valid for other than HBH scope, then can you please explain or provide pointers where this is covered?

<discuss-3> The document specifies the 3 NRPS opcodes for the MNA sub-stack. It does not cover other aspects such as processing of the MNA Sub-Stack with NRPS (encapsulation, handling with push/pop along transit, PHP, egress) or the signalling of the capability in control plane. Are those aspects expected to be covered in some other document? If so, would it be possible for someone to implement this solution without those aspects being specified?

The shepherd's write-up (thanks, Adrian) is candid that WG consensus was only rough, that no implementations have been reported, and that five interconnected technical issues generated reservations from participants. I have several DISCUSS items, primarily around diagram ambiguities that may reflect genuine technical issues. Most of them are easy to address, except maybe the last one.

Section 2.1, paragraph 5
>    *  In-Stack Data: The NRPS13 Action carries 13 bits of ancillary
>       data.  The NRPS is encoded in the 13 bits.  The packet carrying
>       the NRPS13 action should be given the forwarding treatment
>       specified by the associated NRP policy.

This lowercase "should" is ambiguous. If it is intended as normative 
(i.e., SHOULD per BCP 14), it must be capitalized. If it is descriptive 
prose, the statement is unclear — what does an implementation do when 
it cannot apply the NRP-policy-specified forwarding treatment?

The INTDIR reviewer flagged this as well. Please either capitalize and 
justify the requirement level, or rewrite as plain English with explicit 
normative behavior specified separately.

This applies to Section 2.2, and 2.3 also.

Section 2.2, paragraph 1
>     0                   1                   2                   3
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Opcode=TBA2 |             NRPS              |S|  NRPS |U| NAL |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The label "NRPS" appears twice — separated by the S bit. The text says 
"The NRPS is encoded in the 20 bits" suggesting a single 20-bit field, 
yet the diagram shows it split around the S bit position. Can this be 
explained?

Section 2.3, paragraph 1
>     0                   1                   2                   3
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Opcode=TBA3 |        Entropy        | NRPS  |S|  NRPS |U| NAL |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Similarly, the NRPS field again appears split, and the text says, "The least 
significant 8 bits of ancillary data is the NRPS," — but the diagram 
seems to show an additional NRPS fragment appearing after the S bit.

Is the NRPS a contiguous field, or is it split across the S-bit boundary 
by the LSE format constraint? If it is split, the diagram must label 
the two parts distinctly (e.g., NRPS[19:8] and NRPS[7:0]) and the 
text must explain how an implementation assembles them. If it is 
contiguous and the S bit position allows it, the diagram must be 
corrected. This was also raised by the INTDIR reviewer (thanks, 
Jen Linkova). The GENART reviewer (thanks, Vijay Gurbani) similarly 
flagged bit-field boundary alignment for this section. This needs 
to be technically resolved, not just editorially corrected.

Section 2.4, paragraph 0
>    Multiple NRPS Actions may be encoded in a single packet.  An
>    implementation MUST use only the top-most NRPS Action to determine
>    the packet's forwarding treatment.  An implementation that finds a
>    subsequent opcode of any of the three NRPS Actions in the label stack
>    MUST ignore it.  The specific scenarios where multiple NRPS Actions
>    are present in the label stack are outside the scope of this
>    document.

This specifies that when multiple NRPS Actions appear in the label stack, 
the top-most one governs, and further ones MUST be ignored. It then states: 
"The specific scenarios where multiple NRPS Actions are present in the label 
stack are outside the scope of this document."

This is architecturally incomplete. A reader implementing this specification 
encounters a hard MUST behavioral requirement (use only the top-most; ignore 
others) for scenarios that are not defined anywhere accessible. The question 
is - does a document exist today or in progress that defines these scenarios? 
If so, it should be cited. If not, the WG should document at a minimum the 
motivating use cases to prevent incompatible implementations from arising 
independently.