Hi Sue, I agree with Yimi and support adoption of this draft.
In fact, [RFC9256] defines the concept of a Composite Candidate Path. Composite Candidate Paths can be distributed via PCEP, as described in section 3.6 of [I-D.draft-ietf-pce-multipath]. [RFC9830] only lacks specification on how to provision Composite Candidate Paths. draft-jiang-idr-sr-policy-composite-path simply adds the required BGP extensions for this purpose. Regarding the source of the SR policy contained in the composite path, these SR policies can be provisioned through RFC9830, RFC9862 or static configuration. draft-jiang-idr-sr-policy-composite-path makes no changes to the SR Policy framework definition. If an SR Policy is delivered via BGP or PCEP, its processing rules remain consistent with those defined in RFC9256. Thanks, Allan On Fri, Jul 24, 2026 at 5:13 PM Susan Hares <[email protected]> wrote: > Yimi: > > > > I agree that the authors should explicitly address limiting (or configured > limits) on the number explicit BGP paths. > > > > I am happy to hear that the documentation convinces you feel the “draft > ensures that BGP extensions do not interfere with PCE operations, and any > conflicts are resolved per RFC 9256.” > > > > Your answer has completely answered my questions. > > > > Do others in Spring agree with her view? I need to hear from a number of > Spring WG members (and the Spring chairs) on this topic. IDR will not > adopt IDR technology for composite links until we have a strong consensus > from Spring. > > > > Cheerily, Sue > > > > *From:* yimi zhang <[email protected]> > *Sent:* Sunday, July 19, 2026 10:38 AM > *To:* Susan Hares <[email protected]> > *Cc:* SPRING WG <[email protected]>; idr@ietf. org <[email protected]> > *Subject:* Re: [spring] [BGP-SR-TE] Request for information - prior to > adoption call for draft-jiang-idr-sr-policy-composite-path > > > > Hi Sue， > > > > > > > > Thank you for raising these questions. Below are my answers, tagged <Yimi>: > > > > > > > > 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? > > > > <Yimi> I think that the current draft does not explicitly address limiting > constituents to explicit BGP paths. In the next revision, the authors meybe > add text to clearly state how to create composite SR Candidate Paths. > > > > 2) Is the limitation of composite path to specific BGP sources an > appropriate use of the composite concept from SPRING? > > > > <Yimi> The composite path concept in RFC 9256 is agnostic to the source of > its constituents. I believe that even Limiting constituents to explicit BGP > paths is a valid use case that aligns with SPRING’s goal of providing > flexible policy composition. > > > > 3) How does this interact with the PCE composite CPs? > > > > <Yimi> I think that BGP-signaled composite paths and PCE-signaled > composite paths are independent. The draft ensures that BGP extensions do > not interfere with PCE operations, and any conflicts are resolved per RFC > 9256. > > > > > > BR, > > > > Yimi > > Susan Hares <[email protected]> 于 2026年7月11日周六 00:11写道： > > 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 [RFC > > 9862], 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] > > _______________________________________________ > 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]
