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 <[email protected]> Sent: Wednesday, December 10, 2025 8:46 PM To: idr@ietf. org <[email protected]>; SPRING WG List <[email protected]>; Path Computation Element Discussion List <[email protected]> Cc: Susan Hares <[email protected]> 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.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
