< 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. On Thu, Feb 12, 2026 at 3:56 PM Dongjie (Jimmy) <[email protected]> wrote: > 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) <jie.dong= > [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. > > > > > 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 :-) 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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
