Hi Sue & WG I have read the latest draft as well as reviewed the responses from the authors on the thread.
I believe the draft is clearly written in its current state and is ready for adoption speaking from a Spring SR Policy architecture and design point of view. This draft provides the BGP extension to support composite SR policy made up of multiple constituent candidate paths and defines a new constituent SR policy sub tlv to handle the composite candidate path scenario when there is more then one candidate path. The concept or composite SR policy has been supported by PCEP and local head end static policy by most all vendor for a long time now. This draft closes the RFC 9830 SR policy gap in BGP by providing the BGP extension sub tlv to support constituent candidate paths within a composite sr policy. Kind Regards Gyan On Fri, Jul 10, 2026 at 12:11 PM Susan Hares <[email protected]> wrote: > 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]
