Hi spring and idr,

I think this document is ready for adoption, and I support this adoption. Below 
are my responses:

1) Can composite SR Candidate Paths be limited to be created from only explicit 
(aka Static) BGP SR Candidate path?
•      If so, how is it done (technically)?
•      What text should be found in draft-jiang-idr-sr-policy-composite-path-04 
on this limited?
•      Is it there?

This draft distributes a composite candidate path "container" that references 
constituent SR Policies by color.
It does NOT create, generate, or install the candidate paths (segment lists or 
dynamic paths) of those constituent SR Policies.
It does not change or restrict anything and fully complies with the definition 
in RFC9256.

2) Is the limitation of composite path to specific BGP sources an appropriate 
use of the composite concept from SPRING?

It is a Complementary Extension to RFC 9830

It does not alter the existing deployment methods for SR policies; it only 
extends BGP to support the distribution of composite candidate paths based on 
[RFC9830].

3) How does this interact with the PCE composite CPs?

Both BGP and PCE can signal composite paths.

If a constituent policy is available via both protocols, the headend uses 
standard SR Policy selection rules.

This draft does not modify these rules.

Niangen

发件人: Susan Hares <[email protected]>
发送时间: 2026年7月11日 0:09
收件人: 'SPRING WG' <[email protected]>; idr@ietf. org <[email protected]>
主题: [spring] [BGP-SR-TE] Request for information - prior to adoption call for 
draft-jiang-idr-sr-policy-composite-path

Greetings Spring and IDR:

Please note that IPR may exist for this technology.  If you are participating 
in this discussion and know of IPR, please see the IETF IPR rules.

The authors of draft-jiang-idr-sr-policy-composite-path-04 have requested WG 
LC.  During IETF-125, I spent a lengthy time discussing the issues of creating 
BGP routes from any dynamic source (e.g. IGP).  The authors indicated that 
these BGP composite paths would come from explicit SR Policy Candidate 
Policies, which are statically configured.

This document’s abstract states:

   SR Policy Architecture [RFC9256] defines the concept of a Composite

   Candidate Path. A regular SR Policy Candidate Path outputs traffic

   to a set of Segment Lists, while an SR Policy Composite Candidate

   Path outputs traffic recursively to a set of SR Policies on the same

   headend. This document defines extensions to BGP to distribute SR

   policies carrying composite candidate path information. So that

   composite candidate paths can be installed when the SR policy is

   applied.


The authors have indicated that the source for the composite policy would be 
BGP explicit SR Candidate Paths.

The SR policy in the composite path can be distributed

   by BGP as described in [RFC9830], by PCEP as described in [RFC9862], or 
through static configuration.

I have 3 groups of questions as the shepherd for this draft:

1) Can composite SR Candidate Paths be limited to be created from only explicit 
(aka Static) BGP SR Candidate path?

If so, how is it done (technically)?
What text should be found in draft-jiang-idr-sr-policy-composite-path-04 on 
this limited?
Is it there?

2) Is the limitation of composite path to specific BGP sources an appropriate 
use of the composite concept from SPRING?

3) How does this interact with the PCE composite CPs?

Cheerily, Sue Hares
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to