+1 to Ketan's opinion.
RFC 9884 specifies LSP Ping for SR Path SID, in that document Figures 3[1] and
6[2] show the needed fields for identifying a specific segment list. Without
the context of a candidate path, I don't think the 32-bit Segment-List-ID
itself can be used to identify a specific segment list.
[1] https://datatracker.ietf.org/doc/html/rfc9884#section-3.3
[2] https://datatracker.ietf.org/doc/html/rfc9884#section-3.6
Cheers,
Xiao Min
Original
From: KetanTalaulikar <[email protected]>
To: Dongjie (Jimmy) <[email protected]>;
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;idr-chairs <[email protected]>;[email protected]
<[email protected]>;
Date: 2026年02月11日 21:04
Subject: [spring] Re: About the relationship between cadidate path and segment
lists in SR Policy Architecture
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
< 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]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
