Ran: Thank you for your quick response. I am sorry my response was delayed due to IETF work.
Your email matches your descriptions in our face-to-face meetings. Thank you for sending this detailed response to the IDR and spring group. My question to Spring WG is – Does Ran’s description match your understanding of the requirements and limitations that Spring want to put on this draft? Sue From: [email protected] <[email protected]> Sent: Wednesday, July 15, 2026 12:31 AM To: Susan Hares <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Idr] [BGP-SR-TE] Request for information - prior to adoption call for draft-jiang-idr-sr-policy-composite-path Hi Sue Thank you for your careful shepherd review and for raising these important questions. We would like to first clarify a key distinction that may address your core concern regarding "creating BGP routes from dynamic sources." Our Draft Does NOT "Create" BGP Routes from Any Source draft-jiang-idr-sr-policy-composite-path defines BGP extensions to distribute composite candidate path information. Specifically: It distributes a composite candidate path "container" that references constituent SR Policies by color (e.g., "POL100 uses Color 1 with Weight W1 and Color 2 with Weight W2"). It does NOT create, generate, or install the candidate paths (segment lists or dynamic paths) of those constituent SR Policies. Our Draft Is a Complementary Extension to RFC 9830 As stated in Section 1 of RFC 9830: "The signaling of Dynamic and Composite CPs (Sections 5.2 and 5.3, respectively, of [RFC9256]) is outside the scope of this document." Our draft fills this gap by defining BGP signaling mechanisms for Composite Candidate Paths, which is precisely stated in the Introduction of our -09 draft: "This document 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]." Who Creates the Constituent Candidate Paths? The constituent SR Policies (referenced by color) must have their candidate paths created and distributed independently via: Mechanism Reference BGP RFC 9830 (for explicit candidate paths) PCEP RFC 9862 (for PCEP-delivered paths) Static Configuration Local CLI/YANG Our draft does not alter this. It only adds a new sub-TLV (Constituent SR Policy sub-TLV) to the BGP Tunnel Encapsulation Attribute to carry the composite candidate path's reference information（section 2）. Addressing Your Deeper Concern: Dynamic Sources We understand your concern about instability from dynamic sources (e.g., IGP, PCEP). To be clear: --Our draft does not introduce any mechanism to create BGP routes from IGP or any other dynamic source. --The composite candidate path itself is static—it is a fixed list of color references and weights. --If an operator wishes to ensure stability, they can ensure that the constituent SR Policies referenced by the composite path are sourced from explicit (static) configurations or BGP explicit paths. --If dynamic paths (e.g., via PCEP) are used for constituent policies, that is the operator's choice and follows the existing RFC 9256 behavior. To avoid any future misunderstanding, we propose adding some text to Section 1 (Introduction) in the next revision (-10) of the draft. We hope this clarifies the scope of our draft. Please let us know if you have further questions. BR, Ran From: SusanHares <[email protected]<mailto:[email protected]>> To: 'SPRING WG' <[email protected]<mailto:[email protected]>>;idr@ietf. <[email protected]<mailto:[email protected]>>; Date: 2026年07月11日 00:10 Subject: [Idr] [BGP-SR-TE] Request for information - prior to adoption call for draft-jiang-idr-sr-policy-composite-path _______________________________________________ Idr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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]
