Circuit Style Segment Routing Policy

Internet-Draft	CS-SR Policy	February 2026
Schmutzer, et al.	Expires 24 August 2026	[Page]

Abstract

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 SR network. The association of two co-routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy).¶

4. Reference Model

The reference model for CS-SR Policies follows the SR architecture [RFC8402] and SR Policy architecture [RFC9256] and is depicted in Figure 1.¶

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

Figure 1: Circuit Style SR Policy Reference Model

Given the nature of CS-SR Policies, paths are 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 life of the CS-SR Policy.¶

CS-SR Policies can be instantiated in the headend routers by using PCEP or BGP as a communication protocol between the headend routers and the central controller or by configuration.¶

When using PCEP as the communication protocol, the controller is a stateful PCE as defined in [RFC8231]. When using SR-MPLS [RFC8660], PCEP extensions defined in [RFC8664] are used. When using SRv6 [RFC8754] [RFC8986], PCEP extensions defined in [RFC9603] are used.¶
When using BGP as the communication protocol, the BGP extensions defined in [RFC9830] are used.¶
When using configuration, an appropriate YANG model such as [I-D.ietf-spring-sr-policy-yang] can be used.¶

To satisfy the requirements of CS-SR Policies, each link in the topology used by or intended to support CS-SR Policies MUST have:¶

An adjacency-SID which is:¶
- Persistent, which could be statically configured or auto-generated: to ensure that its value does not change after an event that may cause dynamic states to change (e.g. router reboot).¶
- Non-protected: to avoid any local TI-LFA protection [RFC9855] 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 always available to CS-SR Policies independent of any other traffic.¶

When using link bundles (i.e. [IEEE802.1AX]), parallel physical links are only represented via a single adjacency. To ensure deterministic traffic placement onto physical links and Operations, Administration, and Maintenance (OAM) per physical link, an adjacency-SID SHOULD be assigned to each physical link (aka member-link) ([RFC8668], [RFC9356]). This is not needed when the traffic carried by a CS-SR Policy has enough entropy ([RFC6391], [RFC6790], [RFC6437]) for traffic load-balancing across multiple member-links to work well.¶

Similarly, the use of adjacency-SIDs representing parallel adjacencies Section 3.4.1 of [RFC8402] SHOULD also be avoided.¶

When using SR-MPLS [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 SRv6 [RFC8754], the IGP extensions defined in [RFC9352] and [RFC9513] and BGP-LS extensions in [RFC9514] apply.¶

4.1. Managing Bandwidth

In a network, resources are represented by links of certain bandwidth. In a circuit switched network such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN) or Dense Wave Division Multiplexing (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 and can in general lead to link congestion and packet loss.¶

To satisfy the bandwidth requirement for CS-SR Policies it must be ensured that packets carried by CS-SR Policies can always be 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 equal 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 and admission control on the ingress of the pseudowire.¶
Thirdly, ensuring that during times of link congestion only non-CS-SR Policy traffic is being buffered or dropped.¶

For the third step 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 [RFC2597] to map traffic of CS-SR Policies into a specific queue not used by any other traffic.¶
Use of dedicated persistent unprotected adjacency-SIDs that are solely used by CS-SR traffic, managed by network design and policy (which is outside the scope of this document). These dedicated SIDs used by CS-SR Policies MUST NOT be used by features such as TI-LFA [RFC9855] for defining the repair path and microloop avoidance [I-D.bashandy-rtgwg-segment-routing-uloop] for defining the loop-free path.¶

The approach of allocating a Diffserv codepoint can leverage any of the following Per-Hop Behavior (PHB) strategies below, where P is the bandwidth of a physical link, N is the bandwidth allocated for network control and C is the bandwidth reserved for CS-SR policies:¶

Use a Assured Forwarding (AF) class queue [RFC2597] for 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.¶
Use a Expedited Forwarding (EF) class queue [RFC3246] for CS-SR Policies and limit the total utilization across all other EF queues of higher or equal priority to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C.¶
Use a Expedited Forwarding (EF) class queue for CS-SR Policies with a priority higher than all other EF queues and limit the utilization of the CS-SR Policy EF queue by traffic policing to C <= P - N.¶

The use of a dedicated Diffserv codepoint for CS-SR traffic requires the marking of all traffic steered into CS-SR Policies on the ingress with that specific codepoint consistently across the domain.¶

In addition, the headends MAY measure the actual bandwidth utilization of a CS-SR Policy to raise alarms when bandwidth utilization thresholds are passed or to request the reserved bandwidth to be adjusted. Using telemetry collection the alarms or bandwidth adjustments can also be triggered by the controller.¶

6. CS-SR Policy Creation

6.1. Policy Creation when using PCEP

6.1.1. PCC-initiated Mode

Considering the scenario illustrated in Figure 1 a CS-SR Policy between headends A and Z is instantiated by configured a SR Policy on both headend A (with Z as endpoint) and headend Z (with A as endpoint).¶

Both headend routers A and Z act as PCC and delegate path computation to the PCE using PCEP with the procedures described in Section 5.7.1 of [RFC8231]. For SR-MPLS the extensions defined in [RFC8664] are used. And SRv6 specific extensions are defined in [RFC9603].¶

The functional requirements of an CS-SR Policy expressed in Section 5 are signaled using PCEP extensions defined in [RFC5440], [RFC8800], [I-D.ietf-pce-sr-bidir-path], [RFC9862], [I-D.ietf-pce-circuit-style-pcep-extensions] and [I-D.ietf-pce-multipath].¶

The candidate paths of the CS-SR Policy are reported and updated following PCEP procedures of [RFC8231].¶

6.1.2. PCE-initiated Mode

The CS-SR Policy can be instantiated in the network between headends A and Z by a PCE using PCE-initiated procedures defined in [RFC8281]. For PCE-initiated procedures no SR Policy configuration is required on the headends A and Z acting as PCC.¶

The PCE performs path computation in line with the functional requirements expressed in Section 5 and requests the headends A and Z to initiate a SR Policy using the PCEP extensions listed in Section 6.1.1.¶

Following initiation, the candidate paths of the CS-SR Policy are reported and updated following PCEP procedures of [RFC8231] and share the same behavior as the PCC-initiated mode.¶

Connectivity verification and performance measurement is enabled via local policy configuration on the headends, as there is no standard signaling mechanism available.¶

6.2. Policy Creation when using BGP

Considering the scenario illustrated in Figure 1, instead of configuring SR Policies on both headend A (with Z as endpoint) and headend Z (with A as endpoint), a CS-SR Policy between A and Z is instantiated by a request (e.g. application API call) to the controller.¶

The controller performs path computation in line with the functional requirements expressed in Section 5 and instantiates the SR Policies in headends A and Z using the BGP extensions defined in [RFC9830].¶

Connectivity verification and performance measurement is enabled via local policy configuration on the headends, as there is no standard signaling mechanism available.¶

6.3. Maximum SID Depth Constraint

The segment lists used by CS-SR Policy candidate paths are constrained by the maximum number of segments a router can impose onto a packet.¶

When using SR-MPLS this constraint is called "Base MPLS Imposition MSD" and is advertised via IS-IS [RFC8491], OSPF [RFC8476], BGP-LS [RFC8814] and PCEP [RFC8664].¶

When using SRv6 this constraint is called "SRH Max H.encaps MSD" and is advertised via IS-IS [RFC9352], OSPF [RFC9513], BGP-LS [RFC9514] and PCEP [RFC9603].¶

The MSD constraint is typically resolved by leveraging a segment list reduction technique, such as using Node SIDs and/or Binding SIDs (BSIDs) (SR architecture [RFC8402]) in a segment list, which represents one or many hops in a given path.¶

As described in Section 5, adjacency-SIDs without local protection are used in CS-SR Policies to ensure that there is no per-hop ECMP, no localized rerouting due to topological changes, and no invocation of localized protection mechanisms, as the alternate path may not be providing the desired SLA.¶

If a CS-SR Policy path requires segment list reduction, a SR Policy can be programmed in a transit node, and its BSID can be used in the segment list of the CS-SR Policy, if the following requirements are met:¶

The transit SR Policy is unprotected, hence only has one candidate path.¶
The transit SR Policy follows the rerouting and optimization characteristics defined in Section 5 which implies the segment list of the candidate path MUST only use unprotected adjacency-SIDs.¶

This ensures that traffic for CS-SR Policies using a BSID does not get locally rerouted due to topological changes or locally protected due to failures. A transit SR Policy may be pre-programmed in the network or automatically injected in the network by a PCE.¶

9. Recovery Schemes

Various recovery (protection and restoration) schemes can be implemented for a CS-SR Policy. As described in Section 4.3 of [RFC4427], there is a subtle distinction between the terms "protection" and "restoration" based on the resource allocation done during the recovery path establishment. The same definitions apply for CS-SR Policy recovery schemes, wherein:¶

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 continuity check described in Section 10.1 or degradation, i.e., when the packet loss ratio increased beyond a configured acceptable threshold.¶

For candidate path establishment the procedures described in Section 6, for candidate path tear down the procedures in Section 8 and for state reporting the procedures in Section 7 can be used.¶

9.1. Unprotected

In the most basic scenario, no protection or restoration is required. The CS-SR Policy has only one candidate path.¶

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 separate networks and the overlay service is responsible for traffic recovery.¶

As soon as the failure(s) that brought the candidate path down are cleared, the candidate path is activated, traffic is sent across it and state is reported accordingly.¶

9.2. 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. The second candidate path MUST be computed disjoint to the first candidate path and programmed as backup in the forwarding plane as described in Section 9.3 of [RFC9256].¶

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.¶

Protection switching is bidirectional. As described in Section 10.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.¶

Two cases are to be considered when the failure condition impacting a candidate path with higher preference has cleared:¶

Revertive switching: re-activate the higher 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.¶

9.3. Restoration

9.3.1. 1+R Restoration

Similarly to 1:1 protection described in Section 9.2, in this recovery scheme the CS-SR Policy has two candidate paths.¶

To avoid pre-allocating protection bandwidth by the controller ahead of failures, but still being able to recover traffic flow over an alternate path through the network in a deterministic way (maintaining the required bandwidth commitment), the second candidate path with lower preference is established "on demand" and activated upon failure of the first candidate path.¶

As soon as failure(s) that brought the first candidate path down are cleared, the second candidate path is getting torn down and traffic is reverted to the first candidate path.¶

Restoration and reversion behavior is bidirectional. As described in Section 10.1, both headends use continuity check 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.¶

9.3.2. 1:1+R Restoration

For further resiliency in case of multiple concurrent failures that could bring down both candidate paths of 1:1 protection described in Section 9.2, a third candidate path with a preference lower than the other two candidate paths (in this section referred to as first and second candidate path) is added to the CS-SR Policy to enable restoration.¶

There are two possible operating models:¶

R established upon double failure¶

As in Section 9.3.1, to avoid pre-allocating additional bandwidth by the controller ahead of failures, the third candidate path may only be requested when both candidate paths are affected by failures.¶

As soon as either the first or second candidate path recovers, traffic will be reverted and the third candidate path MUST be torn down.¶

R pre-established after single failure¶

Alternatively, the third candidate path can also be requested, pre-computed and programmed as backup already whenever either the first or second candidate path go down with the downside of more bandwidth being set aside ahead of time. When doing so, the third candidate path MUST be computed disjoint to the still operational candidate path.¶

The third candidate path will get activated and carry traffic when further failures lead to both the first and second candidate path being down.¶

As long as either the first or the second candidate path is active, the third candidate path is kept, updated (if needed) to ensure diversity to the active candidate path and is not carrying traffic.¶

Once both, the first and the second candidate path have recovered, the third candidate path is torn down.¶

Again, restoration and reversion behavior is bidirectional. As described in Section 10.1, both headends use continuity check 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.¶

10. Operations, Administration, and Maintenance (OAM)

10.1. Continuity Check

The continuity check for each segment list on both headends MAY be done using¶

Simple Two-Way Active Measurement Protocol (STAMP) in loopback measurement mode as described in section 6 and the session state described in section 11 of [I-D.ietf-spring-stamp-srpm-mpls] for SR-MPLS and [I-D.ietf-spring-stamp-srpm-srv6] for SRv6.¶
Bidirectional Forwarding Detection (BFD) [RFC5880].¶
Seamless BFD (S-BFD) [RFC7880].¶

The use of STAMP is RECOMMENDED as it leverages a single protocol for both continuity check and performance measurement (see Section 10.2 of this document) and allows for a single session to be used, depending on the desired performance measurement session mode (two-way described in section 4, one-way described in section 5 or loopback described in section 6 of [I-D.ietf-spring-stamp-srpm-mpls] for SR-MPLS and [I-D.ietf-spring-stamp-srpm-srv6] for SRv6).¶

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 forwarded along the forward path to the tailend and along the reverse path back to the headend.¶

To be able to send STAMP test packets for loopback measurement mode, the STAMP Session-Sender (i.e., the headend) needs to acquire the segment list information of the reverse path:¶

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].¶

For cases where multiple segment lists are used by a candidate path, the headends will declare a candidate path down after continuity check has failed for one or more segment lists because the bandwidth requirement of the candidate path can no longer be met.¶

10.2. Performance Measurement

Assuming a single STAMP session in loopback mode is used for continuity check and performance measurement, the round-trip delay can be measured and the round-trip loss can be estimated as described in section 8 of [I-D.ietf-spring-stamp-srpm-mpls] for SR-MPLS and [I-D.ietf-spring-stamp-srpm-srv6] for SRv6.¶

Considering that candidate paths are co-routed, the delay in the forward and reverse direction can be assumed to be similar. Under this assumption, one-way delay can be derived by dividing the round-trip delay by two.¶

10.3. Candidate Path Validity Verification

A stateful PCE/controller is in sync with the headend routers in the network topology and the CS-SR Policies provisioned on them. As described in Section 5 a path MUST NOT be automatically recomputed by the controller after or optimized for topology changes unless it is a restoration path.¶

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, such as insufficient bandwidth, diversity constraint no longer met or latency constraint exceeded and only the stateful PCE/controller can detect this and not the headend routers themselves.¶

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.¶

12. Security Considerations

This document does provide guidance on how to implement a CS-SR Policy leveraging existing mechanisms and protocol extensions. As such, it does not introduce any new security considerations.¶

The MPLS or SRv6 network is assumed to be a trusted and secure domain. Attackers who manage to send spoofed packets into the domain could easily disrupt services leveraging CS-SR Policies. The protections against such attacks are described by considerations in Section 4.2 of [RFC5920] and in Section 8 of [RFC8402].¶

Security considerations for the SR Policy Architecture defined in Section 10 of [RFC9256] do apply to this document as well.¶

To satisfy the bandwidth requirement of CS-SR Policies, the Differentiated Service architecture [RFC2475] is leveraged and the security considerations in Section 6 of [RFC2475] do apply. If a dedicated Diffserv codepoint is assigned to CS-SR Policies, the use by any other traffic is to be prevented to ensure QoS is properly enforced.¶

Further a misconfiguration of requested bandwidth for CS-SR Policies can lead to blocking out other CS-SR Policies from consuming available bandwidth and bandwidth starvation of non-CS-SR traffic.¶

Depending on how a CS-SR Policy is instantiated and reported, the following security considerations do apply¶

PCEP:¶
- Section 7 of [RFC8664]¶
- Section 6 of [RFC9603]¶
- Section 8 of [RFC9862]¶
- Section 6 of [I-D.ietf-pce-sr-bidir-path]¶
- Section 7 of [I-D.ietf-pce-circuit-style-pcep-extensions]¶
- Section 10 of [I-D.ietf-pce-multipath]¶
- Section 8 of [I-D.ietf-idr-sr-policy-path-segment]¶
BGP:¶
- Section 7 of [RFC9830]¶
- Section 9 of [RFC9857]¶
Configuration:¶
- Section 8 of [I-D.ietf-spring-sr-policy-yang]¶

Depending on the protocol used for OAM, the following security considerations do apply¶

STAMP: Section 15 of [I-D.ietf-spring-stamp-srpm-mpls] and [I-D.ietf-spring-stamp-srpm-srv6]¶
BFD/S-BFD: Section 9 of [RFC5880] and Section 11 of [RFC7880]¶

15. References

15.1. Normative References

[I-D.ietf-idr-sr-policy-path-segment]: Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR Policy Extensions for Path Segment and Bidirectional Path", Work in Progress, Internet-Draft, draft-ietf-idr-sr-policy-path-segment-14, 11 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment-14>.
[I-D.ietf-pce-circuit-style-pcep-extensions]: Sidor, S., Maheshwari, P., Stone, A., Jalil, L., and S. Peng, "Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies", Work in Progress, Internet-Draft, draft-ietf-pce-circuit-style-pcep-extensions-13, 6 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-circuit-style-pcep-extensions-13>.
[I-D.ietf-pce-multipath]: Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., Bidgoli, H., Peng, S., and S. Sidor, "Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information", Work in Progress, Internet-Draft, draft-ietf-pce-multipath-19, 2 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-19>.
[I-D.ietf-pce-sr-bidir-path]: Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs", Work in Progress, Internet-Draft, draft-ietf-pce-sr-bidir-path-21, 4 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-21>.
[I-D.ietf-spring-sr-policy-yang]: Saleh, T., Raza, S. K., Zhuang, S., Matsushima, S., and V. P. Beeram, "YANG Data Model for Segment Routing Policy", Work in Progress, Internet-Draft, draft-ietf-spring-sr-policy-yang-06, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-policy-yang-06>.
[I-D.ietf-spring-stamp-srpm-mpls]: Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R. F. Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-mpls-00, 2 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-mpls-00>.
[I-D.ietf-spring-stamp-srpm-srv6]: Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R. F. Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-srv6-00, 2 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-srv6-00>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2475]: Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/rfc/rfc2475>.
[RFC4271]: Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.
[RFC5440]: Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/rfc/rfc5440>.
[RFC5920]: Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/rfc/rfc5920>.
[RFC6391]: Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/rfc/rfc6391>.
[RFC6437]: Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/rfc/rfc6437>.
[RFC6790]: Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/rfc/rfc6790>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8231]: Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/rfc/rfc8231>.
[RFC8281]: Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/rfc/rfc8281>.
[RFC8402]: Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8660]: Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/rfc/rfc8660>.
[RFC8664]: Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/rfc/rfc8664>.
[RFC8697]: Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, <https://www.rfc-editor.org/rfc/rfc8697>.
[RFC8754]: Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8800]: Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, July 2020, <https://www.rfc-editor.org/rfc/rfc8800>.
[RFC9256]: Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/rfc/rfc9256>.
[RFC9603]: Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, <https://www.rfc-editor.org/rfc/rfc9603>.
[RFC9716]: Hegde, S., Arora, K., Srivastava, M., Ninan, S., and N. Kumar, "Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks", RFC 9716, DOI 10.17487/RFC9716, February 2025, <https://www.rfc-editor.org/rfc/rfc9716>.
[RFC9830]: Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025, <https://www.rfc-editor.org/rfc/rfc9830>.
[RFC9857]: Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H., and J. Tantsura, "Advertisement of Segment Routing Policies Using BGP - Link State", RFC 9857, DOI 10.17487/RFC9857, October 2025, <https://www.rfc-editor.org/rfc/rfc9857>.
[RFC9862]: Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, <https://www.rfc-editor.org/rfc/rfc9862>.

15.2. Informative References

[I-D.bashandy-rtgwg-segment-routing-uloop]: Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., Francois, P., and P. Psenak, "Loop avoidance using Segment Routing", Work in Progress, Internet-Draft, draft-bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024, <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-17>.
[IEEE802.1AX]: IEEE, "IEEE Standard for Ethernet", May 2020, <https://ieeexplore.ieee.org/document/9105034>.
[RFC2597]: Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/rfc/rfc2597>.
[RFC3246]: Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/rfc/rfc3246>.
[RFC4427]: Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/rfc/rfc4427>.
[RFC4448]: Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/rfc/rfc4448>.
[RFC4553]: Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <https://www.rfc-editor.org/rfc/rfc4553>.
[RFC4842]: Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, DOI 10.17487/RFC4842, April 2007, <https://www.rfc-editor.org/rfc/rfc4842>.
[RFC5086]: Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, <https://www.rfc-editor.org/rfc/rfc5086>.
[RFC5880]: Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/rfc/rfc5880>.
[RFC7880]: Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/rfc/rfc7880>.
[RFC8476]: Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, <https://www.rfc-editor.org/rfc/rfc8476>.
[RFC8491]: Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/rfc/rfc8491>.
[RFC8665]: Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/rfc/rfc8665>.
[RFC8667]: Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/rfc/rfc8667>.
[RFC8668]: Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/rfc/rfc8668>.
[RFC8814]: Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State", RFC 8814, DOI 10.17487/RFC8814, August 2020, <https://www.rfc-editor.org/rfc/rfc8814>.
[RFC8986]: Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9085]: Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/rfc/rfc9085>.
[RFC9352]: Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/rfc/rfc9352>.
[RFC9356]: Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2 Bundle Member Link Attributes in OSPF", RFC 9356, DOI 10.17487/RFC9356, January 2023, <https://www.rfc-editor.org/rfc/rfc9356>.
[RFC9513]: Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, <https://www.rfc-editor.org/rfc/rfc9513>.
[RFC9514]: Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, <https://www.rfc-editor.org/rfc/rfc9514>.
[RFC9801]: Gringeri, S., Whittaker, J., Leymann, N., Schmutzer, C., Ed., and C. Brown, "Private Line Emulation over Packet Switched Networks", RFC 9801, DOI 10.17487/RFC9801, July 2025, <https://www.rfc-editor.org/rfc/rfc9801>.
[RFC9855]: Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute Using Segment Routing", RFC 9855, DOI 10.17487/RFC9855, October 2025, <https://www.rfc-editor.org/rfc/rfc9855>.