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