idnits 2.17.00 (12 Aug 2021) /tmp/idnits57301/draft-schmutzer-pce-cs-sr-policy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (5 May 2022) is 9 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC1925' is defined on line 695, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-sidor-pce-circuit-style-pcep-extensions-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Schmutzer, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Informational Z. Ali, Ed. 5 Expires: 6 November 2022 F. Clad 6 Cisco Systems, Inc. 7 P. Maheshwari 8 Airtel India 9 R. Rokui 10 Ciena 11 A. Stone 12 Nokia 13 L. Jalil 14 Verizon 15 S. Peng 16 Huawei Technologies 17 T. Saad 18 Juniper Networks 19 D. Voyer 20 Bell Canada 21 5 May 2022 23 Circuit Style Segment Routing Policies 24 draft-schmutzer-pce-cs-sr-policy-02 26 Abstract 28 This document describes how Segment Routing (SR) policies can be used 29 to satisfy the requirements for strict bandwidth guarantees, end-to- 30 end recovery and persistent paths within a segment routing network. 31 SR policies satisfying these requirements are called "circuit-style" 32 SR policies (CS-SR policies). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 November 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. CS-SR Policy Characteristics . . . . . . . . . . . . . . . . 5 70 5. CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Maximum Segment Depth . . . . . . . . . . . . . . . . . . 7 72 6. Recovery Schemes . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. Unprotected . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.2. 1:1 Protection . . . . . . . . . . . . . . . . . . . . . 9 75 6.3. Restoration . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.3.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 10 77 6.3.2. 1:1+R Restoration . . . . . . . . . . . . . . . . . . 10 78 7. Operations, Administration, and Maintenance (OAM) . . . . . . 11 79 7.1. Connectivity Verification . . . . . . . . . . . . . . . . 11 80 7.2. Performance Measurement . . . . . . . . . . . . . . . . . 11 81 7.3. Candidate Path Validity Verification . . . . . . . . . . 12 82 8. External Commands . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Candidate Path Switchover . . . . . . . . . . . . . . . . 12 84 8.2. Candidate Path Recomputation . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 13.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Segment routing does allow for a single network to carry both typical 97 IP (connection-less) services and connection-oriented transport 98 services commonly referred to as "private lines". IP services 99 typically require ECMP and TI-LFA, while transport services that 100 normally are delivered via dedicated circuit-switched SONET/SDH or 101 OTN networks do require: 103 * Persistent end-to-end traffic engineered paths that provide 104 predictable and identical latency in both directions 106 * Strict bandwidth commitment per path to ensure no impact on the 107 Service Level Agreement (SLA) due to changing network load from 108 other services 110 * End-to-end protection (<50msec protection switching) and 111 restoration mechanisms 113 * Monitoring and maintenance of path integrity 115 * Data plane remaining up while control plane is down 117 Such a "transport centric" behavior is referred to as "circuit-style" 118 in this document. 120 This document describes how SR policies 121 [I-D.ietf-spring-segment-routing-policy] and the use of adjacency- 122 SIDs defined in the SR architecture [RFC8402] together with a 123 stateful Path Computation Element (PCE) [RFC8231] can be used to 124 satisfy those requirements. It includes how end-to-end recovery and 125 path integrity monitoring can be implemented. 127 SR policies that satisfy those requirements are called "circuit- 128 style" SR policies (CS-SR policies). 130 2. Terminology 132 * BSID : Binding Segment Identifier 134 * CS-SR : Circuit-Style Segment Routing 136 * ID : Identifier 138 * LSP : Label Switched Path 140 * LSPA : LSP attributes 141 * OAM : Operations, Administration and Maintenance 143 * OF : Objective Function 145 * PCE : Path Computation Element 147 * PCEP : Path Computation Element Communication Protocol 149 * PT : Protection Type 151 * SID : Segment Identifier 153 * SLA : Service Level Agreement 155 * SR : Segment Routing 157 * STAMP : Simple Two-Way Active Measurement Protocol 159 * TI-LFA : Topology Independent Loop Free Alternate 161 * TLV : Type Length Value 163 3. Reference Model 165 The reference model for CS-SR policies is following the Segment 166 Routing Architecture [RFC8402] and SR Policy Architecture 167 [I-D.ietf-spring-segment-routing-policy] and is depicted in Figure 1. 169 +--------------+ 170 +-------------->| PCE |<--------------+ 171 | +--------------+ | 172 | | 173 | | 174 v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v 175 +-------+ +-------+ 176 | |=========================================>| | 177 | A | SR-policy from A to Z | Z | 178 | |<=========================================| | 179 +-------+ SR-policy from Z to A +-------+ 181 Figure 1: Circuit-style SR Policy Reference Model 183 By nature of CS-SR policies, paths will be computed and maintained by 184 a stateful PCE defined in [RFC8231]. The stateful PCE provides a 185 consistent simple mechanism for initializing the co-routed 186 bidirectional end to end paths, performing bandwidth allocation 187 control, as well as monitoring facilities to ensure SLA compliance 188 for the live of the CS-SR Policy. When using a MPLS data plane 190 [RFC8660], PCEP extensions defined in [RFC8664] will be used. When 191 using a SRv6 data plane [RFC8754], PCEP extensions defined in 192 [I-D.ietf-pce-segment-routing-ipv6] will be used. 194 In order to satisfy the requirements of CS-SR policies, each link in 195 the topology MUST have: 197 * An adjacency-SID which is: 199 - Manually allocated or persistent : to ensure that its value 200 does not change after a node reload 202 - Non-protected : to avoid any local TI-LFA protection to happen 203 upon interface/link failures 205 * The bandwidth available for CS-SR policies specified 207 * A per-hop behavior ([RFC3246] or [RFC2597]) that ensures that the 208 specified bandwidth is available to CS-SR policies at all times 209 independent of any other traffic 211 When using a MPLS data plane [RFC8660] existing IGP extensions 212 defined in [RFC8667] and [RFC8665] and BGP-LS defined in [RFC9085] 213 can be used to distribute the topology information including those 214 persistent and unprotected adjacency-SIDs. 216 When using a SRv6 data plane [RFC8754] the IGP extensions defined in 217 [I-D.ietf-lsr-isis-srv6-extensions] and 218 [I-D.ietf-lsr-ospfv3-srv6-extensions] and BGP-LS extensions in 219 [I-D.ietf-idr-bgpls-srv6-ext] apply. 221 4. CS-SR Policy Characteristics 223 A CS-SR policy has the following characteristics: 225 * Requested bandwidth : bandwidth to be reserved for the CS-SR 226 policy 228 * Bidirectional co-routed : a CS-SR policy between A and Z is an 229 association of an SR-Policy from A to Z and an SR-Policy from Z to 230 A following the same path(s) 232 * Deterministic and persistent paths : segment lists with strict 233 hops using unprotected adjacency-SIDs 235 * Not automatically recomputed or reoptimized : the SID list of a 236 candidate path must not change automatically to a SID list 237 representing a different path (for example upon topology change) 239 * Multiple candidate paths in case of protection/restoration: 241 - Following the SR policy architecture, the highest preference 242 valid path is carrying traffic 244 - Depending on the protection/restoration scheme (Section 6), 245 lower priority candidate paths 247 o may be pre-computed 249 o may be pre-programmed 251 o may have to be disjoint 253 * Connectivity verification and performance measurement is activated 254 on each candidate path (Section 7) 256 5. CS-SR Policy Creation 258 A CS-SR policy between A and Z is configured both on A (with Z as 259 endpoint) and Z (with A as endpoint) as shown in Figure 1. 261 Both nodes A and Z act as PCC and delegate path computation to the 262 PCE using the extensions defined in [RFC8664]. The PCRpt message 263 sent from the headends to the PCE contains the following parameters: 265 * BANDWIDTH object (Section 7.7 of [RFC5440]) : to indicate the 266 requested bandwidth 268 * LSPA object (section 7.11 of [RFC5440]) : to indicate that no 269 local protection requirements 271 - L flag set to 0 : no local protection 273 - E flag set to 1 : protection enforcement (section 5 of 274 [I-D.ietf-pce-local-protection-enforcement]) 276 * ASSOCIATION object ([RFC8697]) : 278 - Type : Double-sided Bidirectional with Reverse LSP Association 279 ([I-D.ietf-pce-sr-bidir-path]) 281 - Bidirectional Association Group TLV ([RFC9059]) : 283 o R flag is always set to 0 (forward path) 285 o C flag is always set to 1 (co-routed) 287 If the SR-policies are configured with more than one candidate path, 288 a PCEP request is sent per candidate path. Each PCEP request does 289 include the "SR Policy Association" object (type 6) as defined in 290 [I-D.ietf-pce-segment-routing-policy-cp] to make the PCE aware of the 291 candidate path belonging to the same policy. 293 The signaling extensions described in 294 [I-D.sidor-pce-circuit-style-pcep-extensions] are used to ensure that 296 * Path determinism is achieved by the PCE only using segment lists 297 representing a strict hop by hop path using unprotected adjacency- 298 SIDs. 300 * Path persistency across node reloads in the network is achieved by 301 the PCE only including manually configured adjacency-SIDs in its 302 path computation response. 304 * Persistency across network changes is achieved by the PCE not 305 performing periodic nor network event triggered re-optimization. 307 Bandwidth adjustment can be requested after initial creation by 308 signaling both requested and operational bandwidth in the BANDWIDTH 309 object but the PCE is not allowed to respond with a changed path. 311 As discussed in section 3.2 of [I-D.ietf-pce-multipath] it may be 312 necessary to use load-balancing across multiple paths to satisfy the 313 bandwidth requirement of a candidate path. In such a case the PCE 314 will notify the PCC to install multiple segment lists using the 315 signaling procedures described in section 5.3 of 316 [I-D.ietf-pce-multipath]. 318 5.1. Maximum Segment Depth 320 A Segment Routed path defined by a segment list is constrained by 321 maximum segment depth (MSD), which is the maximum number of segments 322 a router can impose onto a packet. [RFC8491], [RFC8476], [RFC8814] 323 and [RFC8664] provide the necessary capabilities for a PCE to 324 determine the MSD capability of a router. The MSD constraint is 325 typically resolved by leveraging a label stack reduction technique, 326 such as using Node SIDs and/or BSIDs (SR architecture [RFC8402]) in a 327 segment list, which represents one or many hops in a given path. 329 As described in Section 4, adjacency-SIDs without local protection 330 are to be used for CS-SR policies to ensure no ECMP, no rerouting due 331 to topological changes nor localized protection is being invoked on 332 the traffic, as the alternate path may not be providing the desired 333 SLA. 335 If a CS-SR Policy path requires SID List reduction, a Node SID cannot 336 be utilized as it is eligible for traffic rerouting following IGP re- 337 convergence. However, a BSID can be programmed to a transit node, if 338 the following requirements are met: 340 * The BSID is unprotected, hence only has one candidate path 342 * The BSID follows the rerouting and optimization characteristics 343 defined in Section 4 which implies the SID list of the candidate 344 path MUST only use unprotected adjacency-SIDs. 346 This ensures that any CS-SR policies in which the BSID provides 347 transit for do not get rerouted due to topological changes or 348 protected due to failures. A BSID may be pre-programmed in the 349 network or automatically injected in the network by a PCE. 351 6. Recovery Schemes 353 Various protection and restoration schemes can be implemented. The 354 terms "protection" and "restoration" are used with the same subtle 355 distinctions outlined in section 1 of [RFC4872], [RFC4427] and 356 [RFC3386] respectively. 358 * Protection : another candidate path is computed and fully 359 established in the data plane and ready to carry traffic 361 * Restoration : a candidate path may be computed and may be 362 partially established but is not ready to carry traffic 364 The term "failure" is used to represent both "hard failures" such 365 complete loss of connectivity detected by Section 7.1 or degradation, 366 a packet loss ratio, beyond a configured acceptable threshold. 368 6.1. Unprotected 370 In the most basic scenario no protection nor restoration is required. 371 The CS-SR policy has only one candidate path configured. This 372 candidate path is established, activated (O field in LSP object is 373 set to 2) and is carrying traffic. 375 In case of a failure the CS-SR policy will go down and traffic will 376 not be recovered. 378 Typically two CS-SR policies are deployed either within the same 379 network with disjoint paths or in two completely separate networks 380 and the overlay service is responsible for traffic recovery. 382 6.2. 1:1 Protection 384 For fast recovery against failures the CS-SR policy is configured 385 with two candidate paths. Both paths are established but only the 386 candidate with higher preference is activated (O field in LSP object 387 is set to 2) and is carrying traffic. The candidate path with lower 388 preference has its O field in LSP object set to 1. 390 Appropriate routing of the protect path diverse from the working path 391 can be requested from the PCE by using the "Disjointness Association" 392 object (type 2) defined in [RFC8800] in the PCRpt messages. The 393 disjoint requirements are communicated in the "DISJOINTNESS- 394 CONFIGURATION TLV" 396 * L bit set to 1 for link diversity 398 * N bit set to 1 for node diversity 400 * S bit set to 1 for SRLG diversity 402 * T bit set to enforce strict diversity 404 The P bit may be set for first candidate path to allow for finding 405 the best working path that does satisfy all constraints without 406 considering diversity to the protect path. 408 The "Objective Function (OF) TLV" as defined in section 5.3 of 409 [RFC8800] may also be added to minimize the common shared resources. 411 Upon a failure impacting the candidate path with higher preference 412 carrying traffic, the candidate path with lower preference is 413 activated immediately and traffic is now sent across it. 415 Protection switching is bidirectional. As described in Section 7.1, 416 both headends will generate and receive their own loopback mode test 417 packets, hence even a unidirectional failure will always be detected 418 by both headends without protection switch coordination required. 420 Two cases are to be considered when the failure impacting the 421 candidate path with higher preference is cleared: 423 * Revertive switching : re-activate the candidate path, change O 424 field from 0 to 2 and start sending traffic over it 426 * Non-revertive switching : do not activate the candidate path, 427 change O field from 0 to 1, keep the second candidate path active 428 with O field set to 2 and continue sending traffic over it 430 6.3. Restoration 432 6.3.1. 1+R Restoration 434 Compared to 1:1 protection described in Section 6.2, this restoration 435 scheme avoids pre-allocating protection bandwidth in steady state, 436 while still being able to recover traffic flow in case of a network 437 failure in a deterministic way (maintain required bandwidth 438 commitment) 440 The CS-SR policy is configured with two candidate paths. The 441 candidate path with higher preference is established, activated (O 442 field in LSP object is set to 2) and is carrying traffic. 444 The second candidate path with lower preference is only established 445 and activated (O field in LSP object is set to 2) upon a failure 446 impacting the first candidate path in order to send traffic over an 447 alternate path through the network around the failure with 448 potentially relaxed constraints but still satisfying the bandwidth 449 commitment. 451 The second candidate path is generally only requested from the PCE 452 and activated after a failure, but may also be requested and pre- 453 established during CS-SR policy creation with the downside of 454 bandwidth being set aside ahead of time. 456 As soon as failure(s) that brought the first candidate path down are 457 cleared, the second candidate path is getting deactivated (O field in 458 LSP object is set to 1) or torn down. The first candidate path is 459 activated (O field in LSP object is set to 2) and traffic sent across 460 it. 462 Restoration and reversion behavior is bidirectional. As described in 463 Section 7.1, both headends use connectivity verification in loopback 464 mode and therefore even in case of unidirectional failures both 465 headends will detect the failure or clearance of the failure and 466 switch traffic away from the failed or to the recovered candidate 467 path. 469 6.3.2. 1:1+R Restoration 471 For further resiliency in case of multiple concurrent failures that 472 could affect both candidate paths of 1:1 protection described in 473 Section 6.2, a third candidate path with a preference lower than the 474 other two candidate paths is added to the CS-SR policy. 476 The third candidate path enables restoration and will generally only 477 be established, activated (O field in LSP object is set to 2) and 478 carry traffic after failure(s) have impacted both the candidate path 479 with highest and second highest preference. 481 The third candidate path may also be requested and pre-computed 482 already whenever either the first or second candidate path went down 483 due to a failure with the downside of bandwidth being set aside ahead 484 of time. 486 As soon as failure(s) that brought either the first or second 487 candidate path down are cleared the third candidate path is getting 488 deactivated (O field in LSP object is set to 1), the candidate path 489 that recovered is activated (O field in LSP object is set to 2) and 490 traffic sent across it. 492 Again restoration and reversion behavior is bidirectional. As 493 described in Section 7.1, both headends use connectivity verification 494 in loopback mode and therefore even in case of unidirectional 495 failures both headends will detect the failure or clearance of the 496 failure and switch traffic away from the failed or to the recovered 497 candidate path. 499 7. Operations, Administration, and Maintenance (OAM) 501 7.1. Connectivity Verification 503 The proper operation of each segment list is validated by both 504 headends using STAMP in loopback measurement mode as described in 505 section 4.2.3 of [I-D.ietf-spring-stamp-srpm]. 507 As the STAMP test packets are including both the segment list of the 508 forward and reverse path, standard segment routing data plane 509 operations will make those packets get switched along the forward 510 path to the tailend and along the reverse path back to the headend. 512 The headend forms the bidirectional SR Policy association using the 513 procedure described in [I-D.ietf-pce-sr-bidir-path] and receives the 514 information about the reverse segment list from the PCE as described 515 in section 4.5 of [I-D.ietf-pce-multipath] 517 7.2. Performance Measurement 519 The same STAMP session is used to estimate round-trip loss as 520 described in section 5 of [I-D.ietf-spring-stamp-srpm]. 522 The same STAMP session used for connectivity verification can be used 523 to measure delay. As loopback mode is used only round-trip delay is 524 measured and one-way has to be derived by dividing the round-trip 525 delay by two. 527 7.3. Candidate Path Validity Verification 529 A stateful PCE is in sync with the network topology and the CS-SR 530 Policies provisioned on the headend routers. As described in 531 Section 4 a path must not be automatically recomputed after or 532 optimized for topology changes. However there may be a requirement 533 for a PCE to tear down a path if the path no longer satisfies the 534 original requirements, detected by PCE, such as insufficient 535 bandwidth, diversity constraint no longer met or latency constraint 536 exceeded. 538 The PCC may measure the actual bandwidth utilization of a CS-SR 539 policy and report it to the PCE in order for the PCE to take an 540 appropriate action if necessary. 542 For a CS-SR policy configured with multiple candidate paths, a PCC 543 may switch to another candidate path if the PCE decided to tear down 544 the active candidate path. 546 8. External Commands 548 8.1. Candidate Path Switchover 550 It is very common to allow operators to trigger a switch between 551 candidate paths even if no failure is present. I.e. to proactively 552 drain a resource for maintenance purposes. Operator triggered 553 switching between candidate paths is unidirectional and has to be 554 requested on both headends. 556 8.2. Candidate Path Recomputation 558 While no automatic re-optimization or pre-computation of CS-SR policy 559 candidate paths is allowed as specified in Section 4, network 560 operators trying to optimize network utilization may explicitly 561 request a candidate path to be re-computed at a certain point in 562 time. 564 9. Security Considerations 566 TO BE ADDED 568 10. IANA Considerations 570 This document has no IANA actions. 572 11. Acknowledgements 574 The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh 575 Gandhi and Tarek Saad for providing their review comments. 577 12. Contributors 579 Contributors' Addresses 581 Brent Foster 582 Cisco Systems, Inc. 583 Email: brfoster@cisco.com 585 Bertrand Duvivier 586 Cisco System, Inc. 587 Email: bduvivie@cisco.com 589 Stephane Litkowski 590 Cisco Systems, Inc. 591 Email: slitkows@cisco.com 593 Jie Dong 594 Huawei Technologies 595 Email: jie.dong@huawei.com 597 13. References 599 13.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 13.2. Informative References 608 [I-D.ietf-idr-bgpls-srv6-ext] 609 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 610 Bernier, D., and B. Decraene, "BGP Link State Extensions 611 for SRv6", Work in Progress, Internet-Draft, draft-ietf- 612 idr-bgpls-srv6-ext-09, 10 November 2021, 613 . 616 [I-D.ietf-lsr-isis-srv6-extensions] 617 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 618 Z. Hu, "IS-IS Extensions to Support Segment Routing over 619 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 620 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 621 . 624 [I-D.ietf-lsr-ospfv3-srv6-extensions] 625 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 626 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 627 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19 628 November 2021, . 631 [I-D.ietf-pce-local-protection-enforcement] 632 Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan, 633 "Local Protection Enforcement in PCEP", Work in Progress, 634 Internet-Draft, draft-ietf-pce-local-protection- 635 enforcement-05, 4 May 2022, 636 . 639 [I-D.ietf-pce-multipath] 640 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 641 Bidgoli, H., Yadav, B., Peng, S., and G. Mishra, "PCEP 642 Extensions for Signaling Multipath Information", Work in 643 Progress, Internet-Draft, draft-ietf-pce-multipath-05, 30 644 March 2022, . 647 [I-D.ietf-pce-segment-routing-ipv6] 648 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 649 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 650 Routing leveraging the IPv6 data plane", Work in Progress, 651 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-13, 1 652 April 2022, . 655 [I-D.ietf-pce-segment-routing-policy-cp] 656 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 657 Bidgoli, "PCEP extension to support Segment Routing Policy 658 Candidate Paths", Work in Progress, Internet-Draft, draft- 659 ietf-pce-segment-routing-policy-cp-07, 21 April 2022, 660 . 663 [I-D.ietf-pce-sr-bidir-path] 664 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 665 "Path Computation Element Communication Protocol (PCEP) 666 Extensions for Associated Bidirectional Segment Routing 667 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 668 pce-sr-bidir-path-09, 6 March 2022, 669 . 672 [I-D.ietf-spring-segment-routing-policy] 673 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 674 P. Mattes, "Segment Routing Policy Architecture", Work in 675 Progress, Internet-Draft, draft-ietf-spring-segment- 676 routing-policy-22, 22 March 2022, 677 . 680 [I-D.ietf-spring-stamp-srpm] 681 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 682 B., and R. Foote, "Performance Measurement Using Simple 683 TWAMP (STAMP) for Segment Routing Networks", Work in 684 Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, 685 1 February 2022, . 688 [I-D.sidor-pce-circuit-style-pcep-extensions] 689 Sidor, S., Ali, Z., and P. Maheshwari, "PCEP extensions 690 for Circuit Style Policies", Work in Progress, Internet- 691 Draft, draft-sidor-pce-circuit-style-pcep-extensions-00, 7 692 March 2022, . 695 [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 696 DOI 10.17487/RFC1925, April 1996, 697 . 699 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 700 "Assured Forwarding PHB Group", RFC 2597, 701 DOI 10.17487/RFC2597, June 1999, 702 . 704 [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le 705 Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. 706 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 707 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 708 . 710 [RFC3386] Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and 711 Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386, 712 November 2002, . 714 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 715 (Protection and Restoration) Terminology for Generalized 716 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 717 DOI 10.17487/RFC4427, March 2006, 718 . 720 [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 721 Ed., "RSVP-TE Extensions in Support of End-to-End 722 Generalized Multi-Protocol Label Switching (GMPLS) 723 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 724 . 726 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 727 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 728 DOI 10.17487/RFC5440, March 2009, 729 . 731 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 732 Computation Element Communication Protocol (PCEP) 733 Extensions for Stateful PCE", RFC 8231, 734 DOI 10.17487/RFC8231, September 2017, 735 . 737 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 738 Decraene, B., Litkowski, S., and R. Shakir, "Segment 739 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 740 July 2018, . 742 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 743 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 744 DOI 10.17487/RFC8476, December 2018, 745 . 747 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 748 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 749 DOI 10.17487/RFC8491, November 2018, 750 . 752 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 753 Decraene, B., Litkowski, S., and R. Shakir, "Segment 754 Routing with the MPLS Data Plane", RFC 8660, 755 DOI 10.17487/RFC8660, December 2019, 756 . 758 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 759 and J. Hardwick, "Path Computation Element Communication 760 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 761 DOI 10.17487/RFC8664, December 2019, 762 . 764 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 765 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 766 Extensions for Segment Routing", RFC 8665, 767 DOI 10.17487/RFC8665, December 2019, 768 . 770 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 771 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 772 Extensions for Segment Routing", RFC 8667, 773 DOI 10.17487/RFC8667, December 2019, 774 . 776 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 777 Dhody, D., and Y. Tanaka, "Path Computation Element 778 Communication Protocol (PCEP) Extensions for Establishing 779 Relationships between Sets of Label Switched Paths 780 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 781 . 783 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 784 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 785 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 786 . 788 [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 789 "Path Computation Element Communication Protocol (PCEP) 790 Extension for Label Switched Path (LSP) Diversity 791 Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, 792 July 2020, . 794 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 795 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 796 Using the Border Gateway Protocol - Link State", RFC 8814, 797 DOI 10.17487/RFC8814, August 2020, 798 . 800 [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation 801 Element Communication Protocol (PCEP) Extensions for 802 Associated Bidirectional Label Switched Paths (LSPs)", 803 RFC 9059, DOI 10.17487/RFC9059, June 2021, 804 . 806 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 807 H., and M. Chen, "Border Gateway Protocol - Link State 808 (BGP-LS) Extensions for Segment Routing", RFC 9085, 809 DOI 10.17487/RFC9085, August 2021, 810 . 812 Authors' Addresses 814 Christian Schmutzer (editor) 815 Cisco Systems, Inc. 816 Email: cschmutz@cisco.com 818 Clarence Filsfils 819 Cisco Systems, Inc. 820 Email: cfilsfil@cisco.com 822 Zafar Ali (editor) 823 Cisco Systems, Inc. 824 Email: zali@cisco.com 826 Francois Clad 827 Cisco Systems, Inc. 828 Email: fclad@cisco.com 830 Praveen Maheshwari 831 Airtel India 832 Email: Praveen.Maheshwari@airtel.com 834 Reza Rokui 835 Ciena 836 Email: rrokui@ciena.com 838 Andrew Stone 839 Nokia 840 Email: andrew.stone@nokia.com 842 Luay Jalil 843 Verizon 844 Email: luay.jalil@verizon.com 845 Shuping Peng 846 Huawei Technologies 847 Email: pengshuping@huawei.com 849 Tarek Saad 850 Juniper Networks 851 Email: tsaad@juniper.net 853 Daniel Voyer 854 Bell Canada 855 Email: daniel.voyer@bell.ca