Hi Ketan, Thanks for sharing your view on this. Please see some replies inline with [Jie]:
From: Ketan Talaulikar <[email protected]> Sent: Wednesday, February 11, 2026 9:04 PM To: Dongjie (Jimmy) <[email protected]> Cc: [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 < 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. 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. 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]
