idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-12.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 11, 2021) is 1162 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-06 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-05 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 15, 2021 M. Negi 6 RtBrick Inc 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 February 11, 2021 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of LSPs 15 draft-ietf-pce-pcep-extension-for-pce-controller-12 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled MPLS and GMPLS traffic-engineered 28 (TE) networks, and the PCE may be used to determine paths in a range 29 of use cases. PCEP has been proposed as a control protocol for use 30 in these environments to allow the PCE to be fully enabled as a 31 central controller. 33 A PCE-based Central Controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/set up/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network device 38 along the path, while leveraging the existing PCE technologies as 39 much as possible. 41 This document specifies the procedures and PCEP extensions for using 42 the PCE as the central controller for provisioning labels along the 43 path of the static LSP. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on August 15, 2021. 62 Copyright Notice 64 Copyright (c) 2021 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 83 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 84 5. Procedures for Using the PCE as a Central Controller (PCECC) 6 85 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 86 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 7 87 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 88 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 8 89 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 90 5.5.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 9 91 5.5.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 13 92 5.5.3. Central Controller Instructions . . . . . . . . . . . 15 93 5.5.3.1. Label Download CCI . . . . . . . . . . . . . . . 16 94 5.5.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 16 95 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 17 96 5.5.5. Re-Delegation and Clean up . . . . . . . . . . . . . 20 97 5.5.6. Synchronization of Central Controllers Instructions . 20 98 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 21 99 5.5.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 21 100 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21 101 6.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 22 102 6.2. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 103 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 24 104 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24 105 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 25 106 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 25 107 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 26 108 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 27 109 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 110 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 29 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 112 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 30 113 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 30 114 10. Manageability Considerations . . . . . . . . . . . . . . . . 30 115 10.1. Control of Function and Policy . . . . . . . . . . . . . 31 116 10.2. Information and Data Models . . . . . . . . . . . . . . 31 117 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 31 118 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 31 119 10.5. Requirements On Other Protocols . . . . . . . . . . . . 32 120 10.6. Impact On Network Operations . . . . . . . . . . . . . . 32 121 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 122 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 32 123 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 32 124 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 32 125 11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 33 126 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 33 127 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 33 128 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 34 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 132 13.2. Informative References . . . . . . . . . . . . . . . . . 36 133 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 39 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 136 1. Introduction 138 The Path Computation Element (PCE) [RFC4655] was developed to offload 139 the path computation function from routers in an MPLS traffic- 140 engineered network. Since then, the role and function of the PCE has 141 grown to cover a number of other uses (such as GMPLS [RFC7025]) and 142 to allow delegated control [RFC8231] and PCE-initiated use of network 143 resources [RFC8281]. 145 According to [RFC7399], Software-Defined Networking (SDN) refers to a 146 separation between the control elements and the forwarding components 147 so that software running in a centralized system, called a 148 controller, can act to program the devices in the network to behave 149 in specific ways. A required element in an SDN architecture is a 150 component that plans how the network resources will be used and how 151 the devices will be programmed. It is possible to view this 152 component as performing specific computations to place traffic flows 153 within the network given knowledge of the availability of network 154 resources, how other forwarding devices are programmed, and the way 155 that other flows are routed. This is the function and purpose of a 156 PCE, and the way that a PCE integrates into a wider network control 157 system (including an SDN system) is presented in [RFC7491]. 159 In early PCE implementations, where the PCE was used to derive paths 160 for MPLS Label Switched Paths (LSPs), paths were requested by network 161 elements (known as Path Computation Clients (PCCs)), and the results 162 of the path computations were supplied to network elements using the 163 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 164 This protocol was later extended to allow a PCE to send unsolicited 165 requests to the network for LSP establishment [RFC8281]. 167 [RFC8283] introduces the architecture for PCE as a central controller 168 as an extension of the architecture described in [RFC4655] and 169 assumes the continued use of PCEP as the protocol used between PCE 170 and PCC. [RFC8283] further examines the motivations and 171 applicability for PCEP as a Southbound Interface (SBI), and 172 introduces the implications for the protocol. 173 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 174 architecture. 176 A PCE-based Central Controller (PCECC) can simplify the processing of 177 a distributed control plane by blending it with elements of SDN and 178 without necessarily completely replacing it. Thus, the LSP can be 179 calculated/setup/initiated and the label forwarding entries can also 180 be downloaded through a centralized PCE server to each network 181 devices along the path while leveraging the existing PCE technologies 182 as much as possible. 184 This document specifies the procedures and PCEP extensions for using 185 the PCE as the central controller for static LSPs, where LSPs can be 186 provisioned as explicit label instructions at each hop on the end-to- 187 end path. Each router along the path must be told what label- 188 forwarding instructions to program and what resources to reserve. 190 The PCE-based controller keeps a view of the network and determines 191 the paths of the end-to-end LSPs, and the controller uses PCEP to 192 communicate with each router along the path of the end-to-end LSP. 194 While this document is focused on the procedures for the static LSPs 195 (referred to as basic PCECC mode in Section 3), the mechanisms and 196 protocol encodings are specified in such a way that extensions for 197 other use cases are easy to achieve. For example, the extensions for 198 PCECC for Segment Routing (SR) are specified in 199 [I-D.zhao-pce-pcep-extension-pce-controller-sr] and 200 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 202 1.1. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 2. Terminology 212 The terminology used in this document is the same as that described 213 in the draft [RFC8283]. 215 3. Basic PCECC Mode 217 In this mode, LSPs are provisioned as explicit label instructions at 218 each hop on the end-to-end path. Each router along the path must be 219 told what label forwarding instructions to program and what resources 220 to reserve. The controller uses PCEP to communicate with each router 221 along the path of the end-to-end LSP. 223 [RFC8283] examines the motivations and applicability for PCECC and 224 use of PCEP as an SBI. Section 3.1.2. of [RFC8283] highlights the 225 use of PCECC for label allocation along the static LSPs and it 226 simplifies the processing of a distributed control plane by blending 227 it with elements of SDN and without necessarily completely replacing 228 it. This allows the operator to introduce the advantages of SDN 229 (such as programmability) into the network. Further Section 3.3. of 230 [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where 231 the PCECC technique could be useful. Section 4 of [RFC8283] also 232 describe the implications on the protocol when used as an SDN SBI. 233 The operator needs to evaluate the advantages offered by PCECC 234 against the operational and scalability needs of the PCECC. 236 As per Section 3.1.2. of [RFC8283], the PCE-based controller will 237 take responsibility for managing some part of the MPLS label space 238 for each of the routers that it controls, and may take wider 239 responsibility for partitioning the label space for each router and 240 allocating different parts for different uses. The PCC MUST NOT make 241 allocations from the label space set aside for the PCE to avoid 242 overlap and collisions of label allocations. It is RECOMMENDED that 243 PCE makes allocations (from the label space set aside for the PCE) 244 for all nodes along the path. For the purpose of this document, it 245 is assumed that the exclusive label range to be used by a PCE is 246 known and set on both PCEP peers. A future extension could add the 247 capability to advertise this range via a possible PCEP extension as 248 well (see [I-D.li-pce-controlled-id-space]). The rest of the 249 processing is similar to the existing stateful PCE mechanism. 251 This document also allows a case where the label space is maintained 252 by the PCC itself, and the labels are allocated by the PCC, in this 253 case, the PCE should request the allocation from PCC as described in 254 Section 5.5.8. 256 4. PCEP Requirements 258 The following key requirements should be considered when designing 259 the PCECC-based solution: 261 1. A PCEP speaker supporting this draft needs to have the capability 262 to advertise its PCECC capability to its peers. 264 2. A PCEP speaker need means to identify PCECC-based LSP in the PCEP 265 messages. 267 3. PCEP procedures need to allow for PCC-based label allocations. 269 4. PCEP procedures need to provide a mean to update (or clean up) 270 the label-download entry to the PCC. 272 5. PCEP procedures need to provide a mean to synchronize the labels 273 between the PCE and the PCC via PCEP messages. 275 5. Procedures for Using the PCE as a Central Controller (PCECC) 277 5.1. Stateful PCE Model 279 Active stateful PCE is described in [RFC8231]. PCE as a central 280 controller (PCECC) reuses the existing active stateful PCE mechanism 281 as much as possible to control LSPs. 283 5.2. New LSP Functions 285 Several new functions are required in PCEP to support PCECC. This 286 document extends the existing messages to support the new functions 287 required by PCECC: 289 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 290 message is used to set up PCE-Initiated LSP based on PCECC 291 mechanism. It is also extended for Central Controller 292 Instructions (CCI) (download or clean up the Label forwarding 293 instructions in the context of this document) on all nodes along 294 the path. 296 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 297 used to send PCECC LSP Reports. It is also extended to report the 298 set of Central Controller Instructions (CCI) (label forwarding 299 instructions in the context of this document) received from the 300 PCE. See Section 5.5.6 for more details. 302 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 303 used to send PCECC LSP Update. 305 The new functions defined in this document are mapped onto the PCEP 306 messages as shown in Table 1. 308 Function Message 309 PCECC Capability advertisement Open 310 Label entry Add PCInitiate 311 Label entry Clean up PCInitiate 312 PCECC Initiated LSP PCInitiate 313 PCECC LSP Update PCUpd 314 PCECC LSP State Report PCRpt 315 PCECC LSP Delegation PCRpt 316 PCECC Label Report PCRpt 318 Table 1: Functions mapped to the PCEP messages 320 5.3. New PCEP Object 322 This document defines a new PCEP object called CCI (Section 7.3) to 323 specify the central controller instructions. In the scope of this 324 document, this is limited to Label forwarding instructions. Future 325 documents can create new CCI object-types for other types of central 326 controller instructions. The CC-ID is the unique identifier for the 327 central controller instructions in PCEP. The PCEP messages are 328 extended in this document to handle the PCECC operations. 330 5.4. PCECC Capability Advertisement 332 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 333 advertise their support of and willingness to use PCEP extensions for 334 PCECC using these elements in the OPEN message: 336 o A new Path Setup Type (PST) in the PATH-SETUP-TYPE-CAPABILITY TLV 337 to indicate support for PCEP extensions for PCECC - TBD1 (Path is 338 set up via PCECC mode) 340 o A new PCECC-CAPABILITY sub-TLV with the L bit set to 1 inside the 341 PATH-SETUP-TYPE-CAPABILITY TLV to indicate a willingness to use 342 PCEP extensions for PCECC based central controller instructions 343 for label download 345 o The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with the I flag set 346 [RFC8281]) 348 The new Path Setup Type is to be listed in the PATH-SETUP-TYPE- 349 CAPABILITY TLV by all PCEP speakers which support the PCEP extensions 350 for PCECC in this document. 352 The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE- 353 CAPABILITY TLV in the OPEN object to indicate a willingness to use 354 the PCEP extensions for PCECC during the established PCEP session. 355 Using the L bit in this TLV, the PCE shows the intention to function 356 as a PCECC server, and the PCC shows a willingness to act as a PCECC 357 client for label download instructions (see Section 7.1.1). 359 If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE- 360 CAPABILITY TLV is not advertised, or is advertised without the I flag 361 set, in the OPEN Object, the receiver MUST: 363 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 364 Error-value=TBD4 (stateful PCE capability was not advertised) 366 o Terminate the session 368 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 369 the PCECC Path Setup Type but without the PCECC-CAPABILITY sub-TLV, 370 it MUST: 372 o Send a PCErr message with Error-Type 10 (Reception of an invalid 373 object) and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV) 375 o Terminate the PCEP session 376 The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the 377 corresponding Path Setup Type being listed in the PATH-SETUP-TYPE- 378 CAPABILITY TLV. If it is present without the corresponding Path 379 Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be 380 ignored. 382 If one or both speakers (PCE and PCC) have not indicated support and 383 willingness to use the PCEP extensions for PCECC, the PCEP extensions 384 for PCECC MUST NOT be used. If a PCECC operation is attempted when 385 both speakers have not agreed in the OPEN messages, the receiver of 386 the message MUST: 388 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 389 Error-Value=TBD3 (Attempted PCECC operations when PCECC capability 390 was not advertised) 392 o Terminate the PCEP session 394 A legacy PCEP speaker (that does not recognize the PCECC Capability 395 sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and 396 [RFC5440]. As per [RFC8408], the legacy PCEP speaker (that does not 397 support PST), it will: 399 o Send a PCErr message with Error-Type = 21 (Invalid traffic 400 engineering path setup type) and Error-value = 1 (Unsupported path 401 setup type) 403 o Terminate the PCEP session 405 5.5. LSP Operations 407 The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE 408 TLV [RFC8408] in the SRP (Stateful PCE Request Parameters) object 409 [RFC8231] with PST set to TBD1 to clearly identify that PCECC LSP is 410 intended. 412 5.5.1. PCE-Initiated PCECC LSP 414 The LSP Instantiation operation is defined in [RFC8281]. In order to 415 set up a PCE-Initiated LSP based on the PCECC mechanism, a PCE sends 416 PCInitiate message with PST set to TBD1 for PCECC (see Section 7.2) 417 to the ingress PCC. 419 The label forwarding instructions (see Section 5.5.3) from PCECC are 420 sent after the initial PCInitiate and PCRpt message exchange with the 421 ingress PCC as per [RFC8281] (see Figure 1). This is done so that 422 the PLSP-ID and other LSP identifiers can be obtained from the 423 ingress and can be included in the label forwarding instruction in 424 the next set of PCInitiate messages along the path as described 425 below. 427 An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple 428 uniquely identifies the LSP in the network. The LSP object is 429 included in the central controller instructions (label download 430 Section 7.3) to identify the PCECC LSP for this instruction. The 431 PLSP-ID is the original identifier used by the ingress PCC, so a 432 transit/egress LSR could have multiple central controller 433 instructions that have the same PLSP-ID. The PLSP-ID in combination 434 with the source (in LSP-IDENTIFIER TLV) MUST be unique. The PLSP-ID 435 is included for maintainability reasons to ease debugging. As per 436 [RFC8281], the LSP object could also include the SPEAKER-ENTITY-ID 437 TLV to identify the PCE that initiated these instructions. Also, the 438 CC-ID is unique in each PCEP session as described in Section 7.3. 440 The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 441 (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message 442 to the PCE in the initial exchange. The PCC responds with a PCRpt 443 message with the status set to "GOING-UP" and carrying the assigned 444 PLSP-ID (see Figure 1). When the PCE receives this PCRpt message 445 with the PLSP-ID, it assigns labels along the path; and sets up the 446 path by sending a PCInitiate message to each node along the path of 447 the LSP as per the PCECC technique. The CC-ID uniquely identifies 448 the central controller instruction within a PCEP session. Each PCC 449 further responds with the PCRpt messages including the central 450 controller instruction (CCI) and the LSP objects. The PCC responds 451 with a PCRpt message to acknowledge the central controller 452 instruction. 454 The ingress node would receive one CCI object with O bit (out-label) 455 set. The transit node(s) would receive two CCI objects with the in- 456 label CCI without an O bit set and the out-label CCI with O bit set. 457 The egress node would receive one CCI object without O bit set (see 458 Figure 1). A node can determine its role based on the setting of the 459 O bit in the CCI object(s) and the LSP-IDENTIFIER TLV in the LSP 460 object. 462 The LSP deletion operation for PCE-Initiated PCECC LSP is the same as 463 defined in [RFC8281]. The PCE should further perform Label entry 464 clean up operation as described in Section 5.5.3.2 for the 465 corresponding LSP. 467 The PCE-Initiated PCECC LSP setup sequence is shown in Figure 1. 469 +-------+ +-------+ 470 |PCC | | PCE | 471 |ingress| +-------+ 472 +------| | | 473 | PCC +-------+ | 474 | transit| | | 475 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 476 |PCC +--------+ | | Initiate 477 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 478 +--------+ | | (GOING-UP) | 479 | | | | 480 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 481 | | | | download 482 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 483 | | | | 484 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 485 | | | | download 486 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 487 | | | | 488 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 489 | | | | download 490 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 491 | | | | 492 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 493 | | | (UP) | Update 494 | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| 495 | | | (UP) | 497 Figure 1: PCE-Initiated PCECC LSP 499 Once the label operations are completed, the PCE SHOULD send a PCUpd 500 message to the ingress PCC. The PCUpd message is as per [RFC8231]. 502 The PCECC LSPs are considered to be 'up' by default (on receipt of 503 PCUpd message from PCE). The ingress MAY further choose to deploy a 504 data plane check mechanism and report the status back to the PCE via 505 a PCRpt message to make sure that the correct label instructions are 506 made along the path of the PCECC LSP (and it is ready to carry 507 traffic). 509 In the case where the label allocations are made by the PCC itself 510 (see Section 5.5.8), the PCE could request an allocation to be made 511 by the PCC, and then the PCC would send a PCRpt with the allocated 512 label encoded in the CC-ID object as shown in Figure 2 in the 513 configuration sequence from the egress towards the ingress along the 514 path. 516 +-------+ +-------+ 517 |PCC | | PCE | 518 |ingress| +-------+ 519 +------| | | 520 | PCC +-------+ | 521 | transit| | | 522 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 523 |PCC +--------+ | | Initiate 524 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 525 +--------+ | | (GOING-UP) | 526 | | | | 527 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 528 | | | C=1 | download 529 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 530 | | | Label=L1 | 531 | |<------PCInitiate,PLSP-ID=2,----------------| Labels 532 | | | CC-ID=Y1,C=1 | download 533 | | | CC-ID=Y2,C=0,L1 | CCI 534 | |-------PCRpt,PLSP-ID=2--------------------->| 535 | | | CC-ID=Y1,Label=L2 | 536 | | | CC-ID=Y2 | 537 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 538 | | | C=0,L2 | download 539 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 540 | | | | 541 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 542 | | | (UP) | Update 544 - The O bit is set as before (and thus not included) 546 Figure 2: PCE-Initiated PCECC LSP (PCC allocation) 548 It should be noted that in this example, the request is made to the 549 egress node with the C bit set in the CCI object to indicate that the 550 label allocation needs to be done by the egress and the egress 551 responds with the allocated label to the PCE. The PCE further inform 552 the transit PCC without setting the C bit to 1 in the CCI object for 553 out-label but the C bit is set to 1 for in-label so the transit node 554 make the label allocation (for the in-label) and report to the PCE. 555 Similarly, the C bit is unset towards the ingress to complete all the 556 label allocation for the PCECC LSP. 558 5.5.2. PCC-Initiated PCECC LSP 560 In order to set up an LSP based on the PCECC mechanism where the LSP 561 is configured at the PCC, a PCC MUST delegate the LSP by sending a 562 PCRpt message with PST set for PCECC (see Section 7.2) and D 563 (Delegate) flag (see [RFC8231]) set in the LSP object (see Figure 3). 565 When a PCE receives the initial PCRpt message with D flag and PST 566 Type set to TBD1, it SHOULD calculate the path and assigns labels 567 along the path; and sets up the path by sending a PCInitiate message 568 to each node along the path of the LSP as per the PCECC technique 569 (see Figure 3). The CC-ID uniquely identifies the central controller 570 instruction within a PCEP session. Each PCC further responds with 571 the PCRpt messages including the central controller instruction (CCI) 572 and the LSP objects. 574 Once the central controller instructions (label operations) are 575 completed, the PCE MUST send the PCUpd message to the ingress PCC. 576 As per [RFC8231], this PCUpd message should include the path 577 information calculated by the PCE. 579 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 581 The LSP deletion operation for PCECC LSPs is the same as defined in 582 [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then 583 it does label clean up operation as described in Section 5.5.3.2 for 584 the corresponding LSP. 586 The Basic PCECC LSP setup sequence is as shown in Figure 3. 588 +-------+ +-------+ 589 |PCC | | PCE | 590 |ingress| +-------+ 591 +------| | | 592 | PCC +-------+ | 593 | transit| | | 594 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 595 |PCC +--------+ | | 596 |egress | | | | 597 +--------+ | | | 598 | | | | 599 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 600 | | | L1,O=0 | download 601 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 602 | | | | 603 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 604 | | | CC-ID=Y1,O=0,L2 | download 605 | | | CC-ID=Y2,O=1,L1 | CCI 606 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| 607 | | | | 608 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 609 | | | L2,O=1 | download 610 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 611 | | | | 612 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 613 | | | | Update 614 | | | | 616 Figure 3: PCC-Initiated PCECC LSP 618 In the case where the label allocations are made by the PCC itself 619 (see Section 5.5.8), the PCE could request an allocation to be made 620 by the PCC, and then the PCC would send a PCRpt with the allocated 621 label encoded in the CC-ID object as shown in Figure 4. 623 +-------+ +-------+ 624 |PCC | | PCE | 625 |ingress| +-------+ 626 +------| | | 627 | PCC +-------+ | 628 | transit| | | 629 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 630 |PCC +--------+ | | 631 |egress | | | | 632 +--------+ | | | 633 | | | | 634 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 635 | | | C=1 | download 636 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 637 | | | Label=L1 | 638 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 639 | | | CC-ID=Y1,C=1 | download 640 | | | CC-ID=Y2,C=0,L1 | CCI 641 | |-------PCRpt,PLSP-ID=1-------------------->| 642 | | | CC-ID=Y1,Label=L2 | 643 | | | CC-ID=Y2 | 644 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 645 | | | C=0,L2 | download 646 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 647 | | | | 648 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 649 | | | | Update 650 | | | | 652 - The O bit is set as before (and thus not included) 654 Figure 4: PCC-Initiated PCECC LSP (PCC allocation) 656 In the case where the label allocations are made by the PCC itself 657 (see Section 5.5.8), the procedure remains the same, with just an 658 additional constraint on the configuration sequence. 660 The rest of the PCC-Initiated PCECC LSP setup operations are the same 661 as those described in Section 5.5.1. 663 5.5.3. Central Controller Instructions 665 The new central controller instructions (CCI) for the label 666 operations in PCEP is done via the PCInitiate message, by defining a 667 new PCEP Object for CCI operations. The local label range of each 668 PCC is assumed to be known by both the PCC and the PCE. 670 5.5.3.1. Label Download CCI 672 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 673 message to each node along the path to download the Label instruction 674 as described in Section 5.5.1 and Section 5.5.2. 676 The CCI object MUST be included, along with the LSP object in the 677 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the 678 LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP 679 object. 681 If a node (PCC) receives a PCInitiate message which includes a Label 682 to download, as part of CCI, that is out of the range set aside for 683 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 684 failure) and Error-value=TBD6 (Label out of range) and MUST include 685 the SRP object to specify the error is for the corresponding label 686 update via PCInitiate message. If a PCC receives a PCInitiate 687 message but fails to download the Label entry, it MUST send a PCErr 688 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 689 (instruction failed) and MUST include the SRP object to specify the 690 error is for the corresponding label update via PCInitiate message. 692 A new PCEP object for central controller instructions (CCI) is 693 defined in Section 7.3. 695 5.5.3.2. Label Clean up CCI 697 In order to delete an LSP based on PCECC, the PCE sends a central 698 controller instructions via a PCInitiate message to each node along 699 the path of the LSP to clean up the Label forwarding instruction. 701 If the PCC receives a PCInitiate message but does not recognize the 702 label in the CCI, the PCC MUST generate a PCErr message with Error- 703 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 704 MUST include the SRP object to specify the error is for the 705 corresponding label clean up (via PCInitiate message). 707 The R flag in the SRP object defined in [RFC8281] specifies the 708 deletion of Label Entry in the PCInitiate message. 710 +-------+ +-------+ 711 |PCC | | PCE | 712 |ingress| +-------+ 713 +------| | | 714 | PCC +-------+ | 715 | transit| | | 716 +------| | | | 717 |PCC +--------+ | | 718 |egress | | | | 719 +--------+ | | | 720 | | | | 721 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 722 | | | R=1 | clean up 723 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 724 | | | | 725 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 726 | | | R=1 | clean up 727 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 728 | | | | 729 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 730 | | | R=1 | clean up 731 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 732 | | | | 733 | | |<--PCInitiate,PLSP-ID=2,PST=TBD1,R=1--| PCECC LSP 734 | | | | remove 736 Figure 5: Label Cleanup 738 As per [RFC8281], following the removal of the Label forwarding 739 instruction, the PCC MUST send a PCRpt message. The SRP object in 740 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 741 that triggered the removal. The R flag in the SRP object MUST be 742 set. 744 In the case where the label allocation is made by the PCC itself (see 745 Section 5.5.8), the removal procedure remains the same, adding the 746 sequence constraint. 748 5.5.4. PCECC LSP Update 750 The update is done as per the make-before-break procedures, i.e. the 751 PCECC first updates new label instructions based on the updated path 752 and then notify it to the ingress to switch traffic, before cleaning 753 up the former instructions. New CC-IDs are used to identify the 754 updated instructions, the identifiers in the LSP object identify the 755 existing LSP. Once new instructions are downloaded, the PCE further 756 updates the new path at the ingress which triggers the traffic switch 757 on the updated path. The ingress PCC acknowledges with a PCRpt 758 message, on receipt of the PCRpt message, the PCE does clean up 759 operation for the former LSP as described in Section 5.5.3.2. 761 The PCECC LSP Update sequence is shown in Figure 6. 763 +-------+ +-------+ 764 |PCC | | PCE | 765 |ingress| +-------+ 766 +------| | | 767 | PCC +-------+ | 768 | transit| | | 769 +------| | | | 770 |PCC +--------+ | | 771 |egress | | | | 772 +--------+ | | | 773 | | | | New Path 774 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 -------------| for LSP 775 | | | | trigger 776 |--------PCRpt,CC-ID=XX,PLSP-ID=1------------------>| new CCI 777 | | | | 778 | |<------PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 779 | | | | download 780 | |-------PCRpt,CC-ID=YY1,YY2,PLSP-ID=1------>| CCI 781 | | | | 782 | | |<----PCInitiate,CC-ID=ZZ,PLSP-ID=1---| Label 783 | | | | download 784 | | |-----PCRpt,CC-ID=ZZ,PLSP-ID=1------->| CCI 785 | | | | 786 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC 787 | | | SRP=S | LSP Update 788 | | | | 789 | | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| Trigger 790 | | | (SRP=S) | Delete 791 | | | | former CCI 792 | | | | 793 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 794 | | | R=1 | clean up 795 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 796 | | | | 797 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1----| Label 798 | | | R=1 | clean up 799 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| CCI 800 | | | | 801 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 802 | | | R=1 | clean up 803 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 804 | | | | 806 Figure 6: PCECC LSP Update 808 The modified PCECC LSPs are considered to be 'up' by default. The 809 ingress MAY further choose to deploy a data plane check mechanism and 810 report the status back to the PCE via a PCRpt message. 812 In the case where the label allocations are made by the PCC itself 813 (see Section 5.5.8), the procedure remains the same. 815 5.5.5. Re-Delegation and Clean up 817 As described in [RFC8281], a new PCE can gain control over an 818 orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain 819 control over the central controller instructions in the same way by 820 sending a PCInitiate message that includes the SRP, LSP, and CCI 821 objects and carries the CC-ID and PLSP-ID identifying the instruction 822 that it wants to take control of. 824 Further, as described in [RFC8281], the State Timeout Interval timer 825 ensures that a PCE crash does not result in automatic and immediate 826 disruption for the services using PCE-initiated LSPs. Similarly the 827 central controller instructions are not removed immediately upon PCE 828 failure. Instead, they are cleaned up on the expiration of this 829 timer. This allows for network clean up without manual intervention. 830 The PCC MUST support the removal of CCI as one of the behaviors 831 applied on expiration of the State Timeout Interval timer. 833 In case of PCC-initiated PCECC LSP, the control over the orphaned LSP 834 at the ingress PCC is taken over by the mechanism specified in 835 [RFC8741] to request delegation. The control over the central 836 controller instructions is described above using [RFC8281]. 838 5.5.6. Synchronization of Central Controllers Instructions 840 The purpose of Central Controllers Instructions synchronization 841 (labels in the context of this document) is to make sure that the 842 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 843 This synchronization is performed as part of the LSP state 844 synchronization as described in [RFC8231] and [RFC8232]. 846 As per LSP State Synchronization [RFC8231], a PCC reports the state 847 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 848 would initiate any missing LSPs and/or remove any LSPs that are not 849 wanted. The same PCEP messages and procedures are also used for the 850 Central Controllers Instructions synchronization. The PCRpt message 851 includes the CCI and the LSP object to report the label forwarding 852 instructions. The PCE would further remove any unwanted instructions 853 or initiate any missing instructions. 855 5.5.7. PCECC LSP State Report 857 As mentioned before, an ingress PCC MAY choose to apply any OAM 858 mechanism to check the status of LSP in the Data plane and MAY 859 further send its status in a PCRpt message to the PCE. 861 5.5.8. PCC-Based Allocations 863 The PCE can request the PCC to allocate the label using the 864 PCInitiate message. The C flag in the CCI object is set to 1 to 865 indicate that the allocation needs to be done by the PCC. The PCC 866 SHOULD allocate the Label and SHOULD report to the PCE using the 867 PCRpt message. 869 If the value of the Label is 0 and the C flag is set to 1, it 870 indicates that the PCE is requesting the allocation to be done by the 871 PCC. If the Label is 'n' and the C flag is set to 1 in the CCI 872 object, it indicates that the PCE requests a specific value 'n' for 873 the Label. If the allocation is successful, the PCC MUST report via 874 the PCRpt message with the CCI object. Else, it MUST send a PCErr 875 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 876 TBD9 ("Invalid CCI"). If the value of the Label in the CCI object is 877 valid, but the PCC is unable to allocate it, it MUST send a PCErr 878 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 879 TBD10 ("Unable to allocate the specified CCI"). 881 If the PCC wishes to withdraw or modify the previously assigned 882 label, it MUST send a PCRpt message without any Label or with the 883 Label containing the new value respectively in the CCI object. The 884 PCE would further trigger the removal of the central controller 885 instruction as per this document. 887 6. PCEP Messages 889 As defined in [RFC5440], a PCEP message consists of a common header 890 followed by a variable-length body made of a set of objects that can 891 be either mandatory or optional. An object is said to be mandatory 892 in a PCEP message when the object must be included for the message to 893 be considered valid. For each PCEP message type, a set of rules is 894 defined that specify the set of objects that the message can carry. 895 An implementation MUST form the PCEP messages using the object 896 ordering specified in this document. 898 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 900 The message formats in this document are specified using Routing 901 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 903 6.1. The PCInitiate Message 905 The PCInitiate message [RFC8281] can be used to download or remove 906 the labels, this document extends the message as shown below - 908 ::= 909 910 Where: 911 is defined in [RFC5440] 913 ::= 914 [] 916 ::= 917 (| 918 | 919 ) 921 ::= 922 923 925 ::= 926 [] 928 Where: 929 and 930 are as per 931 [RFC8281]. 933 The LSP and SRP object is defined in [RFC8231]. 935 When PCInitiate message is used for the central controller 936 instructions (labels), the SRP, LSP, and CCI objects MUST be present. 937 The SRP object is defined in [RFC8231] and if the SRP object is 938 missing, the receiving PCC MUST send a PCErr message with Error- 939 type=6 (Mandatory Object missing) and Error-value=10 (SRP object 940 missing). The LSP object is defined in [RFC8231] and if the LSP 941 object is missing, the receiving PCC MUST send a PCErr message with 942 Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object 943 missing). The CCI object is defined in Section 7.3 and if the CCI 944 object is missing, the receiving PCC MUST send a PCErr message with 945 Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI 946 object missing). More than one CCI object MAY be included in the 947 PCInitiate message for a transit LSR. 949 To clean up entries, the R (remove) bit MUST be set in the SRP object 950 to be encoded along with the LSP and the CCI object. 952 The CCI object received at the ingress node MUST have the O bit (out- 953 label) set. The CCI Object received at the egress MUST have the O 954 bit unset. If this is not the case, PCC MUST send a PCErr message 955 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 956 ("Invalid CCI"). Other instances of the CCI object if present, MUST 957 be ignored. 959 At most two instances of the CCI object can be included, in the case 960 of transit LSR to encode both in-coming and out-going label 961 forwarding instructions. Other instances MUST be ignored for P2P 962 LSP. If the transit LSR did not receive two CCI object with one of 963 them having the O bit set and another with O bit unset, it MUST send 964 a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error 965 Value = TBD9 ("Invalid CCI"). 967 Note that, on receipt of the PCInitiate message with CCI object, the 968 ingress, egress, or transit role of the PCC is identified via the 969 ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV. 971 6.2. The PCRpt Message 973 The PCRpt message can be used to report the labels that were 974 allocated by the PCE, to be used during the state synchronization 975 phase or as acknowledgemnt to PCInitiate message. 977 ::= 978 979 Where: 981 ::= [] 983 ::= (| 984 ) 986 ::= [] 987 988 990 ::= [] 991 992 994 ::= 995 [] 997 Where: 998 is as per [RFC8231] and the LSP and SRP object are 999 also defined in [RFC8231]. 1001 When PCRpt message is used to report the central controller 1002 instructions (labels), the LSP and CCI objects MUST be present. The 1003 LSP object is defined in [RFC8231] and if the LSP object is missing, 1004 the receiving PCE MUST send a PCErr message with Error-type=6 1005 (Mandatory Object missing) and Error-value=8 (LSP object missing). 1006 The CCI object is defined in Section 7.3 and if the CCI object is 1007 missing, the receiving PCE MUST send a PCErr message with Error- 1008 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 1009 missing). Two CCI objects can be included in the PCRpt message for a 1010 transit LSR. 1012 7. PCEP Objects 1014 The PCEP objects defined in this document are compliant with the PCEP 1015 object format defined in [RFC5440]. 1017 7.1. OPEN Object 1019 This document defines a new PST (TBD1) to be included in the PATH- 1020 SETUP-TYPE-CAPABILITY TLV in the OPEN Object. Further, a new sub-TLV 1021 for PCECC capability exchange is also defined. 1023 7.1.1. PCECC Capability sub-TLV 1025 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 1026 Object in the PATH-SETUP-TYPE-CAPABILITY TLV, when the Path Setup 1027 Type list includes the PCECC Path Setup Type TBD1. A PCECC- 1028 CAPABILITY sub-TLV MUST be ignored if the PST list does not contain 1029 PST=TBD1. 1031 Its format is shown in Figure 7. 1033 0 1 2 3 1034 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Type=TBD12 | Length=4 | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Flags |L| 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Figure 7: PCECC Capability sub-TLV 1043 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 1045 The value comprises a single field - Flags (32 bits). Currently, the 1046 following flag bit is defined: 1048 o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates 1049 that the PCEP speaker support and willing to handle the PCECC 1050 based central controller instructions for label download. The bit 1051 MUST be set to 1 by both a PCC and a PCE for the PCECC label 1052 download/report on a PCEP session. 1054 o Unassigned bits MUST be set to 0 on transmission and MUST be 1055 ignored on receipt. 1057 7.2. PATH-SETUP-TYPE TLV 1059 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 1060 defines a new PST value: 1062 o PST = TBD1: Path is set up via PCECC mode. 1064 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in the PATH-SETUP- 1065 TYPE TLV in the SRP object MUST be included for a LSP set up via the 1066 PCECC-based mechanism. 1068 7.3. CCI Object 1070 The Central Controller Instructions (CCI) Object is used by the PCE 1071 to specify the forwarding instructions (Label information in the 1072 context of this document) to the PCC, and MAY be carried within 1073 PCInitiate or PCRpt message for label download/report. 1075 CCI Object-Class is TBD13. 1077 CCI Object-Type is 1 for the MPLS Label. 1079 0 1 2 3 1080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | CC-ID | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Reserved1 | Flags |C|O| 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Label | Reserved2 | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | | 1089 // Optional TLV // 1090 | | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 Figure 8: CCI Object 1095 The fields in the CCI object are as follows: 1097 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 1098 creates a CC-ID for each instruction, the value is unique within 1099 the scope of the PCE and is constant for the lifetime of a PCEP 1100 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1101 used. 1103 Reserved1 (16 bit): Set to zero while sending, ignored on receive. 1105 Flags (16 bit): A field used to carry any additional information 1106 pertaining to the CCI. Currently, the following flag bits are 1107 defined: 1109 * O bit(Out-label) : If the bit is set to 1, it specifies the 1110 label is the OUT label and it is mandatory to encode the next- 1111 hop information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1112 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1113 is not set, it specifies the label is the IN label and it is 1114 optional to encode the local interface information (via 1115 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1116 ADDRESS TLV in the CCI object). 1118 * C Bit (PCC Allocation): If the bit is set to 1, it indicates 1119 that the label allocation needs to be done by the PCC for this 1120 central controller instruction. A PCE sets this bit to request 1121 the PCC to make an allocation from its label space. A PCC 1122 would set this bit to indicate that it has allocated the label 1123 and report it to the PCE. 1125 * All unassigned bits MUST be set to zero at transmission and 1126 ignored at receipt. 1128 Label (20-bit): The Label information. 1130 Reserved2 (12 bit): Set to zero while sending, ignored on receive. 1132 7.3.1. Address TLVs 1134 This document defines the following TLVs for the CCI object to 1135 associate the next-hop information in the case of an outgoing label 1136 and local interface information in the case of an incoming label. 1138 IPV4-ADDRESS TLV: 1140 0 1 2 3 1141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Type=TBD14 | Length = 4 | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | IPv4 address | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 IPV6-ADDRESS TLV: 1150 0 1 2 3 1151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type=TBD15 | Length = 16 | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | | 1156 // IPv6 address (16 bytes) // 1157 | | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1162 0 1 2 3 1163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Type=TBD16 | Length = 8 | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Node-ID | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Interface ID | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1174 0 1 2 3 1175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Type=TBD17 | Length = 40 | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 // Local IPv6 address (16 octets) // 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Local Interface ID | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 // Remote IPv6 address (16 octets) // 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Remote Interface ID | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Figure 9: Address TLVs 1190 The address TLVs are as follows: 1192 IPV4-ADDRESS TLV: an IPv4 address. 1194 IPV6-ADDRESS TLV: an IPv6 address. 1196 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1198 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1199 interface ID) tuples. 1201 8. Implementation Status 1203 [Note to the RFC Editor - remove this section before publication, as 1204 well as remove the reference to RFC 7942.] 1206 This section records the status of known implementations of the 1207 protocol defined by this specification at the time of posting of this 1208 Internet-Draft, and is based on a proposal described in [RFC7942]. 1210 The description of implementations in this section is intended to 1211 assist the IETF in its decision processes in progressing drafts to 1212 RFCs. Please note that the listing of any individual implementation 1213 here does not imply endorsement by the IETF. Furthermore, no effort 1214 has been spent to verify the information presented here that was 1215 supplied by IETF contributors. This is not intended as, and must not 1216 be construed to be, a catalog of available implementations or their 1217 features. Readers are advised to note that other implementations may 1218 exist. 1220 According to [RFC7942], "this will allow reviewers and working groups 1221 to assign due consideration to documents that have the benefit of 1222 running code, which may serve as evidence of valuable experimentation 1223 and feedback that have made the implemented protocols more mature. 1224 It is up to the individual working groups to use this information as 1225 they see fit". 1227 8.1. Huawei's Proof of Concept based on ONOS 1229 The PCE function was developed in the ONOS open source platform. 1230 This extension was implemented on a private version as a proof of 1231 concept for PCECC. 1233 o Organization: Huawei 1235 o Implementation: Huawei's PoC based on ONOS 1237 o Description: PCEP as a southbound plugin was added to ONOS. To 1238 support PCECC, an earlier version of this I-D was implemented. 1239 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1241 o Maturity Level: Prototype 1243 o Coverage: Partial 1245 o Contact: satishk@huawei.com 1247 9. Security Considerations 1249 As per [RFC8283], the security considerations for a PCE-based 1250 controller is a little different from those for any other PCE system. 1251 That is, the operation relies heavily on the use and security of 1252 PCEP, so consideration should be given to the security features 1253 discussed in [RFC5440] and the additional mechanisms described in 1254 [RFC8253]. It further lists the vulnerability of a central 1255 controller architecture, such as a central point of failure, denial- 1256 of-service, and a focus for interception and modification of messages 1257 sent to individual NEs. 1259 In PCECC operations, the PCEP sessions are also required to the 1260 internal routers and thus increasing the resources required for the 1261 session management at the PCE. 1263 The PCECC extension builds on the existing PCEP messages and thus the 1264 security considerations described in [RFC5440], [RFC8231] and 1265 [RFC8281] continue to apply. [RFC8253] specify the support of 1266 Transport Layer Security (TLS) in PCEP, as it provides support for 1267 peer authentication, message encryption, and integrity. It further 1268 provide mechanisms for associating peer identities with different 1269 levels of access and/or authoritativeness, that can be used for the 1270 PCECC operations. Additional considerations are discussed in 1271 following sections. 1273 9.1. Malicious PCE 1275 In this extension, the PCE has complete control over the PCC to 1276 download/remove the labels and can cause the LSP's to behave 1277 inappropriately and cause a major impact to the network. As a 1278 general precaution, it is RECOMMENDED that this PCEP extension be 1279 activated on mutually-authenticated and encrypted sessions across 1280 PCEs and PCCs belonging to the same administrative authority, using 1281 TLS [RFC8253], as per the recommendations and best current practices 1282 in [RFC7525]. 1284 Further, an attacker may flood the PCC with PCECC related messages at 1285 a rate that exceeds either the PCC's ability to process them or the 1286 network's ability to send them, by either spoofing messages or 1287 compromising the PCE itself. [RFC8281] provides a mechanism to 1288 protect PCC by imposing a limit. The same can be used for the PCECC 1289 operations as well. 1291 9.2. Malicious PCC 1293 The PCECC mechanism described in this document requires the PCE to 1294 keep labels (CCI) that it downloads and relies on the PCC responding 1295 (with either an acknowledgment or an error message) to requests for 1296 LSP instantiation. This is an additional attack surface by placing a 1297 requirement for the PCE to keep a CCI/label replica for each PCC. It 1298 is RECOMMENDED that PCE implementations provide a limit on resources 1299 (in this case the CCI) a single PCC can occupy. [RFC8231] provides a 1300 notification mechanism when such threshold is reached. 1302 10. Manageability Considerations 1303 10.1. Control of Function and Policy 1305 A PCE or PCC implementation SHOULD allow to configure to enable/ 1306 disable PCECC capability as a global configuration. Section 6.1 of 1307 [RFC8664] list various controlling factors regarding path setup type. 1308 They are also applicable to the PCECC path setup types. Further, 1309 Section 6.2 of [RFC8664] describe the migration steps when path setup 1310 type of an existing LSP is changed. 1312 10.2. Information and Data Models 1314 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1315 PCECC capability status. 1317 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1318 enable/disable PCECC capability. 1320 10.3. Liveness Detection and Monitoring 1322 Mechanisms defined in this document do not imply any new liveness 1323 detection and monitoring requirements in addition to those already 1324 listed in [RFC5440]. 1326 10.4. Verify Correct Operations 1328 The operator needs the following information to verify that PCEP is 1329 operating correctly with respect to the PCECC path setup type. 1331 o An implementation SHOULD allow the operator to view whether the 1332 PCEP speaker sent the PCECC PST capability to its peer. 1334 o An implementation SHOULD allow the operator to view whether the 1335 peer sent the PCECC PST capability. 1337 o An implementation SHOULD allow the operator to view whether the 1338 PCECC PST is enabled on the PCEP session. 1340 o If one PCEP speaker advertises the PCECC PST capability, but the 1341 other does not, then the implementation SHOULD create a log to 1342 inform the operator of the capability mismatch. 1344 o If a PCEP speaker rejects a CCI, then it SHOULD create a log to 1345 inform the operator, giving the reason for the decision (local 1346 policy, Label issues, etc.). 1348 10.5. Requirements On Other Protocols 1350 PCEP extensions defined in this document do not put new requirements 1351 on other protocols. 1353 10.6. Impact On Network Operations 1355 PCEP extensions defined in this document do not put new requirements 1356 on network operations. 1358 11. IANA Considerations 1360 11.1. PCEP TLV Type Indicators 1362 IANA is requested to allocate the following TLV Type Indicator values 1363 within the "PCEP TLV Type Indicators" sub-registry of the PCEP 1364 Numbers registry: 1366 Value Meaning Reference 1367 TBD14 IPV4-ADDRESS TLV This document 1368 TBD15 IPV6-ADDRESS TLV This document 1369 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1370 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1372 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1374 [RFC8408] requested the creation of "PATH-SETUP-TYPE-CAPABILITY Sub- 1375 TLV Type Indicators" sub-registry. Further IANA is requested to 1376 allocate the following code-point: 1378 Value Meaning Reference 1379 TBD12 PCECC-CAPABILITY This document 1381 11.3. PCECC-CAPABILITY sub-TLV's Flag field 1383 This document defines the PCECC-CAPABILITY sub-TLV and requests that 1384 IANA to create a new sub-registry to manage the value of the PCECC- 1385 CAPABILITY sub-TLV's 32-bits Flag field. New values are to be 1386 assigned by Standards Action [RFC8126]. Each bit should be tracked 1387 with the following qualities: 1389 o Bit number (counting from bit 0 as the most significant bit) 1391 o Capability description 1393 o Defining RFC 1395 Currently, there is one allocation in this registry. 1397 Bit Name Reference 1398 31 Label This document 1399 0-30 Unassigned This document 1401 11.4. Path Setup Type Registry 1403 [RFC8408] created a sub-registry within the "Path Computation Element 1404 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1405 IANA is requested to allocate a new code point within this registry, 1406 as follows: 1408 Value Description Reference 1409 TBD1 Traffic engineering path is This document 1410 set up using PCECC mode 1412 11.5. PCEP Object 1414 IANA is requested to allocate new code-point in the "PCEP Objects" 1415 sub-registry for the CCI object as follows: 1417 Object-Class Value Name Reference 1418 TBD13 CCI Object-Type This document 1419 0 Reserved 1420 1 MPLS Label 1422 11.6. CCI Object Flag Field 1424 IANA is requested to create a new sub-registry to manage the Flag 1425 field of the CCI object called "CCI Object 16-bits Flag Field". New 1426 values are to be assigned by Standards Action [RFC8126]. Each bit 1427 should be tracked with the following qualities: 1429 o Bit number (counting from bit 0 as the most significant bit) 1431 o Capability description 1433 o Defining RFC 1435 Two bits to be defined for the CCI Object flag field in this document 1436 as follows: 1438 Bit Description Reference 1439 0-13 Unassigned This document 1440 14 C Bit - PCC allocation This document 1441 15 O Bit - Specifies label This document 1442 is out-label 1444 11.7. PCEP-Error Object 1446 IANA is requested to allocate new error types and error values within 1447 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1448 PCEP Numbers registry for the following errors: 1450 Error-Type Meaning 1451 ---------- ------- 1452 6 Mandatory Object missing. 1454 Error-value = TBD11 : CCI object missing 1456 10 Reception of an invalid object. 1458 Error-value = TBD2 : Missing PCECC 1459 Capability sub-TLV 1460 19 Invalid operation. 1462 Error-value = TBD3 : Attempted PCECC 1463 operations when 1464 PCECC capability 1465 was not advertised 1466 Error-value = TBD4 : Stateful PCE 1467 capability was not 1468 advertised 1469 Error-value = TBD8 : Unknown Label 1471 TBD5 PCECC failure. 1473 Error-value = TBD6 : Label out of range. 1474 Error-value = TBD7 : Instruction failed. 1475 Error-value = TBD9 : Invalid CCI. 1476 Error-value = TBD10 : Unable to allocate 1477 the specified CCI. 1479 12. Acknowledgments 1481 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1482 Avantika, and Aijun Wang for their useful comments and suggestions. 1484 Thanks to Julien Meuric for shepherding this I-D and providing 1485 valuable comments. 1487 Thanks to Victoria Pritchard for a very detailed RTGDIR review. 1488 Thanks to Yaron Sheffer for the SECDIR review. Thanks to Gyan Mishra 1489 for the GENART review. 1491 13. References 1493 13.1. Normative References 1495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1496 Requirement Levels", BCP 14, RFC 2119, 1497 DOI 10.17487/RFC2119, March 1997, 1498 . 1500 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1501 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1502 DOI 10.17487/RFC5440, March 2009, 1503 . 1505 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1506 Used to Form Encoding Rules in Various Routing Protocol 1507 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1508 2009, . 1510 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1511 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1512 May 2017, . 1514 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1515 Computation Element Communication Protocol (PCEP) 1516 Extensions for Stateful PCE", RFC 8231, 1517 DOI 10.17487/RFC8231, September 2017, 1518 . 1520 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1521 Computation Element Communication Protocol (PCEP) 1522 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1523 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1524 . 1526 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1527 Hardwick, "Conveying Path Setup Type in PCE Communication 1528 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1529 July 2018, . 1531 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1532 and J. Hardwick, "Path Computation Element Communication 1533 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1534 DOI 10.17487/RFC8664, December 2019, 1535 . 1537 13.2. Informative References 1539 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1540 Element (PCE)-Based Architecture", RFC 4655, 1541 DOI 10.17487/RFC4655, August 2006, 1542 . 1544 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1545 Margaria, "Requirements for GMPLS Applications of PCE", 1546 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1547 . 1549 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1550 Computation Element Architecture", RFC 7399, 1551 DOI 10.17487/RFC7399, October 2014, 1552 . 1554 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1555 Hardwick, "Path Computation Element Communication Protocol 1556 (PCEP) Management Information Base (MIB) Module", 1557 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1558 . 1560 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1561 Application-Based Network Operations", RFC 7491, 1562 DOI 10.17487/RFC7491, March 2015, 1563 . 1565 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1566 "Recommendations for Secure Use of Transport Layer 1567 Security (TLS) and Datagram Transport Layer Security 1568 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1569 2015, . 1571 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1572 Code: The Implementation Status Section", BCP 205, 1573 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1574 . 1576 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1577 Writing an IANA Considerations Section in RFCs", BCP 26, 1578 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1579 . 1581 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1582 and D. Dhody, "Optimizations of Label Switched Path State 1583 Synchronization Procedures for a Stateful PCE", RFC 8232, 1584 DOI 10.17487/RFC8232, September 2017, 1585 . 1587 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1588 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1589 Path Computation Element Communication Protocol (PCEP)", 1590 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1591 . 1593 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1594 Architecture for Use of PCE and the PCE Communication 1595 Protocol (PCEP) in a Network with Central Control", 1596 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1597 . 1599 [RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 1600 M. Negi, "Ability for a Stateful Path Computation Element 1601 (PCE) to Request and Obtain Control of a Label Switched 1602 Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, 1603 . 1605 [I-D.ietf-teas-pcecc-use-cases] 1606 Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang, 1607 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1608 Gulida, "The Use Cases for Path Computation Element (PCE) 1609 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1610 use-cases-06 (work in progress), September 2020. 1612 [I-D.ietf-pce-pcep-yang] 1613 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1614 YANG Data Model for Path Computation Element 1615 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1616 yang-15 (work in progress), October 2020. 1618 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1619 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1620 Procedures and Protocol Extensions for Using PCE as a 1621 Central Controller (PCECC) for Segment Routing (SR) MPLS 1622 Segment Identifier (SID) Allocation and Distribution.", 1623 draft-zhao-pce-pcep-extension-pce-controller-sr-09 (work 1624 in progress), November 2020. 1626 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1627 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 1628 and Protocol Extensions for Using PCE as a Central 1629 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1630 extension-pce-controller-srv6-05 (work in progress), 1631 November 2020. 1633 [I-D.li-pce-controlled-id-space] 1634 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1635 Controlled ID Space", draft-li-pce-controlled-id-space-07 1636 (work in progress), October 2020. 1638 Appendix A. Contributor Addresses 1640 Dhruv Dhody 1641 Huawei Technologies 1642 Divyashree Techno Park, Whitefield 1643 Bangalore, Karnataka 560066 1644 India 1646 EMail: dhruv.ietf@gmail.com 1648 Satish Karunanithi 1649 Huawei Technologies 1650 Divyashree Techno Park, Whitefield 1651 Bangalore, Karnataka 560066 1652 India 1654 EMail: satishk@huawei.com 1656 Adrian Farrel 1657 Old Dog Consulting 1658 UK 1660 EMail: adrian@olddog.co.uk 1662 Xuesong Geng 1663 Huawei Technologies 1664 China 1666 Email: gengxuesong@huawei.com 1668 Udayasree Palle 1670 EMail: udayasreereddy@gmail.com 1672 Katherine Zhao 1673 Futurewei Technologies 1675 EMail: katherine.zhao@futurewei.com 1677 Boris Zhang 1678 Telus Ltd. 1679 Toronto 1680 Canada 1682 EMail: boris.zhang@telus.com 1684 Alex Tokar 1685 Cisco Systems 1686 Slovak Republic 1688 EMail: atokar@cisco.com 1690 Authors' Addresses 1692 Zhenbin Li 1693 Huawei Technologies 1694 Huawei Bld., No.156 Beiqing Rd. 1695 Beijing 100095 1696 China 1698 EMail: lizhenbin@huawei.com 1700 Shuping Peng 1701 Huawei Technologies 1702 Huawei Bld., No.156 Beiqing Rd. 1703 Beijing 100095 1704 China 1706 EMail: pengshuping@huawei.com 1708 Mahendra Singh Negi 1709 RtBrick Inc 1710 N-17L, 18th Cross Rd, HSR Layout 1711 Bangalore, Karnataka 560102 1712 India 1714 EMail: mahend.ietf@gmail.com 1716 Quintin Zhao 1717 Etheric Networks 1718 1009 S CLAREMONT ST 1719 SAN MATEO, CA 94402 1720 USA 1722 EMail: qzhao@ethericnetworks.com 1724 Chao Zhou 1725 HPE 1727 EMail: chaozhou_us@yahoo.com