Circuit Style Segment Routing Policies
Internet-Draft draft-ietf-spring-cs-sr-policy-02
Christian Schmutzer, Ed.
Cisco Systems, Inc.
cschmutz@cisco.com
Zafar Ali, Ed.
Cisco Systems, Inc.
zali@cisco.com
Praveen Maheshwari
Airtel India
Praveen.Maheshwari@airtel.com
Reza Rokui
Ciena
rrokui@ciena.com
Andrew Stone
Nokia
andrew.stone@nokia.com
18 April 2024
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies).
Introduction
Segment routing does allow for a single network to carry both typical IP (connection-less) services and connection-oriented transport services commonly referred to as "private lines". IP services typically require ECMP and TI-LFA, while transport services delivered via pseudowires (defined by the PWE3 and PALS workgroups) do require:
- Persistent end-to-end traffic engineered paths that provide predictable and identical latency in both directions
- A requested amount of bandwidth per path to ensure no impact on the Service Level Agreement (SLA) due to changing network load from other services
- Fast end-to-end protection and restoration mechanisms
- Monitoring and maintenance of path integrity
- Data plane remaining up while control plane is down
Such a "transport centric" behavior is referred to as "circuit-style" in this document.
This document describes how SR policies [I-D.ietf-spring-segment-routing-policy] and the use of adjacency-SIDs defined in the SR architecture [RFC8402] together with a stateful Path Computation Element (PCE) [RFC8231] can be used to satisfy those requirements. It includes how end-to-end recovery and path integrity monitoring can be implemented.
SR policies that satisfy those requirements are called "circuit-style" SR policies (CS-SR policies).
Terminology
- BSID : Binding Segment Identifier
- CS-SR : Circuit-Style Segment Routing
- ID : Identifier
- LSP : Label Switched Path
- LSPA : LSP attributes
- OAM : Operations, Administration and Maintenance
- OF : Objective Function
- PCE : Path Computation Element
- PCEP : Path Computation Element Communication Protocol
- PT : Protection Type
- SID : Segment Identifier
- SLA : Service Level Agreement
- SR : Segment Routing
- STAMP : Simple Two-Way Active Measurement Protocol
- TI-LFA : Topology Independent Loop Free Alternate
- TLV : Type Length Value
Reference Model
The reference model for CS-SR policies is following the Segment Routing Architecture [RFC8402] and SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] and is depicted in Figure 1.
Circuit-style SR Policy Reference Model

                      +----------------+
      +-------------->| PCE/controller |<------------+
      |               +----------------+             |
  PCEP/BGP                                       PCEP/BGP
      |                                              |
      v   <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>>  v
+-------+                                          +-------+
|       |=========================================>|       |
|   A   | SR-policy from A to Z                    |   Z   |
|       |<=========================================|       |
+-------+                    SR-policy from Z to A +-------+

By nature of CS-SR policies, paths will be computed and maintained by a centralized entity providing a consistent simple mechanism for initializing the co-routed bidirectional end to end paths, performing bandwidth allocation control, as well as monitoring facilities to ensure SLA compliance for the live of the CS-SR Policy.
When using PCEP as the communication protocol on the endpoints, the centralized entity is a stateful PCE defined in [RFC8231]. When using a MPLS data plane [RFC8660], PCEP extensions defined in [RFC8664] will be used. When using a SRv6 data plane [RFC8754], PCEP extensions defined in [I-D.ietf-pce-segment-routing-ipv6] will be used.
When using BGP as the communication protocol on the endpoints, the centralized entity does perform the same role. BGP extensions defined in [I-D.ietf-idr-segment-routing-te-policy] will be used.
In order to satisfy the requirements of CS-SR policies, each link in the topology MUST have:
- An adjacency-SID which is:
  - Manually allocated or persistent : to ensure that its value does not change after a node reload
  - Non-protected : to avoid any local TI-LFA protection to happen upon interface/link failures
- The bandwidth available for CS-SR policies specified
- A per-hop behavior ([RFC3246] or [RFC2597]) that ensures that the specified bandwidth is available to CS-SR policies at all times independent of any other traffic
When using a MPLS data plane [RFC8660] existing IGP extensions defined in [RFC8667] and [RFC8665] and BGP-LS defined in [RFC9085] can be used to distribute the topology information including those persistent and unprotected adjacency-SIDs.
When using a SRv6 data plane [RFC8754] the IGP extensions defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] and BGP-LS extensions in [I-D.ietf-idr-bgpls-srv6-ext] apply.
Managing Bandwidth
In a network, resources are represented by links of certain bandwidth. In a circuit switched network such as SONET/SDH, OTN or DWDM resources (timeslots or a wavelength) are allocated for a provisioned connection at the time of reservation even if no communication is present. In a packet switched network resources are only allocated when communication is present, i.e. packets are to be sent. This allows for the total reservations to exceed the link bandwidth as well in general for link congestion.
To satisfy the bandwidth requirement for CS-SR policies it must be ensured that packets carried by CS-SR policies can be at all times sent up to the reserved bandwidth on each hop along the path. This is done by:
- Firstly, CS-SR policy bandwidth reservations per link must be limited to euqal or less than the physical link bandwidth.
- Secondly, ensuring traffic for each CS-SR policy is limited to the bandwidth reserved for that CS-SR policy by traffic policing or shaping
- Thirdly, ensuring that during times of link congestion only non-CS-SR policy traffic is being buffered or dropped.
For the later several approaches can be considered:
- Allocate a dedicated physical link of bandwidth P to CS-SR policies and allow CS-SR reservations up to bandwidth C. Consider bandwidth N allocated for network control, ensure that P - N >= C
- Allocate a dedicate logical link (i.e. 801.q VLAN on ethernet) to CS-SR policies on a physical link of bandwidth P. Limit the total utilization across all other logical links to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C
- Allocate a dedicated Diffserv codepoint and queue to CS-SR policies and limit the total utilization across all other queues to bandwidth O by traffic policing or shaping and ensure that P -N - O >= C
- Allocate a dedicate Diffserv codepoint and strict priority queue to CS-SR policies and limit the total utilization across all priority queues of higher or equal priority to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C
- Allocate a dedicate Diffserv codepoint and a strict priority queue with a priority higher than all other queues to CS-SR policies and limit the utilization of that priority queue by traffic policing to C <= P - N
In addition CS-SR policy telemetry collection can be used to raise alarms when bandwidth utilization thresholds are passed or to request the reserved bandwidth to be adjusted.
CS-SR Policy Characteristics
A CS-SR policy has the following characteristics:
- Requested bandwidth : bandwidth to be reserved for the CS-SR policy
- Bidirectional co-routed : a CS-SR policy between A and Z is an association of an SR-Policy from A to Z and an SR-Policy from Z to A following the same path(s)
- Deterministic and persistent paths : segment lists with strict hops using unprotected adjacency-SIDs
- Not automatically recomputed or reoptimized : the SID list of a candidate path must not change automatically to a SID list representing a different path (for example upon topology change)
- Multiple candidate paths in case of protection/restoration:
  - Following the SR policy architecture, the highest preference valid path is carrying traffic
  - Depending on the protection/restoration scheme (Section 6), lower priority candidate paths
    - may be pre-computed
    - may be pre-programmed
    - may have to be disjoint
- Connectivity verification and performance measurement is activated on each candidate path (Section 7)
CS-SR Policy Creation
Policy Creation when using PCEP
Considering the scenario illustrated in Figure 1 a CS-SR policy between A and Z is configured both on A (with Z as endpoint) and Z (with A as endpoint).
Both nodes A and Z act as PCC and delegate path computation to the PCE using PCEP with the extensions defined in [RFC8664] and the procedure described in Section 5.7.1 of [RFC8231]. The PCRpt message sent from the headends to the PCE contains the following parameters:
- BANDWIDTH object (Section 7.7 of [RFC5440]) : to indicate the requested bandwidth
- LSPA object (section 7.11 of [RFC5440]) : to indicate that no local protection requirements
  - L flag set to 0 : no local protection
  - E flag set to 1 : protection enforcement (section 5 of [I-D.ietf-pce-local-protection-enforcement])
- ASSOCIATION object ([RFC8697]) :
  - Type : Double-sided Bidirectional with Reverse LSP Association ([I-D.ietf-pce-sr-bidir-path])
  - Bidirectional Association Group TLV ([RFC9059]) :
    - R flag is always set to 0 (forward path)
    - C flag is always set to 1 (co-routed)
If the SR-policies are configured with more than one candidate path, a PCEP request is sent per candidate path. Each PCEP request does include the "SR Policy Association" object (type 6) as defined in [I-D.ietf-pce-segment-routing-policy-cp] to make the PCE aware of the candidate path belonging to the same policy.
The signaling extensions described in [I-D.sidor-pce-circuit-style-pcep-extensions] are used to ensure that
- Path determinism is achieved by the PCE only using segment lists representing a strict hop by hop path using unprotected adjacency-SIDs.
- Path persistency across node reloads in the network is achieved by the PCE only including manually configured adjacency-SIDs in its path computation response.
- Persistency across network changes is achieved by the PCE not performing periodic nor network event triggered re-optimization.
Bandwidth adjustment can be requested after initial creation by signaling both requested and operational bandwidth in the BANDWIDTH object but the PCE is not allowed to respond with a changed path.
As discussed in section 3.2 of [I-D.ietf-pce-multipath] it may be necessary to use load-balancing across multiple paths to satisfy the bandwidth requirement of a candidate path. In such a case the PCE will notify the PCC to install multiple segment lists using the signaling procedures described in section 5.3 of [I-D.ietf-pce-multipath].
Policy Creation when using BGP
Again considering the scenario illustrated in Figure 1, there is no CS-SR policy configuration required on A nor Z in order to create the CS-SR policy between A and Z.
The centralized controller is instructed (i.e. by an application via a API call) to create the CS-SR policy, for which the controller does perform path computation and is requesting A via BGP to instante a SR-policy (with Z as endpoint) and requesting Z via BGP to instantiate a SR-policy (with Z as endpoint).
To instantiate the SR-policies in A and Z the BGP extensions defined in [I-D.ietf-idr-segment-routing-te-policy] are used.
No signaling extensions are required for the following:
- Path determinism is achieved by the controller only using segment lists representing a strict hop by hop path using unprotected adjacency-SIDs.
- Path persistency across node reloads in the network is achieved by the controller only including manually configured adjacency-SIDs in its path computation response.
- Persistency across network changes is achieved by the controller not performing periodic nor network event triggered re-optimization.
If there are more than one candidate paths per SR-policy required, multiple NLRIs with different distinguisher values (see section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]) have to be included in the BGP UPDATE message.
To achieve load-balancing across multiple paths to satisfy the bandwidth requirement of a candidate path, multiple Segment List Sub-TLVs have to be included in the SR Policy Sub-TLV. See section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]
The endpoints A and Z report the SR-policy states back to the centralized controller via BGP-LS using the extension defined in [I-D.ietf-idr-bgp-ls-sr-policy].
Maximum Segment Depth
A Segment Routed path defined by a segment list is constrained by maximum segment depth (MSD), which is the maximum number of segments a router can impose onto a packet. [RFC8491], [RFC8476], [RFC8814] and [RFC8664] provide the necessary capabilities for a PCE to determine the MSD capability of a router. The MSD constraint is typically resolved by leveraging a label stack reduction technique, such as using Node SIDs and/or BSIDs (SR architecture [RFC8402]) in a segment list, which represents one or many hops in a given path.
As described in Section 4, adjacency-SIDs without local protection are to be used for CS-SR policies to ensure no ECMP, no rerouting due to topological changes nor localized protection is being invoked on the traffic, as the alternate path may not be providing the desired SLA.
If a CS-SR Policy path requires SID List reduction, a Node SID cannot be utilized as it is eligible for traffic rerouting following IGP re-convergence. However, a BSID can be programmed to a transit node, if the following requirements are met:
- The BSID is unprotected, hence only has one candidate path
- The BSID follows the rerouting and optimization characteristics defined in Section 4 which implies the SID list of the candidate path MUST only use unprotected adjacency-SIDs.
This ensures that any CS-SR policies in which the BSID provides transit for do not get rerouted due to topological changes or protected due to failures. A BSID may be pre-programmed in the network or automatically injected in the network by a PCE.
Recovery Schemes
Various protection and restoration schemes can be implemented. The terms "protection" and "restoration" are used with the same subtle distinctions outlined in section 1 of [RFC4872], [RFC4427] and [RFC3386] respectively.
- Protection : another candidate path is computed and fully established in the data plane and ready to carry traffic
- Restoration : a candidate path may be computed and may be partially established but is not ready to carry traffic
The term "failure" is used to represent both "hard failures" such complete loss of connectivity detected by Section 7.1 or degradation, a packet loss ratio, beyond a configured acceptable threshold.
Unprotected
In the most basic scenario no protection nor restoration is required. The CS-SR policy has only one candidate path configured. This candidate path is established, activated and is carrying traffic.
When using PCEP, a PCRpt message is sent from the PCC to the PCE with the O field in the LSP object set to 2.
When using BGP, a BGP-LS update with a SR Policy Candidate Path NLRI is sent from the endpoint to the centralized controller having
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- A flag set to 1 to indicate the candidate path is active and carrying traffic
In case of a failure along the path the CS-SR policy will go down and traffic will not be recovered.
Typically two CS-SR policies are deployed either within the same network with disjoint paths or in two completely separate networks and the overlay service is responsible for traffic recovery.
1:1 Protection
For fast recovery against failures the CS-SR policy has two candidate paths. Both paths are established but only the candidate with higher preference is activated and is carrying traffic.
When using PCEP, the PCRpt message for the candidate path with higher preference will have the O field in the LSP object set to 2. For the candidate path with the lower preference the O field in the LSP object is set to 1.
Appropriate routing of the protect path diverse from the working path can be requested from the PCE by using the "Disjointness Association" object (type 2) defined in [RFC8800] in the PCRpt messages. The disjoint requirements are communicated in the "DISJOINTNESS-CONFIGURATION TLV"
- L bit set to 1 for link diversity
- N bit set to 1 for node diversity
- S bit set to 1 for SRLG diversity
- T bit set to enforce strict diversity
The P bit may be set for first candidate path to allow for finding the best working path that does satisfy all constraints without considering diversity to the protect path.
The "Objective Function (OF) TLV" as defined in section 5.3 of [RFC8800] may also be added to minimize the common shared resources.
When using BGP, the controller is already aware of the disjoint requirements and does consider them while computing both paths. Two NLRIs with different distinguisher values and different preference values are included in the BGP UPDATE sent to the headend routers.
A BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the candidate path with higher preference with
- C flag set to 1 to indicate that candidate path was provisioned by the controller
- A flag set to 1 to indicate the candidate path is active and carrying traffic
and another SR Policy Candidate Path NLRI for the candidate path with lower preference with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- B flag set to 1 to indicate the role of backup path
Upon a failure impacting the candidate path with higher preference carrying traffic, the candidate path with lower preference is activated immediately and traffic is now sent across it.
When using PCEP a PCRpt message for the higher preference candidate path is sent to the PCE with the O field changed from 2 to 0 and a PCRpt message for the lower preference candidate path with the O field change from 1 to 2.
When using BGP a BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the candidate path with higher preference with the A flag cleared and for another BGP-LS update for the candidate path with lower preference with the B flag cleared and A flag set to 1.
Protection switching is bidirectional. As described in Section 7.1, both headends will generate and receive their own loopback mode test packets, hence even a unidirectional failure will always be detected by both headends without protection switch coordination required.
Reversion
Two cases are to be considered when the failure(s) impacting a candidate path with higher preference are cleared:
- Revertive switching : re-activate the highere preference candidate path and start sending traffic over it
- Non-revertive switching : do not activate the higher preference candidate path and keep sending traffic via the lower preference candidate path
When using PCEP, for revertive switching a PCRpt message for the recovered higher preference candidate path is sent to the PCE with the O field changed from 0 to 2 and send a PCRpt message for the lower preference candidate path with the O field changed from 2 to 1. For non-revertive switching only a PCRpt message for the recovered higher preference candidate path with the O field set to 1 is sent.
When using BGP and revertive switching a BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the recovered higher preference candidate path with the A flag set to 1 and another BGP-LS update for the lower preference candidate path with the A flag cleared and B flag set to 1. For non-revertive switching only a BGP-LS update for the higher preference candidate path with the B flag set to 1 is sent.
Restoration
1+R Restoration
Compared to 1:1 protection described in Section 6.2, this restoration scheme avoids pre-allocating protection bandwidth in steady state, while still being able to recover traffic flow in case of a network failure in a deterministic way (maintain required bandwidth commitment)
When using PCEP, the CS-SR policy is configured with two candidate paths. The candidate path with higher preference is established, activated (O field in LSP object is set to 2) and is carrying traffic.
The second candidate path with lower preference is only established and activated (PCRpt message to the PCE with O field in LSP object is set to 2) upon a failure impacting the first candidate path in order to send traffic over an alternate path through the network around the failure with potentially relaxed constraints but still satisfying the bandwidth commitment.
The second candidate path is generally only requested from the PCE and activated after a failure, but may also be requested and pre-established during CS-SR policy creation with the downside of bandwidth being set aside ahead of time.
As soon as failure(s) that brought the first candidate path down are cleared, the second candidate path is getting deactivated (PCRpt message to the PCE with O field in LSP object is set to 1) or torn down. The first candidate path is activated (PCRpt message to the PCE with O field in LSP object is set to 2) and traffic sent across it.
When using BGP, the controller does compute one path and does include one NLRI in the BGP UPDATE message sent to the headend routers to instantiate the CS-SR policy with one candidate path active and carrying traffic.
A BGP-LS update with a SR Policy Candidate Path NLRI is sent to the controller with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- A flag set to 1 to indicate the candidate path is active and carrying traffic
Upon the controller detecting the failure of the CS-SR policy's candidate path, another path is computed and added as second candidate path to the CS-SR policy by sending a BGP UPDATE message to the headend routers with a NLRI distinguisher value being different and preference being lower compared to the first candidate path.
A BGP-LS update with a SR Policy Candidate Path NLRI for the candidate path with higher preference is sent to the controller with
- A flag is cleared to indicate the candidate path is no longer active and not carrying traffic anymore
and another SR Policy Candidate Path NLRI for the candidate path with lower preference with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- A flag set to 1 to indicate the candidate path is active and carrying traffic
The second candidate path is generally only instantiated by the controller and activated after a failure, but may also be instantiated and pre-established during CS-SR policy creation with the downside of bandwidth being set aside ahead of time. If so, a BGP-LS update with a SR Policy Candidate Path NLRI is sent to the controller with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- B flag set to 1 to indicate the role of backup path
Once the controller has detected the failure(s) that brought the first candidate path down are cleared, a BGP-LS update with a SR Policy Candidate Path NLRI for the first candidate path is sent to the controller with
- A flag set to 1 to indicate the candidate path became active and is carrying traffic again
The second candidate path is getting removed by a BGP UPDATE message withdrawing the NLRI of the second candidate path.
Restoration and reversion behavior is bidirectional. As described in Section 7.1, both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.
1:1+R Restoration
For further resiliency in case of multiple concurrent failures that could affect both candidate paths of 1:1 protection described in Section 6.2, a third candidate path with a preference lower than the other two candidate paths is added to the CS-SR policy to enable restoration.
When using PCEP, the third candidate path will generally only be established, activated (PCRpt message to the PCE with O field in LSP object is set to 2) and carry traffic after failure(s) have impacted both the candidate path with highest and second highest preference.
The third candidate path may also be requested and pre-computed already whenever either the first or second candidate path went down due to a failure with the downside of bandwidth being set aside ahead of time.
As soon as failure(s) that brought either the first or second candidate path down are cleared the third candidate path is getting deactivated (PCRpt message to the PCE with O field in LSP object is set to 1), the candidate path that recovered is activated (PCRpt message to the PCE with O field in LSP object is set to 2) and traffic sent across it.
When using BGP, the third candidate path will generally only be instantiated by the controller and activated after failure(s) have impacted both the candidate path with highest and second highest preference, but may also be instantiated and pre-established during CS-SR policy creation with the downside of bandwidth being set aside ahead of time.
Assuming the case where both candidate paths are down, a BGP-LS update is sent with SR Policy Candidate Path NLRIs for the first and second candidate path with
- A flag cleared
and a SR Policy Candidate Path NLRI for the third candidate path with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- A flag set to 1 to indicate the candidate path is active and carrying traffic
Assuming the case where only one candidate path is down, a BGP-LS update is sent with a SR Policy Candidate Path NLRI for the failed candidate path with
- A flag cleared
a SR Policy Candidate Path NLRI for the second candidate path with
- A flag set to 1 to indicate it is active and carrying traffic network
and another SR Policy Candidate Path NLRI for the newly installed third candidate path with
- C flag set to 1 to indicate the candidate path was provisioned by the controller
- B flag set to 1 to indicate the role of backup path
Once the controller has detected the failure(s) that brought either the first or the second candidate path down are cleared, a BGP-LS update with a SR Policy Candidate Path NLRI for the recovered candidate path is sent to the controller with
- A flag set to 1 to indicate the candidate path became active and is carrying traffic again
The third candidate path is getting removed by a BGP UPDATE message withdrawing the NLRI of the third candidate path.
Again restoration and reversion behavior is bidirectional. As described in Section 7.1, both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.
Operations, Administration, and Maintenance (OAM)
Connectivity Verification
The proper operation of each segment list is validated by both headends using STAMP in loopback measurement mode as described in section 4.2.3 of [I-D.ietf-spring-stamp-srpm].
As the STAMP test packets are including both the segment list of the forward and reverse path, standard segment routing data plane operations will make those packets get switched along the forward path to the tailend and along the reverse path back to the headend.
When using PCEP, the headend forms the bidirectional SR Policy association using the procedure described in [I-D.ietf-pce-sr-bidir-path] and receives the information about the reverse segment list from the PCE as described in section 4.5 of [I-D.ietf-pce-multipath]
When using BGP, the controller does inform the headend routers about the reverse segment list using the Reverse Segment List Sub-TLV defined in section 4.1 of [I-D.ietf-idr-sr-policy-path-segment].
Performance Measurement
The same STAMP session is used to estimate round-trip loss as described in section 5 of [I-D.ietf-spring-stamp-srpm].
The same STAMP session used for connectivity verification can be used to measure delay. As loopback mode is used only round-trip delay is measured and one-way has to be derived by dividing the round-trip delay by two.
Candidate Path Validity Verification
A stateful PCE/controller is in sync with the network topology and the CS-SR Policies provisioned on the headend routers. As described in Section 4 a path must not be automatically recomputed after or optimized for topology changes. However there may be a requirement for the stateful PCE/controller to tear down a path if the path no longer satisfies the original requirements, detected by stateful PCE/controller, such as insufficient bandwidth, diversity constraint no longer met or latency constraint exceeded.
The headend may measure the actual bandwidth utilization of a CS-SR policy to take local action and/or report it as requested bandwidth via PCEP or BGP-LS to the stateful PCE/controller. Typical actions are raising alarms or adjusting the reserved bandwidth.
For a CS-SR policy configured with multiple candidate paths, a headend may switch to another candidate path if the stateful PCE/controller decided to tear down the active candidate path.
External Commands
Candidate Path Switchover
It is very common to allow operators to trigger a switch between candidate paths even if no failure is present. I.e. to proactively drain a resource for maintenance purposes. Operator triggered switching between candidate paths is unidirectional and has to be requested on both headends.
Candidate Path Re-computation
While no automatic re-optimization or pre-computation of CS-SR policy candidate paths is allowed as specified in Section 4, network operators trying to optimize network utilization may explicitly request a candidate path to be re-computed at a certain point in time.
Security Considerations
TO BE ADDED
IANA Considerations
This document has no IANA actions.
Acknowledgements
The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh Gandhi and Tarek Saad for providing their review comments and all contributors for their inputs and support.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
Informative References
[RFC8231]

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
E. Crabbe
I. Minei
J. Medved
R. Varga
September 2017
RFC 8231
DOI 10.17487/RFC8231
[I-D.ietf-spring-segment-routing-policy]

Segment Routing Policy Architecture
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Daniel Voyer
Bell Canada
Alex Bogdanov
British Telecom
Paul Mattes
Microsoft
22 March 2022
Internet-Draft draft-ietf-spring-segment-routing-policy-22
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402
[RFC8660]

Segment Routing with the MPLS Data Plane
A. Bashandy, Ed.
C. Filsfils, Ed.
S. Previdi
B. Decraene
S. Litkowski
R. Shakir
December 2019
RFC 8660
DOI 10.17487/RFC8660
[RFC8664]

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing
S. Sivabalan
C. Filsfils
J. Tantsura
W. Henderickx
J. Hardwick
December 2019
RFC 8664
DOI 10.17487/RFC8664
[RFC8754]

IPv6 Segment Routing Header (SRH)
C. Filsfils, Ed.
D. Dukes, Ed.
S. Previdi
J. Leddy
S. Matsushima
D. Voyer
March 2020
RFC 8754
DOI 10.17487/RFC8754
[I-D.ietf-pce-segment-routing-ipv6]

Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing
Cheng Li
Huawei Technologies
Prejeeth Kaladharan
RtBrick Inc
Siva Sivabalan
Ciena Corporation
Mike Koldychev
Cisco Systems, Inc.
Yongqing Zhu
China Telecom
4 April 2024
Internet-Draft draft-ietf-pce-segment-routing-ipv6-25
[I-D.ietf-idr-segment-routing-te-policy]

Advertising Segment Routing Policies in BGP
Stefano Previdi
Huawei Technologies
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Paul Mattes
Microsoft
Dhanendra Jain
Google
23 October 2023
Internet-Draft draft-ietf-idr-segment-routing-te-policy-26
[RFC3246]

An Expedited Forwarding PHB (Per-Hop Behavior)
B. Davie
A. Charny
J.C.R. Bennet
K. Benson
J.Y. Le Boudec
W. Courtney
S. Davari
V. Firoiu
D. Stiliadis
March 2002
RFC 3246
DOI 10.17487/RFC3246
[RFC2597]

Assured Forwarding PHB Group
J. Heinanen
F. Baker
W. Weiss
J. Wroclawski
June 1999
RFC 2597
DOI 10.17487/RFC2597
[RFC8667]

IS-IS Extensions for Segment Routing
S. Previdi, Ed.
L. Ginsberg, Ed.
C. Filsfils
A. Bashandy
H. Gredler
B. Decraene
December 2019
RFC 8667
DOI 10.17487/RFC8667
[RFC8665]

OSPF Extensions for Segment Routing
P. Psenak, Ed.
S. Previdi, Ed.
C. Filsfils
H. Gredler
R. Shakir
W. Henderickx
J. Tantsura
December 2019
RFC 8665
DOI 10.17487/RFC8665
[RFC9085]

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
S. Previdi
K. Talaulikar, Ed.
C. Filsfils
H. Gredler
M. Chen
August 2021
RFC 9085
DOI 10.17487/RFC9085
[I-D.ietf-lsr-isis-srv6-extensions]

IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane
Peter Psenak
Cisco Systems
Clarence Filsfils
Cisco Systems
Ahmed Bashandy
Cisco Systems
Bruno Decraene
Orange
Zhibo Hu
Huawei Technologies
14 November 2022
Internet-Draft draft-ietf-lsr-isis-srv6-extensions-19
[I-D.ietf-lsr-ospfv3-srv6-extensions]

OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
Zhenbin Li
Huawei Technologies
Zhibo Hu
Huawei Technologies
Ketan Talaulikar
Cisco Systems
Peter Psenak
Cisco Systems
21 June 2023
Internet-Draft draft-ietf-lsr-ospfv3-srv6-extensions-15
[I-D.ietf-idr-bgpls-srv6-ext]

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)
Gaurav Dawra
LinkedIn
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Mach Chen
Huawei
Daniel Bernier
Bell Canada
Bruno Decraene
Orange
17 February 2023
Internet-Draft draft-ietf-idr-bgpls-srv6-ext-14
[RFC5440]

Path Computation Element (PCE) Communication Protocol (PCEP)
JP. Vasseur, Ed.
JL. Le Roux, Ed.
March 2009
RFC 5440
DOI 10.17487/RFC5440
[I-D.ietf-pce-local-protection-enforcement]

Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)
Andrew Stone
Nokia
Mustapha Aissaoui
Nokia
Samuel Sidor
Cisco Systems, Inc.
Siva Sivabalan
Ciena Coroporation
23 June 2023
Internet-Draft draft-ietf-pce-local-protection-enforcement-11
[RFC8697]

Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)
I. Minei
E. Crabbe
S. Sivabalan
H. Ananthakrishnan
D. Dhody
Y. Tanaka
January 2020
RFC 8697
DOI 10.17487/RFC8697
[I-D.ietf-pce-sr-bidir-path]

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths
Cheng Li
Huawei Technologies
Mach Chen
Huawei Technologies
Weiqiang Cheng
China Mobile
Rakesh Gandhi
Cisco Systems, Inc.
Quan Xiong
ZTE Corporation
13 February 2024
Internet-Draft draft-ietf-pce-sr-bidir-path-13
[RFC9059]

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)
R. Gandhi, Ed.
C. Barth
B. Wen
June 2021
RFC 9059
DOI 10.17487/RFC9059
[I-D.ietf-pce-segment-routing-policy-cp]

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
Mike Koldychev
Ciena Corporation
Siva Sivabalan
Ciena Corporation
Colby Barth
Juniper Networks, Inc.
Shuping Peng
Huawei Technologies
Hooman Bidgoli
Nokia
17 March 2024
Internet-Draft draft-ietf-pce-segment-routing-policy-cp-15
[I-D.sidor-pce-circuit-style-pcep-extensions]

PCEP extensions for Circuit Style Policies
Samuel Sidor
Cisco Systems, Inc.
Praveen Maheshwari
Airtel India
Andrew Stone
Nokia
Luay Jalil
Verizon
Shuping Peng
Huawei Technologies
15 December 2023
Internet-Draft draft-sidor-pce-circuit-style-pcep-extensions-06
[I-D.ietf-pce-multipath]

PCEP Extensions for Signaling Multipath Information
Mike Koldychev
Ciena Corporation
Siva Sivabalan
Ciena Corporation
Tarek Saad
Juniper Networks, Inc.
Vishnu Pavan Beeram
Juniper Networks, Inc.
Hooman Bidgoli
Nokia
Bhupendra Yadav
Ciena
Shuping Peng
Huawei Technologies
Gyan Mishra
Verizon Inc.
8 April 2024
Internet-Draft draft-ietf-pce-multipath-11
[I-D.ietf-idr-bgp-ls-sr-policy]

Advertisement of Segment Routing Policies using BGP Link-State
Stefano Previdi
Individual
Ketan Talaulikar
Cisco Systems
Jie Dong
Huawei Technologies
Hannes Gredler
RtBrick Inc.
Jeff Tantsura
Nvidia
20 March 2024
Internet-Draft draft-ietf-idr-bgp-ls-sr-policy-04
[RFC8491]

Signaling Maximum SID Depth (MSD) Using IS-IS
J. Tantsura
U. Chunduri
S. Aldrin
L. Ginsberg
November 2018
RFC 8491
DOI 10.17487/RFC8491
[RFC8476]

Signaling Maximum SID Depth (MSD) Using OSPF
J. Tantsura
U. Chunduri
S. Aldrin
P. Psenak
December 2018
RFC 8476
DOI 10.17487/RFC8476
[RFC8814]

Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
J. Tantsura
U. Chunduri
K. Talaulikar
G. Mirsky
N. Triantafillis
August 2020
RFC 8814
DOI 10.17487/RFC8814
[RFC4872]

RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
J.P. Lang, Ed.
Y. Rekhter, Ed.
D. Papadimitriou, Ed.
May 2007
RFC 4872
DOI 10.17487/RFC4872
[RFC4427]

Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
E. Mannie, Ed.
D. Papadimitriou, Ed.
March 2006
RFC 4427
DOI 10.17487/RFC4427
[RFC3386]

Network Hierarchy and Multilayer Survivability
W. Lai, Ed.
D. McDysan, Ed.
November 2002
RFC 3386
DOI 10.17487/RFC3386
[RFC8800]

Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling
S. Litkowski
S. Sivabalan
C. Barth
M. Negi
July 2020
RFC 8800
DOI 10.17487/RFC8800
[I-D.ietf-spring-stamp-srpm]

Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks
Rakesh Gandhi
Cisco Systems, Inc.
Clarence Filsfils
Cisco Systems, Inc.
Daniel Voyer
Bell Canada
Mach Chen
Huawei
Richard "Footer" Foote
Nokia
4 April 2024
Internet-Draft draft-ietf-spring-stamp-srpm-14
[I-D.ietf-idr-sr-policy-path-segment]

SR Policy Extensions for Path Segment and Bidirectional Path
Cheng Li
Huawei Technologies
Zhenbin Li
Huawei Technologies
Yuanyang Yin
China Telecom
Weiqiang Cheng
China Mobile
Ketan Talaulikar
Cisco Systems
19 February 2024
Internet-Draft draft-ietf-idr-sr-policy-path-segment-09
[RFC1925]

The Twelve Networking Truths
R. Callon
April 1996
RFC 1925
DOI 10.17487/RFC1925
Contributors
Daniel Voyer
Bell Canada
daniel.voyer@bell.ca
Luay Jalil
Verizon
luay.jalil@verizon.com
Shuping Peng
Huawei Technologies
pengshuping@huawei.com
Clarence Filsfils
Cisco Systems, Inc.
cfilsfil@cisco.com
Francois Clad
Cisco Systems, Inc.
fclad@cisco.com
Tarek Saad
Cisco Systems, Inc.
tsaad.net@gmail.com
Brent Foster
Cisco Systems, Inc.
brfoster@cisco.com
Bertrand Duvivier
Cisco Systems, Inc.
bduvivie@cisco.com
Stephane Litkowski
Cisco Systems, Inc.
slitkows@cisco.com
Jie Dong
Huawei Technologies
jie.dong@huawei.com