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