[spring] Need Spring review of draft-ietf-idr-sr-policy-nrp-03

[Susan Hares <[e-mail]>]

Joel, Alvaro, Bruno and Spring WG:

IDR requests an in-depth review of draft-ietf-idr-sr-policy-03.

Context:
During the WG LC for draft-ietf-idr-sr-policy-nrp-03 (3/14 to 4/4/2025),
(https://mailarchive.ietf.org/arch/msg/idr/MsMiPqRTmOfG7mkvtJd_8n2hC-0/)
the responses to the IDR WGL LC from Zafar
(https://mailarchive.ietf.org/arch/msg/idr/5Puky_VmsAhHGp1bEIqwVnPBSDc/
and Stephane (https://mailarchive.ietf.org/arch/msg/idr/5Puky_VmsAhHGp1bEIqwVnPBSDc/)
 claimed that draft-ietf-idr-sr-policy-nrp-03

should have a normative dependency on draft-jiang-spring-sr-policy-nrp  and
(https://datatracker.ietf.org/doc/draft-jiang-spring-sr-policy-nrp/)
This document does not appear to be in the Spring queue for WG adoption.

Can you provide input on the debate between Spring/IDR participants and Authors:

Zafar and Stephane contend that:
Issue-1) NRP ID  is depend on section 4 ( Steering into an SR Policy with NRP) in draft-jiang-spring-sr-policy-nrp-03.

   "The method of traffic steering aligns with the description in
   Section 8 of [RFC9256]<https://datatracker.ietf.org/doc/html/rfc9256#section-8>. If the SR Policy candidate path selected as
   the best candidate path is associated with an NRP, the headend node
   of the SR Policy SHOULD encapsulate both the segment list and the
   data plane identifier of the associated NRP Selector ID to the
   header of packets steered to the SR Policy.  The segment list is
   used to instruct the path the packets need to traverse, and the NRP
   Selector ID is used by each node along the path to identify the set
   of local network resources allocated to the NRP for the processing
   of the packet. When an SR policy's active path contains an NRP
   Selector ID, specific handling is necessary, as follows:


   o When steering traffic to the SR policy through Per-Destination
      Steering or Policy-Based Routing, after adding the corresponding
      segment list encapsulation for the SR policy, NRP encapsulation
      is also required. The specific NRP encapsulation details are
      outside the scope of this document.

   o Similarly, When steering traffic to the SR policy via the
      BindingSID, after adding the segment list encapsulation for the
      SR policy, NRP encapsulation is required. The specific NRP
      encapsulation details are outside the scope of this document.


First Question(1-1) This document does not appear to be in the Spring queue for WG adoption.
Where is this work in SPRING's queue.

Second Question (1-2): Are Zafar and Stephane objections due to a tight binding
Between the information carried in BGP and the SRPM processing?

My understanding is that the SRPM in the headend is selecting the best candidate path
(draft-ietf-idr-sr-policy-safi-13, in RFC editor queue).
BGP validates the SR Policy path at the BGP level, and then the BGP process
hands the information to the head-end node's SRPM. In my understanding the
binding between BGP and SRPM is loose. BGP hands information to SRPM
and the SRPM adding policy + information + processing before handing it to the data plane.

Zafar states (pointing to a tight binding):
How [does this draft] to handle the case where NRP ID in BGP message is out-of-range
or NRP is not supported by the SR policy headend.

[Jie Dong author response:]  As described in section 2, in that case the SR Policy CP is considered invalid.

Third Question (1-3): Does the Spring WG and Spring WG Chairs feel that the
draft-jiang-spring-sr-policy-nrp should be a normative reference for
draft-ietf-idr-sr-policy-nrp-03?  If so why?


Issue-2) draft-ietf-idr-sr-policy-nrp-03 should have a normative dependency on
Dataplane IDs (draft-ietf-6man-enhanced-vpn-vtn-id (SRv6) and
SR-MPLS). [Zafar and Stephane]

The authors of draft-ietf-idr-sr-policy-nrp-03 (Jie Dong, Zhibo Hu, and Ran Pang)
claim that:

"[Jie] The 32 bit NRP ID is a control plane ID, which can be mapped to an data plane NRP selector.
The encoding of the data plane NRP ID is out of the scope of this draft (draft-ietf-idr-sr-policy-nrp-03).


Question 2-1: What does Spring WG feel about the concept of NRP ID BGP being mapped to an SRv6 or SR-MPLS data plane?

[Zafar]Can different CPs have different NRP IDs? Is NRP ID a policy level attribute or a CP level attribute? Can different SID-lists have different NRP-IDs? The answers have implications on the protocol extensions.

[Jie] This draft focuses on the BGP SR Policy extensions to associate an SR Policy candidate path with an NRP. The encapsulation of NRP Selector in data plane is specified in drafts in 6MAN and MPLS WG, and is out of the scope of this draft


Issue-3) [Zafar] Why is it domain significant? What happens in multi-domain cases?
[SR] hierarchical or stitched policies in different domains.
These aspects are to be discussed in the Spring draft. IDR should just carry what is defined in Spring.
[Jie] The NRP sub-TLV applies to both SR-MPLS and SRv6, it does introduce additional processing in interworking cases.

This draft focuses on the scenarios where the SR Policy CPs are within the same administrative domain. The multi-domain NRP case is described in other drafts (see draft-li-teas-composite-network-slices.]

Question 3-1: Does raft-ietf-idr-sr-policy-nrp-03 clearly explain it is a
multi-domain single Administrative Domain? If a solution restricted to a single Administrative
domain (due to security issues) acceptable?


Cheerily, Sue Hares
IDR WG chair
IDR Document shepherd