Skip to main content

Telechat Review of draft-ietf-idr-sr-policy-nrp-13
review-ietf-idr-sr-policy-nrp-13-intdir-telechat-dukes-2026-07-22-00

Request Review of draft-ietf-idr-sr-policy-nrp
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2026-06-28
Requested 2026-06-18
Requested by Éric Vyncke
Authors Jie Dong , Zhibo Hu, Ran Pang
I-D last updated 2026-09-03 (Latest revision 2026-07-19)
Completed reviews Opsdir Early review of -03 by Menachem Dodge (diff)
Rtgdir Early review of -03 by Henning Rogge (diff)
Secdir Early review of -06 by Dave Thaler (diff)
Genart IETF Last Call review of -11 by Mallory Knodel (diff)
Intdir Telechat review of -13 by Darren Dukes
Assignment Reviewer Darren Dukes
State Completed
Request Telechat review on draft-ietf-idr-sr-policy-nrp by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/rSh3jkHndaWdz8WlNC5xEBtqIQ8
Reviewed revision 13
Result Ready w/issues
Completed 2026-07-22
review-ietf-idr-sr-policy-nrp-13-intdir-telechat-dukes-2026-07-22-00
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.