Hi Sue, Thank you for your careful shepherd review. 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 is a complementary extension to RFC 9830.
Detailed responses to the questions are as follows: 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? [Changwang] All current expansions comply with the definition of RFC9256. No additional restrictions or descriptions are needed. draft-jiang-idr-sr-policy-composite-path defines that the candidate path of an SR policy can be composed of a set of SR policies specified by color. The paths of these constituent SR policies forming the composite path can be either static or dynamic, such as those delivered by PCEP. An example is provided below: SR Policy POL100 is a composite SR policy with a composite path. SR Policy POL1 <Headend = H1, Color = 1, Endpoint = E1> and SR Policy POL2 <Headend = H1, Color = 2, Endpoint = E1> are the SR policies referenced by colors 1 and 2 in the composite SR Policy POL100. The constituent SR Policies POL1 and POL2 are referenced only by color in the composite candidate path since their headend and endpoint are identical to POL100. SR Policy POL100 <Headend = H1, Color = 100, Endpoint = E1> Candidate Path CP1 <Protocol-Origin = 20, Originator = 64511:192.0.2.1, Discriminator = 1> Preference 200 SR Policy <Color = 1>, Weight W1 SR Policy <Color = 2>, Weight W2 For SR Policy POL1 <Headend = H1, Color = 1, Endpoint = E1> and SR Policy POL2 <Headend = H1, Color = 2, Endpoint = E1>, the candidate paths can be statically configured or dynamic, such as those calculated by PCEP. Therefore, the composite SR Candidate Path only specifies that the path of this composite SR Candidate Path originates from the constituent SR Policies, without specifying the source of the constituent SR Policies' paths. The paths of the constituent SR Policies can be configured via BGP, YANG, or dynamically calculated by PCEP. The composite SR Candidate Path can be specified via BGP, YANG, or PCEP static configuration. 2) Is the limitation of composite path to specific BGP sources an appropriate use of the composite concept from SPRING? [Changwang] All current expansions comply with the definition of RFC9256. No additional restrictions or descriptions are needed. RFC 9256 SR Policy Architecture defines the concept of a Composite Candidate Path. RFC9830 Advertising Segment Routing Policies in BGP. Section 3.5 of draft-ietf-pce-multipath-29 defines how to signal the Composite Candidate Path via PCEP. RFC9830 does not define how to signal the Composite Candidate Path via BGP. draft-jiang-idr-sr-policy-composite-path supplements the TLV definition for signaling the Composite Candidate Path via BGP. 3) How does this interact with the PCE composite CPs? [Changwang] As discussed in 1) above, the path source of the constituent SR Policies may be PCEP. Additionally, the composite CPs issued by the PCE can be reported through BGP-LS extensions (draft-li-idr-bgpls-sr-policy-composite-path). When both BGP and PCE issue the same composite CPs, the principles defined in RFC9256 can be referenced for optimization. No additional processing is required for this document. Thanks, Changwang 发件人: 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 [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 ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
