[spring] Re: Issue raised in RTG-DIR review of draft-ietf-idr-sr-policy-nrp-04 - Requesting response in 1 week

[Susan Hares <[e-mail]>]

If anyone in these WGs (IDR, Spring, PCE, or TEAS) disagrees that the
32-bit NRP-ID passed in the BGP SR Policy TLV in the NRP Sub-TLV
in the Tunnel Encapsulation Attribute, as described
draft-ietf-idr-sr-policy-nrp-04, is a control Plane NRP-ID,
please let me know within 1 week.  You can simply respond to this email.

If no objects, on 12/18/2025, I will request publication of the draft-ietf-idr-sr-policy-nrp-04
based on that assumption.

It is my understanding based on draft-jiang-spring-sr-policy-nrp
that the SRPM in the head end maps this control plane NRP-ID
to a Data plane NRP-ID (which may be a different length).
(The email below summarizes the logic from draft-jian-spring-sr-policy-nrp)

The Spring WG currently plans to run an adoption call (according to Alvaro)
for draft-jiang-spring-sr-policy-nrp-04 in January 2026.


Thank you,
Sue Hares


From: Susan Hares <[e-mail]>
Sent: Wednesday, December 10, 2025 8:46 PM
To: idr@ietf. org <[e-mail]>; SPRING WG List <[e-mail]>; Path Computation Element Discussion List <[e-mail]>
Cc: Susan Hares <[e-mail]>
Subject: Issue raised in RTG-DIR review of draft-ietf-idr-sr-policy-nrp-04

Greetings:

There was an issue raised by the RTG-DIR review of
draft-ietf-idr-sr-policy-sr-nrp-04 that occurred post WG LC
for this draft.

The Reviewer questioned whether NRP ID in
draft-ietf-idr-sr-policy-nrp-04 is a control plane NRP ID, a Data Plane ID or both.
In my discussions with the authors during IDR WG LC, they
Pointed out the NRP ID in the BGP subTLV is a control plane ID.

IDR has decided to publish draft-ietf-idr-sr-policy-sr-nrp-04.txt.
As the document shepherd, I am checking about the
Appropriate resolution of the RTG-DIR comment.
As the shepherd, I reviewed the following documents to get the answer:

draft-ietf-idr-sr-policy-nrp-04
draft-ietf-idr-bgp-ls-policy-nrp-02
draft-jiang-spring-sr-policy-nrp-04
draft-ietf-pce-pcep-nrp-00
draft-ietf-6man-enhanced-vpn-vtn-id-012,
draft-ietf-mpls-mna-nrp-selector-00, and
draft-ietf-teas-nrp-scalability-07

Based on the text in draft-ietf-idr-sr-policy-nrp-04,
I expected to see this answer clearly laid out
in draft-jiang-spring-sr-policy-nrp-04.
My reading of this individual draft from spring came up with
questions:

1) draft-jiang-spring-sr-policy-nrp-04 is on adoption queue (at the bottom).
when will Spring review the validity of section 3?

2) Is the following summary based on Spring, IDR, TEAS, and PCE documents?
If it is not correct, what is the correct summary of NRP ID usage.
If it is correct,  what are the potential failures in the NRP usage
as described?

3) Has anyone in SPRING or TEAS done a full system review?
If so, can you send the reference.

Since I suspect, IDR WG document will be the first to the IESG
I want to make sure the IDR document fits into the entire framework.

Comments?

Cheerily, Sue Hares

===============
Description of sequence:
In draft-ietf-idr-sr-policy-nrp-04, it describes
a Control Plane NRP passed in BGP in the Tunnel Encapsulation Attribute
in the SR Policy (15) tunnel type as a NRP subTLV.  This attribute of the
associated with SR Policy NLRI.

In discussions, I understood that the
32 bit Control Plane NRP calculates the route.
draft-jiang-spring-sr-policy-nrp-04
states in section 3.1

"NRP Selector ID" of a candidate
path is utilized to identify the resources corresponding to the
forwarding path of all segment lists within an SR Policy.
It is a 32-bit value serving as an identifier for the Network
Resource Partition."

draft-jiang-spring-sr-policy-nrp-04 states 6 things (1-6 below):
1) If this NRP Selector ID is signaled by configuration, it meaning is based on
Implementor's configuration model.

2) If this NRP Selector ID is signaled via PCEP, the method to uniquely signal
an individual candidate path along with its NRP
selector ID is described in draft-ietf-pce-pcep-nrp].

Please note:  that in draft-ietf-pce-pcep-nrp-00, the ID document
has a flag for indicating whether the
capability handles Data Plane has NRP Capability.
For PCC, it can flag the PCC supports NRP in Data Plane (SRv6 or SR-MPLS).
For PCE, it supports control path computation.

3) If BGP SR Policy (draft-ietf-idr-sr-policy-nrp-04),
the NRP Selector ID is distributed via BGP-SR
and data is collected via BGP-LS.

4) By configuration, one Candidate Path (SR Policy Candidate Path),
All segment lists must share the same NRP Selector ID; otherwise, it is invalid.

Please note: Section 3.2 describes validation (which updates RFC9256).
Since the Candidate Path final validation is done in the SRPM,
the check for the same NRP Selector ID per Candidate Path is done there.

5) An SR Policy may have multiple SR Policy Candidate routes, and it is possible
that each SR Policy Candidate Route has a unique NRP Selector ID.

6) When a candidate path of an SR Policy is instantiated within an NRP,
Then a network-wide NRP Selector ID is used to identify the NRP.

Note: Since the control plane NRP may be 32 bits from BGP or PCE,
and the data plane encoding (SRv6, SRmpls) could be 13 bits, there
must be a mapping between 32 and 13 bits at the dataplane level.