Hello Jie, If one SR Policy is only for one NRP, I don't think we need any slice id for the SR policy, just steer the specific traffic to the policy, the isolation QoS will be satisfied by the SR policy since it is built only for the specific NRP.
Regards, Zhenqiang Li China Mobile lizhenqi...@chinamobile.com From: Dongjie \(Jimmy\) Date: 2025-07-16 11:41 To: lizhenqi...@chinamobile.com; Susan Hares; 'spring-chairs' CC: spring; i...@ietf.org Subject: [Idr] Re: [spring] Re: Need Spring review of draft-ietf-idr-sr-policy-nrp-03 Hi Zhenqiang, Thanks for your comments on the relationship between SR Policy and NRP. To my understanding an SR Policy can be considered as the SR instantiation of TE tunnels. When associated with an NRP, an SR Policy can be enhanced as SR-TE tunnels with resource guarantee. From this perspective, it would be better to associate an SR Policy with one NRP. That said, as SR segments can be shared by multiple SR Policies, it is possible to share a common path among multiple resource guaranteed SR Policies by using the same SID list. Hope this helps. Best regards, Jie From: lizhenqi...@chinamobile.com <lizhenqi...@chinamobile.com> Sent: Wednesday, July 16, 2025 9:27 AM To: Susan Hares <sha...@ndzh.com>; 'spring-chairs' <spring-cha...@ietf.org> Cc: spring <spring@ietf.org>; i...@ietf.org Subject: [spring] Re: Need Spring review of draft-ietf-idr-sr-policy-nrp-03 Hello Sue and all, I believe the questions listed below are very important. In my opinion, NRP should be decoupled from SR Policy. SR Policy is mainly a path that specific packets will traverse. Several NRPs may share a common path defined by a SR Policy if the network resource required by each NRP can be satisfied. Regards, Zhenqiang Li China Mobile lizhenqi...@chinamobile.com From: Susan Hares Date: 2025-07-13 07:02 To: 'spring-chairs' CC: spring Subject: [spring] Need Spring review of draft-ietf-idr-sr-policy-nrp-03 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]. 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
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
