Hi Ketan, Thanks for your further explanation, it helps to better understand the relationship between SL and CP.
Please see some further inline with [Jie2]: From: Ketan Talaulikar <[email protected]> Sent: Thursday, February 12, 2026 8:44 PM To: Dongjie (Jimmy) <[email protected]> Cc: Dongjie (Jimmy) <[email protected]>; [email protected]; [email protected]; idr-chairs <[email protected]>; [email protected] Subject: Re: [spring] About the relationship between cadidate path and segment lists in SR Policy Architecture < as a WG participant and co-author of RFC9256 > Hi Jie, Please see inline below for follow-up with KT2. I hope it explains the technical and semantic reasons behind why SL is an entity under a specific CP and not something independent by itself. As a reminder, the purpose of multiple SLs is load-balancing - if there was going to be a single SL then it could as well be collapsed with the CP itself. Also, the SL(s) fulfil the objective and constraints of a specific CP - this is why they belong to that specific CP. [Jie2] Yes the SL(s) need to fulfil the objective and constraints of a specific CP, and the same sequence of segments could meet the objective of different CPs. This is part of the reason SR avoids per-path state in the network. I think the point here is whether the same sequence of segments need to be referenced by the same or different segment list IDs when associated with different CPs. On Thu, Feb 12, 2026 at 3:56 PM Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> wrote: Hi Ketan, Thanks for sharing your view on this. Please see some replies inline with [Jie]: From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Sent: Wednesday, February 11, 2026 9:04 PM To: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; idr-chairs <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [spring] About the relationship between cadidate path and segment lists in SR Policy Architecture < only as co-author of RFC9256 > Hi Jie/All, Thanks to Jie for starting this discussion in the SPRING WG. Please check inline below for clarifications and look forward to the discussions in the WG. On Wed, Feb 11, 2026 at 4:01 PM Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> wrote: Dear SPRING WG, In a recent review of draft-ietf-idr-sr-policy-seglist-id-06 in IDR WG, I have one question about the scope of the segment list ID. It is further related to the relationship between candidate path and segment lists in the SR Policy Architecture. KT> Besides the BGP SR Policy address-family draft pointed by Jie (https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-seglist-id-08.html#section-2.1), an identifier for segment lists was found to be required also for BGP-LS (https://www.rfc-editor.org/rfc/rfc9857.html#section-5.7.4) and PCEP (https://www.ietf.org/archive/id/draft-ietf-pce-multipath-19.html#section-4.2). Note that the names are different due to the objects/TLVs in respective protocols but the semantics are identical. [Jie] Thanks for sharing the pointers to other related documents. It helps to give a full picture of this topic. As described in section 2.1 of this draft, the segment list ID is a 32-bit non-zero number that serves as the identifier associated with a segment list. And it says: the scope of this identifier is the SR Policy Candidate path. I didn’t find the description about segment list ID and its scope in RFC 9526 (SR Policy Architecture. KT> This is correct. The Segment List ID was introduced in all these protocols as a result of protocol encoding and other operational requirements. RFC9526 does not define any identifier for a SL. [Jie] Yes. RFC 9256 defines the SR Policy architecture, the encoding belong to the protocol-specific SR Policy extensions. While in this case, the relationship between candidate path and segment list defined in the architecture may have some impact on the encoding/scope of the IDs. Section 2.2 of RFC 9256 describes the relationship between candidate path and segment list, while it is not clear whether a segment list is bound to a candidate path, or it can be relocated to another candidate path without other change? If it is the latter case, it seems the segment list ID should not be scoped under a specific candidate path. KT> It is the former case - i.e., SL belongs to a CP. The hierarchy is also specified in https://www.ietf.org/archive/id/draft-ietf-spring-sr-policy-yang-06.html ... I don't see a concept of "relocation" here; it would be a different SL under a different CP. Note, that the SL is meant to realize the objectives of a specific CP. This does not preclude the realization of the objectives of two different CPs within an SR Policy or even different SR Policies via the same sequence of segments. [Jie] Maybe “relocation” is not a good example. Another example is as what you said, the same list of segments are used as the segment list under multiple candidate paths, which may belong to the same of even different SR Policies. In this case, to my understanding there is just one instantiation of this segment list in the data plane, which is referenced by multiple candidate paths. Should we call them different SLs or the same SL? At least they would share some common properties. Thus my question to RFC 9256 is that whether a segment list can be referenced by multiple candidate paths, the word used in the RFC is “associate”, which is not clear whether the association between segment list and candidate path is 1:1 or can be 1:N. KT2> Let us take your example. Say we have two SLs under two CPs (only one SL under each CP to keep things simple) belonging to two different SR Policies with different intent. At time T0, the path computation provides the exactly same ordered list of segments and so a single instantiation of the SL in the forwarding can be perhaps shared (well, if someone is looking for counters and accounting per segment list or CP or Policy then they can't be shared). Then at time T1, due to a topology change, the path computation provides a different ordered list of segments - now the sharing cannot happen anymore. So, you see, the two SLs were separate independent entities bound by the characteristics of their respective CPs. Just because they happened to look similar at one point does not make them a singular entity. Also factor in how this turns out when there are multiple SLs under a CP with each SL having its weight for load-balancing. IMHO semantics are important. [Jie2] In this example, if at time T1 the path computation provides a different ordered list of segments, and if the updated is provisioned via BGP, the candidate path would be updated via BGP, and the associated segment lists together with the segment list ID can also be updated. Do you think the segment list ID should remain unchanged in this case? If so, to my understanding this separates the segment lists in each CPs from their instantiation in the data plane, and the result is the same segment list ID may refer to different ordered list of segments at different time. This may not be the expected behavior for some scenarios, where an identifier to reference a specific ordered list of segment is needed. Another related point is how a segment list should be identified/referenced in the control plane/management plane, does it require to use <candidate path ID + segment list ID>, or it can be referenced directly using the segment list ID? This could have impact on other protocol extensions related to the segment list. KT> I've shared the pointers to the various documents (control and management planes related). Given that SL belongs to a CP, and the CP is the unit of signaling in various control plane protocols, I've not seen a requirement for directly referencing a segment list. [Jie] Min just gave an example of referencing a segment list in LSP Ping for SR-MPLS (RFC 9884). As we can see, it requires to carry a long list of information to uniquely identify a segment list in control plane, not just the segment list ID. Such overhead may be OK for some control plane mechanisms, while for some others it would be better if the referencing could be more efficient/direct. Please note such simplification can be achieved by allocating each segment list under each candidate path with a unique ID on the headend node, regardless of whether there are sharing the same sequence of segments or not. KT2> I would caution against trying saving some bytes in control plane signaling at the cost of breaking the clear and well-defined semantics of today. I'll watch this thread for the views of other WG participants while I switch to listening mode :-) [Jie2] Saving the bytes in control plane signaling is just one by-product. As mentioned in above discussion, this is more about whether the segment list ID can uniquely identify an ordered list of segments on the headend node, or it is an abstract reference which may point to different ordered list of segments in data plane. It would be good to hear the opinions of other WG participants on this. Best regards, Jie Thanks, Ketan Best regards, Jie Thanks, Ketan After some discussion with the IDR chairs and Ketan, we think it is necessary to bring this to the SPRING WG and ask for your views and opinions. Best regards, Jie _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
