[Int-dir] Re: draft-ietf-idr-sr-policy-nrp-13 telechat Intdir review

[Susan Hares <[e-mail]>]

Darren: 

Thank you for the updated Intdir review.  As shepherd for the draft, I will chat with the authors today.  

I have a few questions for my understanding of your review:

draft-ietf-spring-sr-policy-nrp-02 states in section 3.1 

  " *  When signaling is via BGP SR Policy, the method to uniquely signal
      an individual candidate path along with its NRP ID is described in
      [I-D.ietf-idr-sr-policy-nrp].  The state of candidate paths
      associated with NRP can be collected via BGP-LS
      [I-D.ietf-idr-bgp-ls-sr-policy-nrp]."

These NRPs are the control plane NRP (not the NRP Selector). 
Draft-ietf-idr-sr-policy-nrp states in Section 2. 

   *  NRP ID: A 32-bit identifier which uniquely identifies an NRP in an
      NRP domain [I-D.ietf-teas-ns-ip-mpls].  Value 0 is reserved, which
      MUST NOT be used by the sender.  On receipt of the NRP ID TLV, if
      the NRP ID is 0, the NRP ID TLV MUST be ignored.

Question on your issue 1: 
The BGP protocol implementation does minimal checking on the syntax ranges, but the content of the values is checked by SRPM based on the current information in the SRPM.  So, "no validation" is not quite correct.  As long as we agree upon the content, shall I let the authors work on the text?  

Question on your issue 2:  I think we are on the same concept.  But I'd like to check.   
An NRP ID = 0, will cause the subTLV with NRP ID to be malformed. A malformed subTLV will be ignored and not passed to the SRPM.  Other valid SubTLVs within the be SR Candidate path TLV associated with the NLRI will be passed to the SRPM.  So.. does this align with your comment? 

Sue Hares 
(IDR co-chair/shepherd)

-----Original Message-----
From: Darren Dukes via Datatracker <[e-mail]> 
Sent: Wednesday, July 22, 2026 11:55 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-idr-sr-policy-nrp-13 telechat Intdir review

Document: draft-ietf-idr-sr-policy-nrp
Title: BGP SR Policy Extensions for Network Resource Partition
Reviewer: Darren Dukes
Review result: Ready with Issues

I was asked to review revision 11 of this draft as part of the IntArea directorate. Since then revision 13 has been posted and I've revised this review to that version. This review is for the Int AD IESG review and may be considered by authors as last call review comments.

General Observations:
The specification is compact and the wire encoding is straightforward.
The encoding and the separation between BGP validation and SR Policy Module (SRPM) semantic processing are consistent with RFC 9830.

After reviewing the draft and its normative references I'm left with one ISSUE around validity checking.

This draft defines the NRP ID Sub TLV and its encoding, but does not specify, nor fully abdicate, the validity checking of the NRP ID to draft-ietf-spring-sr-policy-nrp.

draft-ietf-spring-sr-policy-nrp-02 does not yet define deterministic behavior when a syntactically valid NRP association cannot be used by the receiving head end.

Further more this draft contains select normative language about how NRP IDs are associated with candidate paths, but that text says essentially nothing normative.

This draft states in Operational Considerations:
    Although the updates to SR Policy architecture in
   [I-D.ietf-spring-sr-policy-nrp] allow different candidate paths in
   one SR Policy to be associated with different NRPs, in normal network
   scenarios it is considered that no matter which candidate path is
   active, the association between an SR Policy and NRP is consistent.
   In such case all candidate paths of one SR Policy SHOULD be
   associated with the same NRP.  The cases where different candidate
   paths of an SR Policy are associated with different NRPs is valid but
   NOT RECOMMENDED.

This does not tell an implementor of this specification anything other than "anything other NRP ID 0 is valid".

ISSUE 1: I suggest this text say something deterministic or is removed completely and replaced with text stating "NRP ID validation is out of scope and defined in draft-ietf-spring-sr-policy-nrp"

ISSUE  2 (not an issue for this draft): In addition draft-ietf-spring-sr-policy-nrp should be updated at the earliest to specify normative validity checking of NRP IDs and the requirements around their permitted values in SR Policy candidate paths, and their lack of existence when NRP ID 0 may be received but the TLV is ignored.