idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-08.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 (November 1, 2020) is 1243 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-14 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-07 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-04 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 Summary: 0 errors (**), 0 flaws (~~), 8 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: May 5, 2021 M. Negi 6 RtBrick Inc 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 November 1, 2020 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-08 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 May 5, 2021. 61 Copyright Notice 63 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . 8 89 5.5.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 8 90 5.5.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 12 91 5.5.3. Central Controller Instructions . . . . . . . . . . . 14 92 5.5.3.1. Label Download CCI . . . . . . . . . . . . . . . 15 93 5.5.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 15 94 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 16 95 5.5.5. Re-Delegation and Clean up . . . . . . . . . . . . . 19 96 5.5.6. Synchronization of Central Controllers Instructions . 19 97 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 20 98 5.5.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 20 99 5.5.9. Binding Label . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . 29 113 10. Manageability Considerations . . . . . . . . . . . . . . . . 30 114 10.1. Control of Function and Policy . . . . . . . . . . . . . 30 115 10.2. Information and Data Models . . . . . . . . . . . . . . 30 116 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 30 117 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 30 118 10.5. Requirements On Other Protocols . . . . . . . . . . . . 30 119 10.6. Impact On Network Operations . . . . . . . . . . . . . . 30 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 121 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 31 122 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 31 123 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 31 124 11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 31 125 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 32 126 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 32 127 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 32 128 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 129 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 131 13.2. Informative References . . . . . . . . . . . . . . . . . 34 132 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 37 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 specifies a new PCEP object called CCI (see 305 Section 7.3) for the encoding of the central controller instructions. 306 In the scope of this document, this is limited to Label forwarding 307 instructions. Future documents can create new CCI object-types for 308 other types of central controller instructions. The CC-ID is the 309 unique identifier for the central controller instructions in PCEP. 310 The PCEP messages are extended in this document to handle the PCECC 311 operations. 313 5.4. PCECC Capability Advertisement 315 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 316 advertise their support of PCECC extensions. 318 This document defines a new Path Setup Type (PST) [RFC8408] for 319 PCECC, as follows: 321 o PST = TBD1: Path is set up via PCECC mode. 323 A PCEP speaker MUST indicate its support of the function described in 324 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 325 object with this new PST included in the PST list. 327 This document also defines the PCECC Capability sub-TLV 328 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 329 information about their PCECC capability. If a PCEP speaker includes 330 PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then 331 the receiving peer MUST also include the PCECC Capability sub-TLV 332 (with the L bit set to 1) inside the PATH-SETUP-TYPE-CAPABILITY TLV. 333 If the sub-TLV is absent or the L bit is not set to 1, then the 334 receiving PCEP speaker MUST send a PCErr message with Error-Type 10 335 (Reception of an invalid object) and Error-Value TBD2 (Missing PCECC 336 Capability sub-TLV) and MUST then close the PCEP session. If a PCEP 337 speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC- 338 CAPABILITY sub-TLV, but the PST list does not contain PST=TBD1, then 339 the PCEP speaker MUST ignore the PCECC-CAPABILITY sub-TLV. 341 The presence of the PST=TBD1 and PCECC Capability sub-TLV (with the L 342 bit set to 1, see Section 7.1.1) in a PCC's OPEN Object indicates 343 that the PCC is willing to function as a PCECC client for label 344 download instructions. The presence of the PST=TBD1 and PCECC 345 Capability sub-TLV (with the L bit set to 1) in a PCE's OPEN message 346 indicates that the PCE is interested in function as a PCECC server 347 for label download instructions. 349 The PCEP extensions for PCECC for label download MUST NOT be used if 350 one or both PCEP Speakers have not included the PST=TBD1 or the PCECC 351 Capability sub-TLV (with the L bit set to 1) in their respective OPEN 352 message. If a PCEP speaker which supports the extensions of this 353 draft but did not advertise this capability attempts a PCECC 354 operation, then a PCErr message with Error-Type=19 (Invalid 355 Operation) and Error-Value=TBD3 (Attempted PCECC operations when 356 PCECC capability was not advertised) MUST be generated by its peer 357 and the PCEP session will be terminated. If a PCEP speaker does not 358 recognize the PCECC Capability sub-TLV, it will ignore the sub-TLV in 359 accordance with [RFC8408] and [RFC5440]. 361 A PCC or a PCE MUST include both the PCECC-CAPABILITY sub-TLV (with 362 the L bit set to 1) and the STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) 363 (with the I flag set [RFC8281]) in the OPEN Object to support the 364 extensions defined in this document. If the PCECC-CAPABILITY sub-TLV 365 is advertised and the STATEFUL-PCE-CAPABILITY TLV is not advertised 366 in the OPEN Object, it MUST send a PCErr message with Error-Type=19 367 (Invalid Operation) and Error-value=TBD4 (stateful PCE capability was 368 not advertised) and terminate the session. This error is also 369 triggered if the PCECC-CAPABILITY sub-TLV is advertised and the I 370 flag in the STATEFUL-PCE-CAPABILITY TLV is not set. 372 5.5. LSP Operations 374 The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE 375 TLV [RFC8408] in the SRP object to clearly identify that PCECC LSP is 376 intended. 378 5.5.1. PCE-Initiated PCECC LSP 380 The LSP Instantiation operation is the same as defined in [RFC8281]. 382 In order to set up a PCE-Initiated LSP based on the PCECC mechanism, 383 a PCE sends PCInitiate message with Path Setup Type set for PCECC 384 (see Section 7.2) to the ingress PCC. 386 An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple 387 uniquely identifies the LSP in the network. The LSP object is 388 included in the central controller instructions (label download 389 Section 7.3) to identify the PCECC LSP for this instruction. The 390 PLSP-ID is the original identifier used by the ingress PCC, so a 391 transit/egress LSR could have multiple central controller 392 instructions that have the same PLSP-ID. The PLSP-ID in combination 393 with the source (in LSP-IDENTIFIER TLV) MUST be unique. The PLSP-ID 394 is included for maintainability reasons to ease debugging. As per 395 [RFC8281], the LSP object could also include the SPEAKER-ENTITY-ID 396 TLV to identify the PCE that initiated these instructions. Also, the 397 CC-ID is unique in the PCEP session as described in Section 7.3. 399 The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 400 (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message 401 to the PCE. The PCC responds with a PCRpt message with the status 402 set to "GOING-UP" and carrying the assigned PLSP-ID. When the PCE 403 receives this PCRpt message with the PLSP-ID, it assigns labels along 404 the path; and sets up the path by sending a PCInitiate message to 405 each node along the path of the LSP as per the PCECC technique. The 406 CC-ID uniquely identifies the central controller instruction within a 407 PCEP session. Each PCC further responds with the PCRpt messages 408 including the central controller instruction (CCI) and the LSP 409 objects. 411 Note that the label forwarding instructions (see Section 5.5.3) from 412 PCECC are sent after the initial PCInitiate and PCRpt message 413 exchange with the ingress PCC. This is done so that the PLSP-ID and 414 other LSP identifiers can be obtained from the ingress and can be 415 included in the label forwarding instruction in the next set of 416 PCInitiate messages. 418 The ingress node would receive one CCI object with O bit (out-label) 419 set. The transit node(s) would receive two CCI objects with the in- 420 label CCI without an O bit set and the out-label CCI with O bit set. 421 The egress node would receive one CCI object without O bit set. A 422 node can determine its role based on the setting of the O bit in the 423 CCI object(s) and the LSP-IDENTIFIER TLV in the LSP object. 425 The LSP deletion operation for PCE-Initiated PCECC LSP is the same as 426 defined in [RFC8281]. The PCE should further perform Label entry 427 clean up operation as described in Section 5.5.3.2 for the 428 corresponding LSP. 430 The PCE-Initiated PCECC LSP setup sequence is shown in Figure 1. 432 +-------+ +-------+ 433 |PCC | | PCE | 434 |ingress| +-------+ 435 +------| | | 436 | PCC +-------+ | 437 | transit| | | 438 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 439 |PCC +--------+ | | Initiate 440 |egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 441 +--------+ | | (GOING-UP) | 442 | | | | 443 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 444 | | | | download 445 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 446 | | | | 447 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 448 | | | | download 449 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 450 | | | | 451 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 452 | | | | download 453 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 454 | | | | 455 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP 456 | | | (UP) | Update 457 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 458 | | | (UP) | 460 Figure 1: PCE-Initiated PCECC LSP 462 Once the label operations are completed, the PCE SHOULD send a PCUpd 463 message to the ingress PCC. The PCUpd message is as per [RFC8231]. 465 The PCECC LSPs are considered to be 'up' by default (on receipt of 466 PCUpd message from PCE). The ingress MAY further choose to deploy a 467 data plane check mechanism and report the status back to the PCE via 468 a PCRpt message to make sure that the correct label instructions are 469 made along the path of the PCECC LSP (and it is ready to carry 470 traffic). 472 In the case where the label allocations are made by the PCC itself 473 (see Section 5.5.8), the PCE could request an allocation to be made 474 by the PCC, and then the PCC would send a PCRpt with the allocated 475 label encoded in the CC-ID object as shown in Figure 2 in the 476 configuration sequence from the egress towards the ingress along the 477 path. 479 +-------+ +-------+ 480 |PCC | | PCE | 481 |ingress| +-------+ 482 +------| | | 483 | PCC +-------+ | 484 | transit| | | 485 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 486 |PCC +--------+ | | Initiate 487 |egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 488 +--------+ | | (GOING-UP) | 489 | | | | 490 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 491 | | | C=1 | download 492 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 493 | | | Label=L1 | 494 | |<----- PCInitiate,PLSP-ID=2, ---------------| Labels 495 | | | CC-ID=Y1,C=1 | download 496 | | | CC-ID=Y2,C=0,L1 | CCI 497 | |----- PCRpt,PLSP-ID=2 ------------------->| 498 | | | CC-ID=Y1, Label=L2 | 499 | | | CC-ID=Y2 | 500 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 -- | Label 501 | | | C=0,L2 | download 502 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 503 | | | | 504 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1---| PCECC LSP 505 | | | (UP) | Update 507 - The O bit is set as before (and thus not included) 509 Figure 2: PCE-Initiated PCECC LSP (PCC allocation) 511 It should be noted that in this example, the request is made to the 512 egress node with the C bit set in the CCI object to indicate that the 513 label allocation needs to be done by the egress and the egress 514 responds with the allocated label to the PCE. The PCE further inform 515 the transit PCC without setting the C bit to 1 in the CCI object for 516 out-label but the C bit is set to 1 for in-label so the transit node 517 make the label allocation (for the in-label) and report to the PCE. 518 Similarly, the C bit is unset towards the ingress to complete all the 519 label allocation for the PCECC LSP. 521 5.5.2. PCC-Initiated PCECC LSP 523 In order to set up an LSP based on the PCECC mechanism where the LSP 524 is configured at the PCC, a PCC MUST delegate the LSP by sending a 525 PCRpt message with PST set for PCECC (see Section 7.2) and D 526 (Delegate) flag (see [RFC8231]) set in the LSP object. 528 When a PCE receives the initial PCRpt message with D flag and PST 529 Type set to TBD1, it SHOULD calculate the path and assigns labels 530 along the path; and sets up the path by sending a PCInitiate message 531 to each node along the path of the LSP as per the PCECC technique. 532 The CC-ID uniquely identifies the central controller instruction 533 within a PCEP session. Each PCC further responds with the PCRpt 534 messages including the central controller instruction (CCI) and the 535 LSP objects. 537 Once the central controller instructions (label operations) are 538 completed, the PCE MUST send the PCUpd message to the ingress PCC. 539 Per [RFC8231], this PCUpd message should include the path information 540 calculated by the PCE. 542 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 544 The LSP deletion operation for PCECC LSPs is the same as defined in 545 [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then 546 it does label clean up operation as described in Section 5.5.3.2 for 547 the corresponding LSP. 549 The Basic PCECC LSP setup sequence is as shown in Figure 3. 551 +-------+ +-------+ 552 |PCC | | PCE | 553 |ingress| +-------+ 554 +------| | | 555 | PCC +-------+ | 556 | transit| | | 557 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 558 |PCC +--------+ | | 559 |egress | | | | 560 +--------+ | | | 561 | | | | 562 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 563 | | | L1,O=0 | download 564 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 565 | | | | 566 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 567 | | | CC-ID=Y1,O=0,L2 | download 568 | | | CC-ID=Y2,O=1,L1 | CCI 569 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 570 | | | | 571 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 572 | | | L2,O=1 | download 573 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 574 | | | | 575 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 576 | | | | Update 577 | | | | 579 Figure 3: PCC-Initiated PCECC LSP 581 In the case where the label allocations are made by the PCC itself 582 (see Section 5.5.8), the PCE could request an allocation to be made 583 by the PCC, and then the PCC would send a PCRpt with the allocated 584 label encoded in the CC-ID object as shown in Figure 4. 586 +-------+ +-------+ 587 |PCC | | PCE | 588 |ingress| +-------+ 589 +------| | | 590 | PCC +-------+ | 591 | transit| | | 592 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 593 |PCC +--------+ | | 594 |egress | | | | 595 +--------+ | | | 596 | | | | 597 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 598 | | | C=1 | download 599 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 600 | | | Label=L1 | 601 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 602 | | | CC-ID=Y1,C=1 | download 603 | | | CC-ID=Y2,C=0,L1 | CCI 604 | |----- PCRpt,PLSP-ID=1 ------------------>| 605 | | | CC-ID=Y1, Label=L2 | 606 | | | CC-ID=Y2 | 607 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 608 | | | C=0,L2 | download 609 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 610 | | | | 611 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 612 | | | | Update 613 | | | | 615 - The O bit is set as before (and thus not included) 617 Figure 4: PCC-Initiated PCECC LSP (PCC allocation) 619 In the case where the label allocations are made by the PCC itself 620 (see Section 5.5.8), the procedure remains the same, with just an 621 additional constraint on the configuration sequence. 623 The rest of the PCC-Initiated PCECC LSP setup operations are the same 624 as those described in Section 5.5.1. 626 5.5.3. Central Controller Instructions 628 The new central controller instructions (CCI) for the label 629 operations in PCEP is done via the PCInitiate message, by defining a 630 new PCEP Object for CCI operations. The local label range of each 631 PCC is assumed to be known by both the PCC and the PCE. 633 5.5.3.1. Label Download CCI 635 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 636 message to each node along the path to download the Label instruction 637 as described in Section 5.5.1 and Section 5.5.2. 639 The CCI object MUST be included, along with the LSP object in the 640 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the 641 LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP 642 object. 644 If a node (PCC) receives a PCInitiate message which includes a Label 645 to download, as part of CCI, that is out of the range set aside for 646 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 647 failure) and Error-value=TBD6 (Label out of range) and MUST include 648 the SRP object to specify the error is for the corresponding label 649 update via PCInitiate message. If a PCC receives a PCInitiate 650 message but fails to download the Label entry, it MUST send a PCErr 651 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 652 (instruction failed) and MUST include the SRP object to specify the 653 error is for the corresponding label update via PCInitiate message. 655 A new PCEP object for central controller instructions (CCI) is 656 defined in Section 7.3. 658 5.5.3.2. Label Clean up CCI 660 In order to delete an LSP based on PCECC, the PCE sends a central 661 controller instructions via a PCInitiate message to each node along 662 the path of the LSP to clean up the Label forwarding instruction. 664 If the PCC receives a PCInitiate message but does not recognize the 665 label in the CCI, the PCC MUST generate a PCErr message with Error- 666 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 667 MUST include the SRP object to specify the error is for the 668 corresponding label clean up (via PCInitiate message). 670 The R flag in the SRP object defined in [RFC8281] specifies the 671 deletion of Label Entry in the PCInitiate message. 673 +-------+ +-------+ 674 |PCC | | PCE | 675 |ingress| +-------+ 676 +------| | | 677 | PCC +-------+ | 678 | transit| | | 679 +------| | | | 680 |PCC +--------+ | | 681 |egress | | | | 682 +--------+ | | | 683 | | | | 684 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 ------------ | Label 685 | | | R=1 | clean up 686 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 687 | | | | 688 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 -- | Label 689 | | | R=1 | clean up 690 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 691 | | | | 692 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 -- | Label 693 | | | R=1 | clean up 694 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 695 | | | | 696 | | |<--PCInitiate,PLSP-ID=2,PST=TBD1,R=1--| PCECC LSP 697 | | | | remove 699 Figure 5: Label Cleanup 701 As per [RFC8281], following the removal of the Label forwarding 702 instruction, the PCC MUST send a PCRpt message. The SRP object in 703 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 704 that triggered the removal. The R flag in the SRP object MUST be 705 set. 707 In the case where the label allocation is made by the PCC itself (see 708 Section 5.5.8), the removal procedure remains the same, adding the 709 sequence constraint. 711 5.5.4. PCECC LSP Update 713 In case of a modification of a PCECC LSP with a new path, a PCE sends 714 a PCUpd message to the ingress PCC. But to follow the make-before- 715 break procedures, the PCECC first updates new instructions based on 716 the updated LSP and then update to the ingress to switch traffic, 717 before cleaning up the former instructions. A new CC-ID is used to 718 identify the updated instruction, the existing identifiers in the LSP 719 object identify the existing LSP. Once new instructions are 720 downloaded, the PCE further updates the new path at the ingress which 721 triggers the traffic switch on the updated path. The ingress PCC 722 acknowledges with a PCRpt message, on receipt of the PCRpt message, 723 the PCE does clean up operation for the former LSP as described in 724 Section 5.5.3.2. 726 The PCECC LSP Update sequence is shown in Figure 6. 728 +-------+ +-------+ 729 |PCC | | PCE | 730 |ingress| +-------+ 731 +------| | | 732 | PCC +-------+ | 733 | transit| | | 734 +------| | | | 735 |PCC +--------+ | | 736 |egress | | | | 737 +--------+ | | | 738 | | | | New Path 739 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 740 | | | | trigger 741 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 742 | | | | 743 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 744 | | | | download 745 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 746 | | | | 747 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 748 | | | | download 749 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 750 | | | | 751 | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC 752 | | | SRP=S | LSP Update 753 | | | | 754 | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger 755 | | | (SRP=S) | Delete 756 | | | | former CCI 757 | | | | 758 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 759 | | | R=1 | clean up 760 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 761 | | | | 762 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 763 | | | R=1 | clean up 764 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 765 | | | | 766 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 767 | | | R=1 | clean up 768 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 769 | | | | 771 Figure 6: PCECC LSP Update 773 The modified PCECC LSPs are considered to be 'up' by default. The 774 ingress MAY further choose to deploy a data plane check mechanism and 775 report the status back to the PCE via a PCRpt message. 777 In the case where the label allocations are made by the PCC itself 778 (see Section 5.5.8), the procedure remains the same. 780 5.5.5. Re-Delegation and Clean up 782 As described in [RFC8281], a new PCE can gain control over an 783 orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain 784 control over the central controller instructions in the same way by 785 sending a PCInitiate message that includes the SRP, LSP, and CCI 786 objects and carries the CC-ID and PLSP-ID identifying the instruction 787 that it wants to take control of. 789 Further, as described in [RFC8281], the State Timeout Interval timer 790 ensures that a PCE crash does not result in automatic and immediate 791 disruption for the services using PCE-initiated LSPs. Similarly the 792 central controller instructions are not removed immediately upon PCE 793 failure. Instead, they are cleaned up on the expiration of this 794 timer. This allows for network clean up without manual intervention. 795 The PCC MUST support the removal of CCI as one of the behaviors 796 applied on expiration of the State Timeout Interval timer. 798 In case of PCC-initiated PCECC LSP, the control over the orphaned LSP 799 at the ingress PCC is taken over by the mechanism specified in 800 [RFC8741] to request delegation. The control over the central 801 controller instructions is described above using [RFC8281]. 803 5.5.6. Synchronization of Central Controllers Instructions 805 The purpose of Central Controllers Instructions synchronization 806 (labels in the context of this document) is to make sure that the 807 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 808 This synchronization is performed as part of the LSP state 809 synchronization as described in [RFC8231] and [RFC8232]. 811 As per LSP State Synchronization [RFC8231], a PCC reports the state 812 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 813 would initiate any missing LSPs and/or remove any LSPs that are not 814 wanted. The same PCEP messages and procedures are also used for the 815 Central Controllers Instructions synchronization. The PCRpt message 816 includes the CCI and the LSP object to report the label forwarding 817 instructions. The PCE would further remove any unwanted instructions 818 or initiate any missing instructions. 820 5.5.7. PCECC LSP State Report 822 As mentioned before, an ingress PCC MAY choose to apply any OAM 823 mechanism to check the status of LSP in the Data plane and MAY 824 further send its status in a PCRpt message to the PCE. 826 5.5.8. PCC-Based Allocations 828 The PCE can request the PCC to allocate the label using the 829 PCInitiate message. The C flag in the CCI object is set to 1 to 830 indicate that the allocation needs to be done by the PCC. The PCC 831 SHOULD allocate the Label and SHOULD report to the PCE using the 832 PCRpt message. 834 If the value of the Label is 0 and the C flag is set to 1, it 835 indicates that the PCE is requesting the allocation to be done by the 836 PCC. If the Label is 'n' and the C flag is set to 1 in the CCI 837 object, it indicates that the PCE requests a specific value 'n' for 838 the Label. If the allocation is successful, the PCC MUST report via 839 the PCRpt message with the CCI object. Else, it MUST send a PCErr 840 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 841 TBD9 ("Invalid CCI"). If the value of the Label in the CCI object is 842 valid, but the PCC is unable to allocate it, it MUST send a PCErr 843 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 844 TBD10 ("Unable to allocate the specified CCI"). 846 If the PCC wishes to withdraw or modify the previously assigned 847 label, it MUST send a PCRpt message without any Label or with the 848 Label containing the new value respectively in the CCI object. The 849 PCE would further trigger the removal of the central controller 850 instruction as per this document. 852 5.5.9. Binding Label 854 As per [I-D.ietf-pce-binding-label-sid], when a stateful PCE is 855 deployed for setting up TE paths, it may be desirable to report the 856 binding label to the stateful PCE for the purpose of enforcing end- 857 to-end TE. In the case of the PCECC, the binding label may be 858 allocated by the PCE itself as described in this section. This 859 procedure is thus applicable for all path setup types including 860 PCECC. 862 A P flag in the LSP object is introduced in 863 [I-D.ietf-pce-sr-path-segment] to indicate the allocation needs to be 864 made by the PCE. A PCC would set this bit to 1 (and carry the TE- 865 PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid] in the LSP object) 866 to request for allocation of the binding label by the PCE in the 867 PCReq or PCRpt message. A PCE would also set this bit to 1 to 868 indicate that the binding label is allocated by PCE and encoded in 869 the PCRep, PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is 870 present in LSP object). Further, a PCE would set this bit to 0 to 871 indicate that the allocation is done by the PCC instead. 873 The ingress PCC could request the binding label to be allocated by 874 the PCE via a PCRpt message as per [RFC8231]. The delegate flag 875 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 876 be included with no Binding Value. The PCECC would allocate the 877 binding label and further respond to ingress PCC with PCUpd message 878 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in an LSP 879 object. The P flag in the LSP object would be set to 1 to indicate 880 that the allocation is made by the PCE. 882 The PCE could allocate the binding label on its own accord for a PCE- 883 Initiated (or delegated) LSP. The allocated binding label needs to 884 be informed to the PCC. The PCE would use the PCInitiate message 885 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 886 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 887 object would be set to 1 to indicate that the allocation is made by 888 the PCE. 890 Before a PCE can allocate a binding label the PCECC capability MUST 891 be exchanged on the PCEP session. Note that the CCI object is not 892 used for binding allocation; this is done to maintain consistency 893 with the rest of the binding label/SID procedures as per 894 [I-D.ietf-pce-binding-label-sid]. 896 6. PCEP Messages 898 As defined in [RFC5440], a PCEP message consists of a common header 899 followed by a variable-length body made of a set of objects that can 900 be either mandatory or optional. An object is said to be mandatory 901 in a PCEP message when the object must be included for the message to 902 be considered valid. For each PCEP message type, a set of rules is 903 defined that specify the set of objects that the message can carry. 904 An implementation MUST form the PCEP messages using the object 905 ordering specified in this document. 907 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 909 The message formats in this document are specified using Routing 910 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 912 6.1. The PCInitiate Message 914 The PCInitiate message [RFC8281] can be used to download or remove 915 the labels, this document extends the message as shown below - 917 ::= 918 919 Where: 920 is defined in [RFC5440] 922 ::= 923 [] 925 ::= 926 (| 927 | 928 ) 930 ::= 931 932 934 ::= 935 [] 937 Where: 938 and 939 are as per 940 [RFC8281]. 942 The LSP and SRP object is defined in [RFC8231]. 944 When PCInitiate message is used for the central controller 945 instructions (labels), the SRP, LSP, and CCI objects MUST be present. 946 The SRP object is defined in [RFC8231] and if the SRP object is 947 missing, the receiving PCC MUST send a PCErr message with Error- 948 type=6 (Mandatory Object missing) and Error-value=10 (SRP object 949 missing). The LSP object is defined in [RFC8231] and if the LSP 950 object is missing, the receiving PCC MUST send a PCErr message with 951 Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object 952 missing). The CCI object is defined in Section 7.3 and if the CCI 953 object is missing, the receiving PCC MUST send a PCErr message with 954 Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI 955 object missing). More than one CCI object MAY be included in the 956 PCInitiate message for a transit LSR. 958 To clean up entries, the R (remove) bit MUST be set in the SRP object 959 to be encoded along with the LSP and the CCI object. 961 The CCI object received at the ingress node MUST have the O bit (out- 962 label) set. The CCI Object received at the egress MUST have the O 963 bit unset. If this is not the case, PCC MUST send a PCErr message 964 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 965 ("Invalid CCI"). Other instances of the CCI object if present, MUST 966 be ignored. 968 At most two instances of the CCI object can be included, in the case 969 of transit LSR to encode both in-coming and out-going label 970 forwarding instructions. Other instances MUST be ignored for P2P 971 LSP. If the transit LSR did not receive two CCI object with one of 972 them having the O bit set and another with O bit unset, it MUST send 973 a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error 974 Value = TBD9 ("Invalid CCI"). 976 Note that, on receipt of the PCInitiate message with CCI object, the 977 ingress, egress, or transit role of the PCC is identified via the 978 ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV. 980 6.2. The PCRpt Message 982 The PCRpt message can be used to report the labels that were 983 allocated by the PCE, to be used during the state synchronization 984 phase or as acknowledgemnt to PCInitiate message. 986 ::= 987 988 Where: 990 ::= [] 992 ::= (| 993 ) 995 ::= [] 996 997 999 ::= [] 1000 1001 1003 ::= 1004 [] 1006 Where: 1007 is as per [RFC8231] and the LSP and SRP object are 1008 also defined in [RFC8231]. 1010 When PCRpt message is used to report the central controller 1011 instructions (labels), the LSP and CCI objects MUST be present. The 1012 LSP object is defined in [RFC8231] and if the LSP object is missing, 1013 the receiving PCE MUST send a PCErr message with Error-type=6 1014 (Mandatory Object missing) and Error-value=8 (LSP object missing). 1015 The CCI object is defined in Section 7.3 and if the CCI object is 1016 missing, the receiving PCE MUST send a PCErr message with Error- 1017 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 1018 missing). Two CCI objects can be included in the PCRpt message for a 1019 transit LSR. 1021 7. PCEP Objects 1023 The PCEP objects defined in this document are compliant with the PCEP 1024 object format defined in [RFC5440]. 1026 7.1. OPEN Object 1028 This document defines new optional TLVs for use in the OPEN Object. 1030 7.1.1. PCECC Capability sub-TLV 1032 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 1033 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 1034 CAPABILITY TLV. Advertisement of the PCECC capability implies 1035 support of LSPs that are set up through PCECC as per PCEP extensions 1036 defined in this document. 1038 Its format is shown in Figure 7. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Type=TBD12 | Length=4 | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Flags |L| 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Figure 7: PCECC Capability sub-TLV 1050 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 1052 The value comprises a single field - Flags (32 bits). Currently, the 1053 following flag bit is defined: 1055 o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates 1056 that the PCEP speaker allows PCECC based central controller 1057 instructions for label download. The bit MUST be set to 1 by both 1058 a PCC and a PCE for the PCECC label download/report on a PCEP 1059 session. 1061 o Unassigned bits MUST be set to 0 on transmission and MUST be 1062 ignored on receipt. 1064 7.2. PATH-SETUP-TYPE TLV 1066 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 1067 defines a new PST value: 1069 o PST = TBD1: Path is set up via PCECC mode. 1071 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE 1072 TLV in SRP object indicates that this LSP was set up via a PCECC- 1073 based mechanism. 1075 7.3. CCI Object 1077 The Central Controller Instructions (CCI) Object is used by the PCE 1078 to specify the forwarding instructions (Label information in the 1079 context of this document) to the PCC, and MAY be carried within 1080 PCInitiate or PCRpt message for label download/report. 1082 CCI Object-Class is TBD13. 1084 CCI Object-Type is 1 for the MPLS Label. 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | CC-ID | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Reserved1 | Flags |C|O| 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Label | Reserved2 | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | | 1096 // Optional TLV // 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Figure 8: CCI Object 1102 The fields in the CCI object are as follows: 1104 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 1105 creates a CC-ID for each instruction, the value is unique within 1106 the scope of the PCE and is constant for the lifetime of a PCEP 1107 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1108 used. 1110 Reserved1 (16 bit): Set to zero while sending, ignored on receive. 1112 Flags (16 bit): A field used to carry any additional information 1113 pertaining to the CCI. Currently, the following flag bits are 1114 defined: 1116 * O bit(Out-label) : If the bit is set to 1, it specifies the 1117 label is the OUT label and it is mandatory to encode the next- 1118 hop information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1119 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1120 is not set, it specifies the label is the IN label and it is 1121 optional to encode the local interface information (via 1122 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1123 ADDRESS TLV in the CCI object). 1125 * C Bit (PCC Allocation): If the bit is set to 1, it indicates 1126 that the allocation needs to be done by the PCC for this 1127 central controller instruction. A PCE sets this bit to request 1128 the PCC to make an allocation from its label space. A PCC 1129 would set this bit to indicate that it has allocated the CC-ID 1130 and report it to the PCE. 1132 * All unassigned bits MUST be set to zero at transmission and 1133 ignored at receipt. 1135 Label (20-bit): The Label information. 1137 Reserved2 (12 bit): Set to zero while sending, ignored on receive. 1139 7.3.1. Address TLVs 1141 This document defines the following TLVs for the CCI object to 1142 associate the next-hop information in the case of an outgoing label 1143 and local interface information in the case of an incoming label. 1145 IPV4-ADDRESS TLV: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type=TBD14 | Length = 4 | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | IPv4 address | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 IPV6-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=TBD15 | Length = 16 | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | | 1163 // IPv6 address (16 bytes) // 1164 | | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1169 0 1 2 3 1170 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 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Type=TBD16 | Length = 8 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Node-ID | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Interface ID | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1181 0 1 2 3 1182 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 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Type=TBD17 | Length = 40 | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 // Local IPv6 address (16 octets) // 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Local Interface ID | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 // Remote IPv6 address (16 octets) // 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Remote Interface ID | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Figure 9: Address TLVs 1197 The address TLVs are as follows: 1199 IPV4-ADDRESS TLV: an IPv4 address. 1201 IPV6-ADDRESS TLV: an IPv6 address. 1203 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1205 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1206 interface ID) tuples. 1208 8. Implementation Status 1210 [Note to the RFC Editor - remove this section before publication, as 1211 well as remove the reference to RFC 7942.] 1213 This section records the status of known implementations of the 1214 protocol defined by this specification at the time of posting of this 1215 Internet-Draft, and is based on a proposal described in [RFC7942]. 1217 The description of implementations in this section is intended to 1218 assist the IETF in its decision processes in progressing drafts to 1219 RFCs. Please note that the listing of any individual implementation 1220 here does not imply endorsement by the IETF. Furthermore, no effort 1221 has been spent to verify the information presented here that was 1222 supplied by IETF contributors. This is not intended as, and must not 1223 be construed to be, a catalog of available implementations or their 1224 features. Readers are advised to note that other implementations may 1225 exist. 1227 According to [RFC7942], "this will allow reviewers and working groups 1228 to assign due consideration to documents that have the benefit of 1229 running code, which may serve as evidence of valuable experimentation 1230 and feedback that have made the implemented protocols more mature. 1231 It is up to the individual working groups to use this information as 1232 they see fit". 1234 8.1. Huawei's Proof of Concept based on ONOS 1236 The PCE function was developed in the ONOS open source platform. 1237 This extension was implemented on a private version as a proof of 1238 concept for PCECC. 1240 o Organization: Huawei 1242 o Implementation: Huawei's PoC based on ONOS 1244 o Description: PCEP as a southbound plugin was added to ONOS. To 1245 support PCECC, an earlier version of this I-D was implemented. 1246 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1248 o Maturity Level: Prototype 1250 o Coverage: Partial 1252 o Contact: satishk@huawei.com 1254 9. Security Considerations 1256 The security considerations described in [RFC8231] and [RFC8281] 1257 apply to the extensions described in this document. Additional 1258 considerations related to a malicious PCE are introduced. 1260 9.1. Malicious PCE 1262 PCE has complete control over PCC to update the labels and can cause 1263 the LSP's to behave inappropriately and cause major impact to the 1264 network. As a general precaution, it is RECOMMENDED that this PCEP 1265 extension be activated on authenticated and encrypted sessions across 1266 PCEs and PCCs belonging to the same administrative authority, using 1267 Transport Layer Security (TLS) [RFC8253], as per the recommendations 1268 and best current practices in [RFC7525]. 1270 10. Manageability Considerations 1272 10.1. Control of Function and Policy 1274 A PCE or PCC implementation SHOULD allow to configure to enable/ 1275 disable PCECC capability as a global configuration. 1277 10.2. Information and Data Models 1279 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1280 PCECC capability status. 1282 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1283 enable/disable PCECC capability. 1285 10.3. Liveness Detection and Monitoring 1287 Mechanisms defined in this document do not imply any new liveness 1288 detection and monitoring requirements in addition to those already 1289 listed in [RFC5440]. 1291 10.4. Verify Correct Operations 1293 Mechanisms defined in this document do not imply any new operation 1294 verification requirements in addition to those already listed in 1295 [RFC5440] and [RFC8231]. 1297 10.5. Requirements On Other Protocols 1299 PCEP extensions defined in this document do not put new requirements 1300 on other protocols. 1302 10.6. Impact On Network Operations 1304 PCEP extensions defined in this document do not put new requirements 1305 on network operations. 1307 11. IANA Considerations 1308 11.1. PCEP TLV Type Indicators 1310 IANA is requested to allocate the following TLV Type Indicator values 1311 within the "PCEP TLV Type Indicators" sub-registry of the PCEP 1312 Numbers registry: 1314 Value Meaning Reference 1315 TBD14 IPV4-ADDRESS TLV This document 1316 TBD15 IPV6-ADDRESS TLV This document 1317 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1318 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1320 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1322 [RFC8408] requested the creation of "PATH-SETUP-TYPE-CAPABILITY Sub- 1323 TLV Type Indicators" sub-registry. Further IANA is requested to 1324 allocate the following code-point: 1326 Value Meaning Reference 1327 TBD12 PCECC-CAPABILITY This document 1329 11.3. PCECC-CAPABILITY sub-TLV's Flag field 1331 This document defines the PCECC-CAPABILITY sub-TLV and requests that 1332 IANA to create a new sub-registry to manage the value of the PCECC- 1333 CAPABILITY sub-TLV's 32-bits Flag field. New values are to be 1334 assigned by Standards Action [RFC8126]. Each bit should be tracked 1335 with the following qualities: 1337 o Bit number (counting from bit 0 as the most significant bit) 1339 o Capability description 1341 o Defining RFC 1343 Currently, there is one allocation in this registry. 1345 Bit Name Reference 1346 31 Label This document 1347 0-30 Unassigned This document 1349 11.4. Path Setup Type Registry 1351 [RFC8408] created a sub-registry within the "Path Computation Element 1352 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1353 IANA is requested to allocate a new code point within this registry, 1354 as follows: 1356 Value Description Reference 1357 TBD1 Traffic engineering path is This document 1358 set up using PCECC mode 1360 11.5. PCEP Object 1362 IANA is requested to allocate new code-point in the "PCEP Objects" 1363 sub-registry for the CCI object as follows: 1365 Object-Class Value Name Reference 1366 TBD13 CCI Object-Type This document 1367 0 Reserved 1368 1 MPLS Label 1370 11.6. CCI Object Flag Field 1372 IANA is requested to create a new sub-registry to manage the Flag 1373 field of the CCI object called "CCI Object 16-bits Flag Field". New 1374 values are to be assigned by Standards Action [RFC8126]. Each bit 1375 should be tracked with the following qualities: 1377 o Bit number (counting from bit 0 as the most significant bit) 1379 o Capability description 1381 o Defining RFC 1383 Two bits to be defined for the CCI Object flag field in this document 1384 as follows: 1386 Bit Description Reference 1387 0-13 Unassigned This document 1388 14 C Bit - PCC allocation This document 1389 15 O Bit - Specifies label This document 1390 is out-label 1392 11.7. PCEP-Error Object 1394 IANA is requested to allocate new error types and error values within 1395 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1396 PCEP Numbers registry for the following errors: 1398 Error-Type Meaning 1399 ---------- ------- 1400 6 Mandatory Object missing. 1402 Error-value = TBD11 : CCI object missing 1404 10 Reception of an invalid object. 1406 Error-value = TBD2 : Missing PCECC 1407 Capability sub-TLV 1408 19 Invalid operation. 1410 Error-value = TBD3 : Attempted PCECC 1411 operations when 1412 PCECC capability 1413 was not advertised 1414 Error-value = TBD4 : Stateful PCE 1415 capability was not 1416 advertised 1417 Error-value = TBD8 : Unknown Label 1419 TBD5 PCECC failure. 1421 Error-value = TBD6 : Label out of range. 1422 Error-value = TBD7 : Instruction failed. 1423 Error-value = TBD9 : Invalid CCI. 1424 Error-value = TBD10 : Unable to allocate 1425 the specified CCI. 1427 12. Acknowledgments 1429 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1430 Avantika, and Aijun Wang for their useful comments and suggestions. 1432 Thanks to Julien Meuric for shepherding this I-D and providing 1433 valuable comments. 1435 13. References 1437 13.1. Normative References 1439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1440 Requirement Levels", BCP 14, RFC 2119, 1441 DOI 10.17487/RFC2119, March 1997, 1442 . 1444 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1445 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1446 DOI 10.17487/RFC5440, March 2009, 1447 . 1449 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1450 Used to Form Encoding Rules in Various Routing Protocol 1451 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1452 2009, . 1454 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1455 Writing an IANA Considerations Section in RFCs", BCP 26, 1456 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1457 . 1459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1460 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1461 May 2017, . 1463 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1464 Computation Element Communication Protocol (PCEP) 1465 Extensions for Stateful PCE", RFC 8231, 1466 DOI 10.17487/RFC8231, September 2017, 1467 . 1469 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1470 Computation Element Communication Protocol (PCEP) 1471 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1472 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1473 . 1475 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1476 Hardwick, "Conveying Path Setup Type in PCE Communication 1477 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1478 July 2018, . 1480 13.2. Informative References 1482 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1483 Element (PCE)-Based Architecture", RFC 4655, 1484 DOI 10.17487/RFC4655, August 2006, 1485 . 1487 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1488 Margaria, "Requirements for GMPLS Applications of PCE", 1489 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1490 . 1492 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1493 Computation Element Architecture", RFC 7399, 1494 DOI 10.17487/RFC7399, October 2014, 1495 . 1497 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1498 Hardwick, "Path Computation Element Communication Protocol 1499 (PCEP) Management Information Base (MIB) Module", 1500 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1501 . 1503 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1504 Application-Based Network Operations", RFC 7491, 1505 DOI 10.17487/RFC7491, March 2015, 1506 . 1508 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1509 "Recommendations for Secure Use of Transport Layer 1510 Security (TLS) and Datagram Transport Layer Security 1511 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1512 2015, . 1514 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1515 Code: The Implementation Status Section", BCP 205, 1516 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1517 . 1519 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1520 and D. Dhody, "Optimizations of Label Switched Path State 1521 Synchronization Procedures for a Stateful PCE", RFC 8232, 1522 DOI 10.17487/RFC8232, September 2017, 1523 . 1525 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1526 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1527 Path Computation Element Communication Protocol (PCEP)", 1528 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1529 . 1531 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1532 Architecture for Use of PCE and the PCE Communication 1533 Protocol (PCEP) in a Network with Central Control", 1534 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1535 . 1537 [RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 1538 M. Negi, "Ability for a Stateful Path Computation Element 1539 (PCE) to Request and Obtain Control of a Label Switched 1540 Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, 1541 . 1543 [I-D.ietf-teas-pcecc-use-cases] 1544 Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang, 1545 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1546 Gulida, "The Use Cases for Path Computation Element (PCE) 1547 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1548 use-cases-06 (work in progress), September 2020. 1550 [I-D.ietf-pce-pcep-yang] 1551 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1552 YANG Data Model for Path Computation Element 1553 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1554 yang-14 (work in progress), July 2020. 1556 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1557 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1558 Procedures and Protocol Extensions for Using PCE as a 1559 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 1560 pcep-extension-pce-controller-sr-07 (work in progress), 1561 July 2020. 1563 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1564 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 1565 and Protocol Extensions for Using PCE as a Central 1566 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1567 extension-pce-controller-srv6-04 (work in progress), July 1568 2020. 1570 [I-D.li-pce-controlled-id-space] 1571 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1572 Controlled ID Space", draft-li-pce-controlled-id-space-07 1573 (work in progress), October 2020. 1575 [I-D.ietf-pce-binding-label-sid] 1576 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 1577 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1578 in PCE-based Networks.", draft-ietf-pce-binding-label- 1579 sid-03 (work in progress), June 2020. 1581 [I-D.ietf-pce-sr-path-segment] 1582 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1583 "Path Computation Element Communication Protocol (PCEP) 1584 Extension for Path Segment in Segment Routing (SR)", 1585 draft-ietf-pce-sr-path-segment-01 (work in progress), May 1586 2020. 1588 Appendix A. Contributor Addresses 1590 Dhruv Dhody 1591 Huawei Technologies 1592 Divyashree Techno Park, Whitefield 1593 Bangalore, Karnataka 560066 1594 India 1596 EMail: dhruv.ietf@gmail.com 1598 Satish Karunanithi 1599 Huawei Technologies 1600 Divyashree Techno Park, Whitefield 1601 Bangalore, Karnataka 560066 1602 India 1604 EMail: satishk@huawei.com 1606 Adrian Farrel 1607 Old Dog Consulting 1608 UK 1610 EMail: adrian@olddog.co.uk 1612 Xuesong Geng 1613 Huawei Technologies 1614 China 1616 Email: gengxuesong@huawei.com 1618 Udayasree Palle 1620 EMail: udayasreereddy@gmail.com 1622 Katherine Zhao 1623 Futurewei Technologies 1625 EMail: katherine.zhao@futurewei.com 1627 Boris Zhang 1628 Telus Ltd. 1629 Toronto 1630 Canada 1632 EMail: boris.zhang@telus.com 1634 Alex Tokar 1635 Cisco Systems 1636 Slovak Republic 1638 EMail: atokar@cisco.com 1640 Authors' Addresses 1642 Zhenbin Li 1643 Huawei Technologies 1644 Huawei Bld., No.156 Beiqing Rd. 1645 Beijing 100095 1646 China 1648 EMail: lizhenbin@huawei.com 1650 Shuping Peng 1651 Huawei Technologies 1652 Huawei Bld., No.156 Beiqing Rd. 1653 Beijing 100095 1654 China 1656 EMail: pengshuping@huawei.com 1658 Mahendra Singh Negi 1659 RtBrick Inc 1660 N-17L, 18th Cross Rd, HSR Layout 1661 Bangalore, Karnataka 560102 1662 India 1664 EMail: mahend.ietf@gmail.com 1666 Quintin Zhao 1667 Etheric Networks 1668 1009 S CLAREMONT ST 1669 SAN MATEO, CA 94402 1670 USA 1672 EMail: qzhao@ethericnetworks.com 1674 Chao Zhou 1675 HPE 1677 EMail: chaozhou_us@yahoo.com