idnits 2.17.1 draft-ietf-pce-sr-bidir-path-00.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2020) is 1533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-pce-association-bidir-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-12 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-01 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 10, 2020 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 February 7, 2020 13 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 14 draft-ietf-pce-sr-bidir-path-00 16 Abstract 18 The Path Computation Element Communication Protocol (PCEP) provides 19 mechanisms for Path Computation Elements (PCEs) to perform path 20 computations in response to Path Computation Clients (PCCs) requests. 21 The Stateful PCE extensions allow stateful control of Multiprotocol 22 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 23 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 24 in Segment Routing (SR) TE networks. 26 This document defines PCEP extensions for grouping two reverse 27 unidirectional SR Paths into an Associated Bidirectional SR Path when 28 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 29 well as when using a Stateless PCE. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 3. PCEP Extension for Bidirectional SR Path . . . . . . . . . . 4 69 3.1. Double-sided Bidirectional SR Path Association Group 70 Object . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Bidirectional Flag . . . . . . . . . . . . . . . . . . . . . 6 72 5. Procedures for Associated Bidirectional SR Path Computation . 6 73 5.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 7 74 5.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 7 75 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 76 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 77 6.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 10 78 6.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 11 81 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. Manageability Considerations . . . . . . . . . . . . . . . . 12 84 9.1. Control of Function and Policy . . . . . . . . . . . . . 12 85 9.2. Information and Data Models . . . . . . . . . . . . . . . 12 86 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 87 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 88 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 89 9.6. Impact On Network Operations . . . . . . . . . . . . . . 12 90 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 12.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 Segment routing (SR) [RFC8402] leverages the source routing and 100 tunneling paradigms. SR supports to steer packets into an explicit 101 forwarding path at the ingress node. 103 [RFC5440] describes the Path Computation Element (PCE) Communication 104 Protocol (PCEP). PCEP enables the communication between a Path 105 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 106 purpose of computation of Multiprotocol Label Switching (MPLS) as 107 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 108 Path (TE LSP) characteristics. 110 [RFC8231] specifies a set of extensions to PCEP to enable stateful 111 control of TE LSPs within and across PCEP sessions in compliance with 112 [RFC4657]. It includes mechanisms to effect LSP State 113 Synchronization between PCCs and PCEs, delegation of control over 114 LSPs to PCEs, and PCE control of timing and sequence of path 115 computations within and across PCEP sessions. The model of operation 116 where LSPs are initiated from the PCE is described in [RFC8281]. 118 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 119 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 120 allow a stateful PCE to compute and initiate SR-TE paths, as well as 121 a PCC to request, report or delegate SR Paths. 123 [I-D.ietf-pce-association-group] introduces a generic mechanism to 124 create a grouping of LSPs which can then be used to define 125 associations between a set of LSPs and/or a set of attributes, for 126 example primary and secondary LSP associations, and is equally 127 applicable to the active and passive modes of a Stateful PCE 128 [RFC8231] or a stateless PCE [RFC5440]. 130 Currently, SR networks only support unidirectional paths. However, 131 bidirectional SR Paths are required in some networks, for example, in 132 mobile backhaul transport networks. The requirement of bidirectional 133 SR Path is specified in [I-D.ietf-spring-mpls-path-segment]. 135 [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping 136 two reverse unidirectional MPLS TE LSPs into an Associated 137 Bidirectional LSP when using a Stateful PCE for both PCE-Initiated 138 and PCC-Initiated LSPs as well as when using a Stateless PCE. 140 This document extends the bidirectional association to segment 141 routing by specifying PCEP extensions for grouping two reverse 142 unidirectional SR Paths into a bidirectional SR Path. 144 [I-D.ietf-pce-association-bidir] specifies the Double-sided 145 Bidirectional LSP Association procedure, where the PCE creates the 146 association and provisions at both endpoints, the RSVP-TE does the 147 signaling to the egress the status of the forward LSP and the ingress 148 about the reverse LSP. Thus, the both endpoints learn the reverse 149 LSPs forming the bidirectional LSP association. In case of SR, to 150 support the bidirectional path use-case, this is done using the PCEP 151 protocol. This is done so that both endpoints are aware of the the 152 unidirectional SR Path, as well as the status and other SR path 153 related information. 155 [I-D.li-pce-sr-path-segment] defines a procedure for Path Segment 156 Identifier (PSID) in PCEP for SR using PATH-SEGMENT TLV. The PSID 157 can be a Path Segment Identifier in SR-MPLS 158 [I-D.ietf-spring-mpls-path-segment]. The PSID can be used for an 159 associated bidirectional SR Path for identifying the SR Path. 161 2. Terminology 163 This document makes use of the terms defined in 164 [I-D.ietf-pce-segment-routing]. The reader is assumed to be familiar 165 with the terminology defined in [RFC5440], [RFC8231], [RFC8281], 166 [I-D.ietf-pce-association-group] and 167 [I-D.ietf-pce-association-bidir]. 169 2.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 3. PCEP Extension for Bidirectional SR Path 179 As per [I-D.ietf-pce-association-group], LSPs are associated by 180 adding them to a common association group. 181 [I-D.ietf-pce-association-bidir] specifies PCEP extensions for 182 grouping two reverse unidirectional MPLS-TE LSPs into an Associated 183 Bidirectional LSP for both single-sided and double-sided initiation 184 cases by defining two new Bidirectional LSP Association Groups. 186 This document extends the procedure for associated bidirectional SR 187 Paths by defining a new bidirectional association group (Double-sided 188 Bidirectional SR Path Association Group). The document further 189 describes the mechanism for associating two unidirectional SR Paths 190 into a bidirectional SR Path. [I-D.li-pce-sr-path-segment] defines a 191 procedure for communicating Path Segment in PCEP for SR using PATH- 192 SEGMENT TLV. The bidirectional SR Path can also use the PATH-SEGMENT 193 TLV. 195 Note that an association group is defined in this document to define 196 procedures specific to SR Paths (and the procedures are different 197 than the RSVP-TE bidirectional association groups defined in 198 [I-D.ietf-pce-association-bidir]). 200 3.1. Double-sided Bidirectional SR Path Association Group Object 202 As defined in [I-D.ietf-pce-association-bidir], two LSPs are 203 associated as a bidirectional MPLS-TE LSP by a common bidirectional 204 LSP association group. For associating two SR paths, this document 205 defines a new association group called 'Double-sided Bidirectional SR 206 Path Association Group' as follows: 208 o Association Type (TBD1 to be assigned by IANA) = Double-sided 209 Bidirectional SR Path Association Group 211 Similar to other bidirectional associations, this Association Type is 212 operator-configured in nature and statically created by the operator 213 on the PCEP peers. The paths belonging to this association is 214 conveyed via PCEP messages to the PCEP peer. Operator-configured 215 Association Range TLV [I-D.ietf-pce-association-group] MUST NOT be 216 sent for these Association Types, and MUST be ignored, so that the 217 entire range of association ID can be used for them. The handling of 218 the Association ID, Association Source, optional Global Association 219 Source and optional Extended Association ID in this association are 220 set in the same way as [I-D.ietf-pce-association-bidir]. 222 A member of the 'Double-sided Bidirectional SR Path Association 223 Group' can take the role of a forward or reverse SR Path and follow 224 the similar rules defined in [I-D.ietf-pce-association-bidir] for 225 LSPs. 227 o An SR Path (forward or reverse) can not be part of more than one 228 'Double-sided Bidirectional SR Path Association Group'. 230 o The endpoints of the SR Paths in this associations cannot be 231 different. 233 For describing the SR Paths in this association group, such as 234 direction and co-routed information, this association group reuses 235 the Bidirectional LSP Association Group TLV defined in 236 [I-D.ietf-pce-association-bidir]. All fields and processing rules 237 are as per [I-D.ietf-pce-association-bidir]. 239 4. Bidirectional Flag 241 As defined in [RFC5440], the B-flag in RP object MUST be set when the 242 PCC specifies that the path computation request relates to a 243 bidirectional TE LSP. In this document, the B-flag also MUST be set 244 when the PCC specifies that the path computation request relates to a 245 bidirectional SR Path. When a stateful PCE initiates or updates a 246 bidirectional SR Paths including LSPs and SR paths, the B-flag in SRP 247 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] MAY be set as well. 249 5. Procedures for Associated Bidirectional SR Path Computation 251 Two unidirectional SR Paths can be associated by the association 252 group object as specified in [I-D.ietf-pce-association-group]. A 253 bidirectional LSP association group object is defined in 254 [I-D.ietf-pce-association-bidir] (for MPLS-TE). This document 255 extends these association mechanisms for bidirectional SR Paths. Two 256 SR Paths can be associated together by using the Bidirectional SR 257 Path Association Group defined in this document for PCEP messages. 258 The PATH-SEGMENT TLV [I-D.li-pce-sr-path-segment] SHOULD also be 259 included in the LSP object for these SR Paths to support required 260 use-cases. 262 For bidirectional SR Paths, there is a need to know the reverse 263 direction SR paths. The PCE SHOULD inform the reverse SR Paths to 264 the ingress PCCs and vice versa. To achieve this, a PCInitiate 265 message for the reverse SR Path is sent to the ingress PCC and a 266 PCInitiate message for the forward SR Path is sent to the egress PCC 267 (with the same association group). These PCInitiate message MUST NOT 268 trigger initiation of SR Paths. The reverse direction SR Path can be 269 used for several use-cases, such as directed BFD 270 [I-D.ietf-mpls-bfd-directed]. 272 For a bidirectional LSP computation when using both direction LSPs on 273 a node, the same LSP would need to be identified using 2 different 274 PLSP-IDs based on the PCEP session to the ingress or the egress. In 275 other words, the LSP will have a PLSP-ID A at the ingress node while 276 it will have the PLSP-ID B at the egress node. The PCE will maintain 277 the two PLSP-IDs for the same LSP. For instance, an ingress PCC 278 requests a bidirectional SR Path computation, and the PCE computes a 279 forward LSP1 with PLSP-ID say 100. The reverse LSP2 from the egress 280 to the ingress with PLSP-ID say 200 is allocated by the egress PCC. 281 Since the PLSP-ID space is independent at each PCC, the PLSP-ID 282 allocated by the egress PCC can not be used for the LSP at the 283 ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to 284 allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , 285 say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and 286 may have say PLSP-ID 201 at the egress node. 288 5.1. PCE Initiated Associated Bidirectional SR Paths 290 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 291 Path Association Group can be created by a Stateful PCE. 293 o Stateful PCE can create and update the forward and reverse SR 294 Paths independently for a 'Double-sided Bidirectional SR Path 295 Association Group'. 297 o Stateful PCE can establish and remove the association relationship 298 on a per SR Path basis. 300 o Stateful PCE can create and update the SR Path and the association 301 on a PCC via PCInitiate and PCUpd messages, respectively, using 302 the procedures described in [I-D.ietf-pce-association-group]. 304 o The PATH-SEGMENT TLV SHOULD be included for each SR Path in the 305 LSP object. 307 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 308 D) SHOULD be informed by PCE via PCInitiate message with the 309 matching association group. 311 +-----+ 312 | PCE | 313 +-----+ 314 PCInitiate/PCUpd: / \ PCInitiate/PCUpd: 315 Tunnel 1 (F) / \ Tunnel 2 (F) 316 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 317 Association #1 / \ Association #1 318 / \ 319 v v 320 +-----+ LSP1 +-----+ 321 | S |------------>| D | 322 | |<------------| | 323 +-----+ LSP2 +-----+ 324 326 Figure 1: PCE-Initiated Double-sided Bidirectional SR Path 327 with Forward and Reverse Direction SR Paths 329 5.2. PCC Initiated Associated Bidirectional SR Paths 331 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 332 Path Association Group can also be created by a PCC. 334 o PCC can create and update the forward and reverse SR Paths 335 independently for a 'Double-sided Bidirectional SR Path 336 Association Group'. 338 o PCC can establish and remove the association relationship on a per 339 SR Path basis. 341 o PCC MUST report the change in the association group of an SR Path 342 to PCE(s) via PCRpt message. 344 o PCC can report the forward and reverse SR Paths independently to 345 PCE(s) via PCRpt message. 347 o PCC can delegate the forward and reverse SR Paths independently to 348 a Stateful PCE, where PCE would control the SR Paths. 350 o Stateful PCE can update the SR Paths in the 'Double-sided 351 Bidirectional SR Path Association Group' via PCUpd message, using 352 the procedures described in [I-D.ietf-pce-association-group]. 354 o The PATH-SEGMENT TLV MUST be handled as defined in 355 [I-D.li-pce-sr-path-segment]. 357 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 358 D) SHOULD be informed by PCE via PCInitiate message with the 359 matching association group. 361 +-----+ 362 | PCE | 363 +-----+ 364 Report/Delegate: ^ ^ Report/Delegate: 365 Tunnel 1 (F) / \ Tunnel 2 (F) 366 (LSP1 (F)) / \ (LSP2 (F)) 367 Association #2 / \ Association #2 368 / \ 369 / \ 370 +-----+ LSP1 +-----+ 371 | S |------------>| D | 372 | |<------------| | 373 +-----+ LSP2 +-----+ 374 376 Figure 2a: Step 1: PCC-Initiated Double-sided Bidirectional SR Path 377 with Forward Direction SR Paths 379 +-----+ 380 | PCE | 381 +-----+ 382 PCUpd/PCInitiate: / \ PCUpd/PCInitiate: 383 Tunnel 1 (F) / \ Tunnel 2 (F) 384 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 385 Association #2 / \ Association #2 386 / \ 387 v v 388 +-----+ LSP1 +-----+ 389 | S |------------>| D | 390 | |<------------| | 391 +-----+ LSP2 +-----+ 392 394 Figure 2b: Step 2: PCE-Upd/Initiated Double-sided Bidirectional Path 395 Along with Reverse Direction SR Paths 397 5.3. Error Handling 399 The error handling as described in section 5.5 of 400 [I-D.ietf-pce-association-bidir] continue to apply. 402 The PCEP Path Setup Type (PST) MUST be set to 'TE Path is Setup using 403 Segment Routing' [I-D.ietf-pce-segment-routing] for the LSP belonging 404 to the 'Double-sided Bidirectional SR Path Association Group'. In 405 case a PCEP speaker receives a different PST value for this 406 association group, it MUST send a PCErr message with Error-Type = 29 407 (Early allocation by IANA) (Association Error) and Error-Value = TBD2 408 (Bidirectional LSP Association - Path Setup Type Mismatch). 410 6. Implementation Status 412 [Note to the RFC Editor - remove this section before publication, as 413 well as remove the reference to [RFC7942]. 415 This section records the status of known implementations of the 416 protocol defined by this specification at the time of posting of this 417 Internet-Draft, and is based on a proposal described in [RFC7942]. 418 The description of implementations in this section is intended to 419 assist the IETF in its decision processes in progressing drafts to 420 RFCs. Please note that the listing of any individual implementation 421 here does not imply endorsement by the IETF. Furthermore, no effort 422 has been spent to verify the information presented here that was 423 supplied by IETF contributors. This is not intended as, and must not 424 be construed to be, a catalog of available implementations or their 425 features. Readers are advised to note that other implementations may 426 exist. 428 According to [RFC7942], "this will allow reviewers and working groups 429 to assign due consideration to documents that have the benefit of 430 running code, which may serve as evidence of valuable experimentation 431 and feedback that have made the implemented protocols more mature. 432 It is up to the individual working groups to use this information as 433 they see fit". 435 6.1. Huawei's Commercial Delivery 437 The feature is developing based on Huawei VRP8. 439 o Organization: Huawei 441 o Implementation: Huawei's Commercial Delivery implementation based 442 on VRP8. 444 o Description: The implementation is under development. 446 o Maturity Level: Product 448 o Contact: tanren@huawei.com 450 6.2. ZTE's Commercial Delivery 452 o Organization: ZTE 453 o Implementation: ZTE's Commercial Delivery implementation based on 454 Rosng v8. 456 o Description: The implementation is under development. 458 o Maturity Level: Product 460 o Contact: zhan.shuangping@zte.com.cn 462 7. IANA Considerations 464 7.1. Association Type 466 This document defines a new Association Type for the Association 467 Object defined [I-D.ietf-pce-association-group]. IANA is requested 468 to make the assignment of a value for the sub-registry "ASSOCIATION 469 Type Field" (to be created in [I-D.ietf-pce-association-group]), as 470 follows: 472 Value Name Reference 473 ------------------------------------------------------------------- 474 TBD1 Double-sided Bidirectional This document 475 SR Path Association Group 477 7.2. PCEP Errors 479 This document defines new Error value for Error Type 29 (Association 480 Error). IANA is requested to allocate new Error value within the 481 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 482 Numbers registry, as follows: 484 Error Type Description Reference 485 ------------------------------------------------------------------- 486 29 Association Error 488 Error value: TBD2 This document 489 Bidirectional LSP Association - 490 Path Setup Type Mismatch 492 8. Security Considerations 494 The security considerations described in [RFC5440], [RFC8231], 495 [RFC8281], and [I-D.ietf-pce-segment-routing] apply to the extensions 496 defined in this document as well. 498 A new Association Type for the Association Object, 'Double-sided 499 Associated Bidirectional SR Path Association Group' is introduced in 500 this document. Additional security considerations related to LSP 501 associations due to a malicious PCEP speaker is described in 502 [I-D.ietf-pce-association-group] and apply to this Association Type. 503 Hence, securing the PCEP session using Transport Layer Security (TLS) 504 [RFC8253] is recommended. 506 9. Manageability Considerations 508 All manageability requirements and considerations listed in 509 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 510 defined in this document. In addition, requirements and 511 considerations listed in this section apply. 513 9.1. Control of Function and Policy 515 The mechanisms defined in this document do not imply any control or 516 policy requirements in addition to those already listed in [RFC5440], 517 [RFC8231], and [RFC8281]. 519 9.2. Information and Data Models 521 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 522 defined for Bidirectional SR Path associations. The PCEP YANG module 523 [I-D.ietf-pce-pcep-yang] defines data model for Bidirectional SR Path 524 associations. 526 9.3. Liveness Detection and Monitoring 528 Mechanisms defined in this document do not imply any new liveness 529 detection and monitoring requirements in addition to those already 530 listed in [RFC5440], [RFC8231], and [RFC8281]. 532 9.4. Verify Correct Operations 534 Mechanisms defined in this document do not imply any new operation 535 verification requirements in addition to those already listed in 536 [RFC5440], [RFC8231], and [I-D.ietf-pce-segment-routing] . 538 9.5. Requirements On Other Protocols 540 Mechanisms defined in this document do not imply any new requirements 541 on other protocols. 543 9.6. Impact On Network Operations 545 Mechanisms defined in [RFC5440], [RFC8231], and 546 [I-D.ietf-pce-segment-routing] also apply to PCEP extensions defined 547 in this document. 549 10. Contributors 551 The following people have substantially contributed to this document: 553 Dhruv Dhody 554 Huawei Technologies 555 Divyashree Techno Park, Whitefield 556 Bangalore, Karnataka 560066 557 India 559 Email: dhruv.ietf@gmail.com 561 Zhenbin Li 562 Huawei Technologies 563 Huawei Campus, No. 156 Beiqing Rd. 564 Beijing 100095 565 China 567 Email: lizhenbin@huawei.com 569 Jie Dong 570 Huawei Technologies 571 Huawei Campus, No. 156 Beiqing Rd. 572 Beijing 100095 573 China 575 Email: jie.dong@huawei.com 577 11. Acknowledgments 579 Many thanks to Marina Fizgeer for detailed review and comments. 581 12. References 583 12.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 591 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 592 DOI 10.17487/RFC5440, March 2009, 593 . 595 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 596 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 597 May 2017, . 599 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 600 Computation Element Communication Protocol (PCEP) 601 Extensions for Stateful PCE", RFC 8231, 602 DOI 10.17487/RFC8231, September 2017, 603 . 605 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 606 Computation Element Communication Protocol (PCEP) 607 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 608 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 609 . 611 [I-D.ietf-pce-association-group] 612 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 613 Dhody, D., and Y. Tanaka, "Path Computation Element 614 Communication Protocol (PCEP) Extensions for Establishing 615 Relationships Between Sets of Label Switched Paths 616 (LSPs)", draft-ietf-pce-association-group-10 (work in 617 progress), August 2019. 619 [I-D.ietf-pce-association-bidir] 620 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 621 Associated Bidirectional Label Switched Paths (LSPs)", 622 draft-ietf-pce-association-bidir-05 (work in progress), 623 February 2020. 625 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 626 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 627 Ali, "Path Computation Element (PCE) Protocol Extensions 628 for Stateful PCE Usage in GMPLS-controlled Networks", 629 draft-ietf-pce-pcep-stateful-pce-gmpls-12 (work in 630 progress), October 2019. 632 [I-D.li-pce-sr-path-segment] 633 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 634 and Q. Xiong, "Path Computation Element Communication 635 Protocol (PCEP) Extension for Path Segment in Segment 636 Routing (SR)", draft-li-pce-sr-path-segment-08 (work in 637 progress), August 2019. 639 12.2. Informative References 641 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 642 Element (PCE) Communication Protocol Generic 643 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 644 2006, . 646 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 647 "PCEPS: Usage of TLS to Provide a Secure Transport for the 648 Path Computation Element Communication Protocol (PCEP)", 649 RFC 8253, DOI 10.17487/RFC8253, October 2017, 650 . 652 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 653 Decraene, B., Litkowski, S., and R. Shakir, "Segment 654 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 655 July 2018, . 657 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 658 Code: The Implementation Status Section", BCP 205, 659 RFC 7942, DOI 10.17487/RFC7942, July 2016, 660 . 662 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 663 Hardwick, "Path Computation Element Communication Protocol 664 (PCEP) Management Information Base (MIB) Module", 665 RFC 7420, DOI 10.17487/RFC7420, December 2014, 666 . 668 [I-D.ietf-pce-segment-routing] 669 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 670 and J. Hardwick, "PCEP Extensions for Segment Routing", 671 draft-ietf-pce-segment-routing-16 (work in progress), 672 March 2019. 674 [I-D.ietf-mpls-bfd-directed] 675 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 676 "Bidirectional Forwarding Detection (BFD) Directed Return 677 Path", draft-ietf-mpls-bfd-directed-13 (work in progress), 678 December 2019. 680 [I-D.ietf-spring-mpls-path-segment] 681 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 682 "Path Segment in MPLS Based Segment Routing Network", 683 draft-ietf-spring-mpls-path-segment-01 (work in progress), 684 September 2019. 686 [I-D.ietf-pce-pcep-yang] 687 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 688 YANG Data Model for Path Computation Element 689 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 690 yang-13 (work in progress), October 2019. 692 Authors' Addresses 694 Cheng Li 695 Huawei Technologies 696 Huawei Campus, No. 156 Beiqing Rd. 697 Beijing 100095 698 China 700 Email: chengli13@huawei.com 702 Mach(Guoyi) Chen 703 Huawei Technologies 704 Huawei Campus, No. 156 Beiqing Rd. 705 Beijing 100095 706 China 708 Email: Mach.chen@huawei.com 710 Weiqiang Cheng 711 China Mobile 712 China 714 Email: chengweiqiang@chinamobile.com 716 Rakesh Gandhi 717 Cisco Systems, Inc. 718 Canada 720 Email: rgandhi@cisco.com 722 Quan Xiong 723 ZTE Corporation 724 China 726 Email: xiong.quan@zte.com.cn