[spring] Re: About the relationship between cadidate path and segment lists in SR Policy Architecture

[Ketan Talaulikar <[e-mail]>]

< 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=
[e-mail]> 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.


>
>
> 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.


> 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.


> 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.

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>