Internet-Draft cs-srte September 2021
Schmutzer, et al. Expires 3 April 2022 [Page]
Network Working Group
Intended Status:
C. Schmutzer, Ed.
Cisco Systems, Inc.
C. Filsfils
Cisco Systems, Inc.
Z. Ali, Ed.
Cisco Systems, Inc.
F. Clad
Cisco Systems, Inc.

Circuit Style Segment Routing Policies


This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for strict bandwidth guarantees, 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).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 April 2022.

1. Introduction

There are several applications that require strict bandwidth guarantees, end-to-end recovery and persistent paths through the network. 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 adjacency-SIDs defined in the SR architecture [RFC8402] together with a stateful Path Computation Element (PCE) [RFC8231] can be used to statisfy those requirements. It includes how end-to-end recovery and path integrity monitoring can be implemented.

SR policies that satisy those requirements are called "circuit-style" SR policies (CS-SR policies).

2. Terminology

  • 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

3. Requirements of CS-SR Policies

The requirements of circuit-style SR policies (CS-SR policies) are as follows:

  • Persistent end2end traffic engineered paths that provide predictable and identical latency in both directions
  • Strict bandwidth commitment per path to ensure no impact on the Service Level Agreement (SLA) due to changing network load from other services
  • End2end protection (<50msec protection switching) and restoration mechanisms
  • Monitoring and maintenance of path integrity
  • Data plane remains up while control plane is down

4. Architecture Overview

CS-SR policies are following the segment routing architecture [RFC8402] and SR policy architecture [I-D.ietf-spring-segment-routing-policy].

By nature of CS-SR policies, paths wil be computed and maintained by 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.

A simplified architecture is shown in Figure 1.

      +-------------->|     PCE      |<--------------+
      |               +--------------+               |
      |                                              |
      |                                              |
      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 Architecture

5. PCE Topology

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

Existing IGP extensions defined in [RFC8667] and [RFC8665] can be used to distribute the topology information including those persistent and unprotected Adj-SIDs when using a MPLS dataplane [RFC8660]. When using a SRv6 dataplane [RFC8754] the IGP extensions defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] apply.

6. CS-SR Policy Characteristics

A CS-SR policy had 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)
  • Not automatically recomputed or reoptimized : the SID list of a candidate path must not change automatically (for example upon topology change)
  • Multiple candiate 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 9) , lower priority candidate paths

      • may be pre-computed
      • may be pre-programmed
      • may have to be disjoint
  • Liveness and performance measurement is activated on each candidate path (Section 8)

7. CS-SR Policy Creation

A CS-SR policy between A and Z is configured both on A (with Z as endpoint) and Z (with A as endpoint) as shown in Figure 1.

Both nodes A and Z act as PCC and delegate path computation to the PCE using the extensions defined in [RFC8664]. Considering a CS-SR policy that has no protection/restoration requirement, 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 the local protection requirements

  • 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 candiate 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.

8. Operations, Administration, and Maintenance (OAM)

8.1. Liveness

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 dataplane operations will make those packets get switched along the forward path to the tailend and along the reverse path back to the headend.

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]

8.2. Performance Measurement

The same STAMP session used for liveliness monitoring 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.

The same STAMP session can also be used to estimate round-trip loss as described in section 5 of [I-D.ietf-spring-stamp-srpm].

9. Recovery Schemes

Various protection and restoration schemes can be implemented. The terms "protection" and "restoration" are used with 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

When protection and/or restoration is required the SR polices are configured with two or more candidate paths. The PCRpt messages include the "Path Protection Association" object (type 1) defined in [RFC8745].

9.1. Unprotected

In the most basic scenario no protection nor restoration is required. The SR-policy only has one candidate path configured.

In case of a failure the CS-SR policy will go down and traffic will not be recovered.

9.2. 1:1 Protection

For fast recovery against failures a second candidate with a lower preference is configured. Its path is pre-computed and pre-programmed so that upon detection of a failure traffic can be immediately directed to this alternate path by the headend.

For the highest preference candidate path the parameters of the "Path Protection Association TLV" defined in [RFC8745] are set as follows:

  • Protection Type (PT) is set to 0x04 to indicate "1:N Protection with Extra-Traffic" as defined in section 14.1 of [RFC4872]
  • P bit is set to 0 to indicate this is the "working" path
  • S bit is set to 0 but will be ignored

For the lower preference candidate path the parameters are as follows:

  • Protection Type (PT) is set to 0x04 to indicate "1:N Protection with Extra-Traffic"
  • P is set to 1 to indicate this is the "protect" path
  • S bit set to 0 to indicate "primary"

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.

As described in Section 8.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 and therefore no protection switch coordination is required.

11. IANA Considerations

This document has no IANA actions.

12. Acknowledgements

The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh Gandhi for providing their review comments.

13. Contributors

Contributors' Addresses

Brent Foster
Cisco Systems, Inc.

Bertrand Duvivier
Cisco System, Inc.

Stephane Litkowski
Cisco Systems, Inc.

14. References

14.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

14.2. Informative References

Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-srv6-extensions-17, , <>.
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-lsr-ospfv3-srv6-extensions-02, , <>.
Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan, "Local Protection Enforcement in PCEP", Work in Progress, Internet-Draft, draft-ietf-pce-local-protection-enforcement-03, , <>.
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for Signaling Multipath Information", Work in Progress, Internet-Draft, draft-ietf-pce-multipath-01, , <>.
Li, C., Negi, M., Sivabalan, S., Koldychev, M., Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, , <>.
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-05, , <>.
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-pce-sr-bidir-path-08, , <>.
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-13, , <>.
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, B., and R. Foote, "Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-02, , <>.
Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, , <>.
Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, , <>.
Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386, , <>.
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, , <>.
Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, , <>.
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <>.
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, , <>.
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <>.
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, , <>.
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, , <>.
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, , <>.
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, , <>.
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, , <>.
Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE", RFC 8745, DOI 10.17487/RFC8745, , <>.
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, , <>.
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, , <>.
Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 9059, DOI 10.17487/RFC9059, , <>.

Authors' Addresses

Christian Schmutzer (editor)
Cisco Systems, Inc.
Clarence Filsfils
Cisco Systems, Inc.
Zafar Ali (editor)
Cisco Systems, Inc.
Francois Clad
Cisco Systems, Inc.