Hi??
I support this adoption. Below are my answers:
1) Can composite SR Candidate Paths be limited to be created from only explicit
(aka Static) BGP SR Candidate path?
?6?1 If so, how is it done (technically)?
?6?1 What text should be found in
draft-jiang-idr-sr-policy-composite-path-04 on this limited?
?6?1 Is it there?
Technically, the draft allows composite paths to reference any SR Policy,
regardless of its source.
2) Is the limitation of composite path to specific BGP sources an appropriate
use of the composite concept from SPRING?
Composite paths are about structuring traffic steering, not about creating new
paths. I believe any method of creation is reasonable.
The current document does not alter the definition of RFC9256 and requires no
additional modifications.
3) How does this interact with the PCE composite CPs?
BGP and PCE are complementary distribution mechanisms. A composite path
signaled via BGP may reference constituent policies that are themselves
signaled via PCE. The headend resolves these references independently,
following RFC 9256 procedures. No conflict is introduced by this draft.
Yuan Li
??????: 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
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
