I support the DISCUSS positions of the other ADs, but do not have anything more to add.

Thanks to Shawn E. and Vijay G. for their SECDIR and GENART reviews.  I also appreciated the shepherds write up for this document, so thanks to Adrian F. for that.

Being a security AD I feel it necessary to comment on the security considerations:  I appreciate the blunt honesty in the security considerations in that this switch construct is inherently insecure, with some minimal mitigations.  At the same time, I bemoan the state of this security.  I have no particular advice to change this state of affairs beyond something drastic like adding security into the label stack processing with known security approaches.

Thanks to Shawn Emery for their secdir review. I tend to agree with his comments.

I support Med's discuss as it pertains to Normative References.

Section 2.3:  Is the Entropy value transmitted?  If it is, then that needs to be addressed in Section 5. (I notice that RFC 6790 says that it is not signaled)

Section 5:  Using RFC 9789, possibly referencing its Security Consideration section, would give some potential mitigations which could be used.

Thanks for the work done in this document and for addressing (either by explanations over email or by changing the text) to my previous blocking [DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/mpls/TxllnlGfeL0iQtVhT6vr8jc0USY/)

Thanks for providing this document. I do not see any transport-protocol related concerns, however I do have comments that I think ought to be addressed.

I did consider balloting "DISCUSS" on the basis that the protocol did specify how to handle receiver processing of the R and the NAL fields (see (4) and (6) below), but I decided instead to ballot "No Objection, on the basis that this looked like an omission, rather than a problem. None-the-less, I would appreciate a response to this set of comments to confirm this suspicion and explain how a receiver is expected to process these two fields.

Please find non-blocking comments below:

(1) I share the OPS-Dir IETF Last Call Review comment on specifying the options, rather than discussing these, please consider addressing this, e.g.:
/This document discusses a few options for..../
/The proposed encodings are compliant/

In Sections 2.1 and 2.2: 

(2) Please consider adding a one-line caption to each figure.

(3) I was a little by the field /NRPS/ in both figures without an explanation, please explain or perhaps consider whether the figures read better with the field set to /NRPS13/ and /NRPS20/ respectively?

(4) I could not find a description of the receiver processing for the NAL field. I expected to see words explaining how a receiver must handle a non-zero value in this field. Normally I'd expect the protocol to say: "This field MUST be set to zero on transmission and ignored upon receipt.", but another action could be defined, but needs to be specified here.

(5) The fields:|R|IHS|S| are not explained. It would at least be helpful to directly refer to a reference that defines these fields.
e.g. S:The Bottom of Stack [RFC3032], etc.

Please define for the figure at least: NAL = Network Action Length, NASL = Network Action Sub-Stack, IHS  =  I2E, HBH, or Select Scope, all of which I understand are defined in [draft-ietf-mpls-mna-hdr].

(6) If I understand, R = Reserved. If so, please specify the value when sending, and the action required when a value for R is receive, e.g."This bit MUST be set to zero on transmission and ignored upon receipt."

In Section 2.13:

(7) It was not clear to me what was intended by the two fields both labelled /NRPS/.

(8) Please add a one-line caption to this figure.

(9) Please expand NMA on first use - is this MPLS Network Actions (MNA)?

Thanks again,
Gorry Fairhurst
(WIT AD)

Thanks for writing this document. I found it well written, a nice read, and found that it explains well the intent and definitions used in a concise way.

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

Thanks for the discussion on the points in my original ballot and addressing some of them. I am moving one of the remaining points that we could not come to an agreement on into non-blocking comment.

<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?

< authors indicated that these aspects are covered to some extent in the generic draft-ietf-mpls-mna-hdr and the NRP specific aspects would be addressed in draft-ietf-teas-ns-ip-mpls >

I also have just one comment to share regarding recommendations:

262	   The choice of which Action to use when the NRP Selector could fit in
263	   multiple Actions, is open, but it is RECOMMENDED to use NRPS13 where
264	   possible unless Entropy is also to be carried and it is possible to
265	   use ENSRP20.

I believe NRPS13 is recommended because it has the best encoding efficiency and 13-bits are expected to be sufficient for majority of deployments. Also, ENRPS20 (there is a typo on line 265) gives 8-bit NRPS so it can be used only if that size is suitable AND EL is also needed. Since this document introduces 3 ways of encoding, it would be beneficial if it were to provide some more detailed explanatory text for the benefits of each and then provide the recommendations on that basis. This would help implementers and operators get some convergence on the minimum desired support given that the WG could not reach a consensus on determining one or all to be mandatory to support.

< authors indicated that they would like to stick to the text that came from WG consensus >

Thanks for addressing my DISCUSS comments.

I support the DISCUSS positions of the other ADs, particularly as regards normative references.

Hi Tony, Pavan, John, Tarek, and Israel,

Thank you for the changes made in -05 [1]; these address all DISCUSS points and many of comments in my previous ballot [2].

I appreciate that the following comments are better addressed in draft-ietf-teas-ns-ip-mpls as draft-ietf-mpls-mna-nrp-selector now depends normatively on draft-ietf-teas-ns-ip-mpls. These considerations can be inherited ** if discussed there **. I think having a sentence early in draft-ietf-mpls-mna-nrp-selector would be useful to set the expectation vs. draft-ietf-teas-ns-ip-mpls.

** Items that would be resolved in draft-ietf-teas-ns-ip-mpls **

# Missing behavior

Do we allow NRPS remarking/rewriting to take place once progressing in a forwarding path?

# Single vs. Multiple NRPs

CURRENT:
   The NRP
   Selector is used to map the packet to the associated NRP and provides
   the corresponding forwarding treatment to the packet.

May be remind that

* Slicing does not require several NRPs

* The mechanism is applicable only when there are multiple NRPs.

## More operational considerations

For example, we do say:

CURRENT:
   An NRP-capable node MUST drop a packet by default if the encoded NRPS
   cannot be mapped to a known NRP.  

### Such events need to be logged/alarm generated (syslog, for example) as this is a symptom that some classification were broken or that local configuration is not updated. Of course, such events should be rate-limited.

### Idem, counters of discarded packets should be maintained.

### There is a need to trace and isolate nodes in the network vs support of a given NRPS.

### We need a discussion about scalability. The use of slide-flow aggregates is a means to optimize state.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-mna-nrp-selector-04&url2=draft-ietf-mpls-mna-nrp-selector-05&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/mpls/JA4Qi9yXLz7MaTWYf7AAUAlbErQ/

Thank you to Vijay Gurbani for the GENART review.

I support the DISCUSS positions of Éric Vyncke, Ketan Talaulikar, Mahesh Jethanandani and Mohamed Boucadair.

I support the existing DISCUSS positions and will not re-iterate any points there.

One minor point: Section 2.3 says:
>      Entropy Label [RFC6790].  While the RFC 6790 Entropy Label has
>      some restrictions to avoid collisions with the reserved label
>      space (0-15) [RFC3032], those restrictions are not necessary for
>      the Entropy Value and do not apply.  The packet carrying the

Why do these restrictions not apply? It isn't obvious (at least to me) and probably warrants either an in-line answer or a reference to another section of the document.