Circuit Style Segment Routing Policies
draft-schmutzer-pce-cs-sr-policy-00

Document Type Active Internet-Draft (individual)
Authors Christian Schmutzer  , Clarence Filsfils  , Zafar Ali  , Francois Clad 
Last updated 2021-09-30
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                  C. Schmutzer, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Informational                               Z. Ali, Ed.
Expires: 3 April 2022                                            F. Clad
                                                     Cisco Systems, Inc.
                                                       30 September 2021

                 Circuit Style Segment Routing Policies
                  draft-schmutzer-pce-cs-sr-policy-00

Abstract

   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 https://datatracker.ietf.org/drafts/current/.

   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.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Schmutzer, et al.         Expires 3 April 2022                  [Page 1]
Internet-Draft                   cs-srte                  September 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements of CS-SR Policies  . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  PCE Topology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  CS-SR Policy Characteristics  . . . . . . . . . . . . . . . .   5
   7.  CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . .   5
   8.  Operations, Administration, and Maintenance (OAM) . . . . . .   6
     8.1.  Liveness  . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.2.  Performance Measurement . . . . . . . . . . . . . . . . .   7
   9.  Recovery Schemes  . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Unprotected . . . . . . . . . . . . . . . . . . . . . . .   7
     9.2.  1:1 Protection  . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     14.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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.

Schmutzer, et al.         Expires 3 April 2022                  [Page 2]
Internet-Draft                   cs-srte                  September 2021

   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

Schmutzer, et al.         Expires 3 April 2022                  [Page 3]
Internet-Draft                   cs-srte                  September 2021

   *  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

Schmutzer, et al.         Expires 3 April 2022                  [Page 4]
Internet-Draft                   cs-srte                  September 2021

   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

         o  may be pre-computed

         o  may be pre-programmed

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

Schmutzer, et al.         Expires 3 April 2022                  [Page 5]
Internet-Draft                   cs-srte                  September 2021

   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

      -  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]) :

         o  R flag is always set to 0 (forward path)

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

Schmutzer, et al.         Expires 3 April 2022                  [Page 6]
Internet-Draft                   cs-srte                  September 2021

   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.

Schmutzer, et al.         Expires 3 April 2022                  [Page 7]
Internet-Draft                   cs-srte                  September 2021

   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.

Schmutzer, et al.         Expires 3 April 2022                  [Page 8]
Internet-Draft                   cs-srte                  September 2021

10.  Security Considerations

   TO BE ADDED

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.
   Email: brfoster@cisco.com

   Bertrand Duvivier
   Cisco System, Inc.
   Email: bduvivie@cisco.com

   Stephane Litkowski
   Cisco Systems, Inc.
   Email: slitkows@cisco.com

14.  References

14.1.  Normative References

   [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/info/rfc2119>.

14.2.  Informative References

   [I-D.ietf-lsr-isis-srv6-extensions]
              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, 18 June 2021,
              <https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
              extensions-17.txt>.

Schmutzer, et al.         Expires 3 April 2022                  [Page 9]
Internet-Draft                   cs-srte                  September 2021

   [I-D.ietf-lsr-ospfv3-srv6-extensions]
              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, 15
              February 2021, <https://www.ietf.org/archive/id/draft-
              ietf-lsr-ospfv3-srv6-extensions-02.txt>.

   [I-D.ietf-pce-local-protection-enforcement]
              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, 5 August 2021,
              <https://www.ietf.org/archive/id/draft-ietf-pce-local-
              protection-enforcement-03.txt>.

   [I-D.ietf-pce-multipath]
              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, 27 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-pce-multipath-
              01.txt>.

   [I-D.ietf-pce-segment-routing-ipv6]
              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, 27
              May 2021, <https://www.ietf.org/internet-drafts/draft-
              ietf-pce-segment-routing-ipv6-09.txt>.

   [I-D.ietf-pce-segment-routing-policy-cp]
              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, 23 May 2021,
              <https://www.ietf.org/archive/id/draft-ietf-pce-segment-
              routing-policy-cp-05.txt>.

   [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) Paths", Work in Progress, Internet-Draft, draft-ietf-
              pce-sr-bidir-path-08, 9 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
              path-08.txt>.

Schmutzer, et al.         Expires 3 April 2022                 [Page 10]
Internet-Draft                   cs-srte                  September 2021

   [I-D.ietf-spring-segment-routing-policy]
              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, 28 May 2021,
              <https://www.ietf.org/archive/id/draft-ietf-spring-
              segment-routing-policy-13.txt>.

   [I-D.ietf-spring-stamp-srpm]
              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,
              13 September 2021, <https://www.ietf.org/archive/id/draft-
              ietf-spring-stamp-srpm-02.txt>.

   [RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
              DOI 10.17487/RFC1925, April 1996,
              <https://www.rfc-editor.org/info/rfc1925>.

   [RFC3209]  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, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC3386]  Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and
              Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386,
              November 2002, <https://www.rfc-editor.org/info/rfc3386>.

   [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/info/rfc4427>.

   [RFC4872]  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, May 2007,
              <https://www.rfc-editor.org/info/rfc4872>.

   [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/info/rfc5440>.

Schmutzer, et al.         Expires 3 April 2022                 [Page 11]
Internet-Draft                   cs-srte                  September 2021

   [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/info/rfc8231>.

   [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/info/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/info/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/info/rfc8664>.

   [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/info/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/info/rfc8667>.

   [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/info/rfc8697>.

   [RFC8745]  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, March 2020,
              <https://www.rfc-editor.org/info/rfc8745>.

Schmutzer, et al.         Expires 3 April 2022                 [Page 12]
Internet-Draft                   cs-srte                  September 2021

   [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/info/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/info/rfc8800>.

   [RFC9059]  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, June 2021,
              <https://www.rfc-editor.org/info/rfc9059>.

Authors' Addresses

   Christian Schmutzer (editor)
   Cisco Systems, Inc.

   Email: cschmutz@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.

   Email: cfilsfil@cisco.com

   Zafar Ali (editor)
   Cisco Systems, Inc.

   Email: zali@cisco.com

   Francois Clad
   Cisco Systems, Inc.

   Email: fclad@cisco.com

Schmutzer, et al.         Expires 3 April 2022                 [Page 13]