idnits 2.17.1 draft-li-pce-controlled-id-space-03.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 (June 27, 2019) is 1763 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-01 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-04 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-01 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Experimental J. Dong 5 Expires: December 29, 2019 Z. Li 6 Huawei Technologies 7 A. Wang 8 China Telecom 9 W. Cheng 10 China Mobile 11 C. Zhou 12 Cisco System 13 June 27, 2019 15 PCE Controlled ID Space 16 draft-li-pce-controlled-id-space-03 18 Abstract 20 The Path Computation Element Communication Protocol (PCEP) provides 21 mechanisms for Path Computation Elements (PCEs) to perform path 22 computations in response to Path Computation Clients (PCCs) requests. 23 The Stateful PCE extensions allow stateful control of Multiprotocol 24 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 25 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 26 in SR networks. 28 Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a 29 model where the PCC delegates control over one or more locally 30 configured LSPs to the PCE. Further, stateful PCE could also create 31 and delete PCE-initiated LSPs itself. A PCE-based central controller 32 (PCECC) simplify the processing of a distributed control plane by 33 integrating with elements of Software-Defined Networking (SDN). 35 In some use cases, such as PCECC or Binding Segment Identifier (SID) 36 for Segment Routing (SR), there are requirements for a stateful PCE 37 to make allocation of labels, SIDs, etc. These use cases require PCE 38 aware of various identifier spaces where to make allocations on 39 behalf of PCC. This document describes a mechanism for PCC to inform 40 the PCE of the identifier space under its control via PCEP. The 41 identifier could be MPLS label, SID or any other to-be-defined 42 identifier to be allocated by a PCE. 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 December 29, 2019. 61 Copyright Notice 63 Copyright (c) 2019 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 81 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 83 3.1.1. PCECC for MPLS/SR-MPLS . . . . . . . . . . . . . . . 4 84 3.1.2. PCECC for SRv6 . . . . . . . . . . . . . . . . . . . 5 85 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 86 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 89 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 90 5.1.2. FUNCT-ID-CONTROL-SPACE TLV . . . . . . . . . . . . . 8 91 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 97 10.2. Informative References . . . . . . . . . . . . . . . . . 12 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 [RFC5440] defines the stateless Path Computation Element 104 communication Protocol (PCEP) for Path Computation Elements (PCEs) to 105 perform path computations in response to Path Computation Clients 106 (PCCs) requests. For supporting stateful operations, [RFC8231] 107 specifies a set of extensions to PCEP to enable stateful control of 108 LSPs within and across PCEP sessions in compliance with [RFC4657]. 109 Furthermore, [RFC8281] describes the setup, maintenance, and teardown 110 of PCE-initiated LSPs under the stateful PCE model, without the need 111 for local configuration on the PCC, thus allowing for a dynamic 112 network that is centrally controlled and deployed. 114 [RFC8283] introduces the architecture for PCE as a central 115 controller, it examines the motivations and applicability for PCEP as 116 a control protocol in this environment, and introduces the 117 implications for the protocol. Also, 118 [I-D.ietf-pce-pcep-extension-for-pce-controller] specifies the 119 procedures and PCEP protocol extensions for using the PCE as the 120 central controller, where LSPs are calculated/setup/initiated and 121 label forwarding entries are downloaded through extending PCEP. 122 However, the document assumes that label range to be used by a PCE is 123 known and set on both PCEP peers. This extension adds the capability 124 to advertise the range via a PCEP extension. 126 Similarly, [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies 127 the procedures and PCEP protocol extensions when a PCE-based 128 controller is also responsible for configuring the forwarding actions 129 on the routers (SR SID distribution in this case), in addition to 130 computing the paths for packet flows in a segment routing network and 131 telling the edge routers what instructions to attach to packets as 132 they enter the network. However, the document assumes that label 133 range to be used by a PCE is known and set on both PCEP peers. This 134 extension adds the capability to advertise the range (from SRGB or 135 SRLB of the node) via a PCEP extension. 137 In addition, [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 138 specifies the procedures and PCEP protocol extensions of PCECC for 139 SRv6. An SRv6 SID is represented as LOC:FUNCT where LOC is the L 140 most significant bits and FUNCT is the 128-L least significant bits. 141 The FUNCT part of the SID is an opaque identification of a local 142 function bound to the SID. This extension adds the capability to 143 advertise the range of Function ID (FUNCT part) via a PCEP extension. 145 Once the PCC/node has given control over an ID space (for example 146 labels), the PCC/node MUST NOT allocate the ID from this ID space. 147 For example, a PCC/node MUST NOT use this labels from the PCE 148 controlled label space to make allocation for VPN Prefix distributed 149 via BGP or labels used for LDP/RSVP-TE signalling. This is done to 150 make sure that the PCE control over ID space does not conflict with 151 the existing node allocation. 153 The use case are described in Section 3. The ID space range 154 information can be advertised via the TLVs in the Open message. The 155 detailed procedures are described in Section 4, and the objects' 156 format is specified in Section 5. 158 2. Terminology 160 This memo makes use of the terms defined in [RFC5440], [RFC8231], 161 [RFC8283] and [RFC8402]. 163 2.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. Use cases 173 3.1. PCE-based Central Control 175 A PCE-based central controller (PCECC) can simplify the processing of 176 a distributed control plane by integrating with elements of SDN. 177 Thus, the LSP/SR path can be calculated/setup/initiated and the 178 label/SID forwarding entries can also be downloaded through a 179 centralized PCE server to each network devices along the path while 180 leveraging the existing PCE technologies as much as possible. 182 3.1.1. PCECC for MPLS/SR-MPLS 184 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes a mode 185 where LSPs are provisioned as explicit label instructions at each hop 186 on the end-to-end path. Each router along the path must be told what 187 label forwarding instructions to program and what resources to 188 reserve. The controller uses PCEP to communicate with each router 189 along the path of the end-to-end LSP. For this to work, the PCE- 190 based controller will take responsibility for managing some part of 191 the MPLS label space for each router that it controls as described in 192 section 3.1.2. of [RFC8283]. A mechanism for a PCC to inform the PCE 193 of such a label space to control is needed within PCEP. 195 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 196 allow a stateful PCE to compute, update or initiate SR-TE paths. 197 [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the 198 mechanism for PCECC to allocate and provision the node/prefix/ 199 adjacency label (SID) via PCEP. To make such allocation, PCE needs 200 to be aware of the label space from Segment Routing Global Block 201 (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node 202 that it controls. A mechanism for a PCC to inform the PCE of such 203 label space to control is needed within PCEP. The full SRGB/SRLB of 204 a node could be learned via existing IGP or BGP-LS mechanism. 206 3.1.2. PCECC for SRv6 208 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] describes the 209 mechanism for PCECC to allocate and provision the SRv6 SID via PCEP. 210 An SRv6 SID is represented as LOC:FUNCT 211 ([I-D.ietf-spring-srv6-network-programming]) where LOC is the L most 212 significant bits and FUNCT is the 128-L least significant bits. The 213 FUNCT part of the SID is an opaque identification of a local function 214 bound to the SID. To make such allocation, PCE needs to be aware of 215 the Function ID space (FUNCT part) of the node that it controls. A 216 mechanism for a PCC to inform the PCE of such a Function ID space to 217 control is needed within PCEP. 219 3.2. Binding SID Allocation 221 The headend of an SR Policy binds a Binding SID to its policy 222 [I-D.ietf-spring-segment-routing-policy]. The instantiation of which 223 may involve a list of SIDs. Currently Binding SID are allocated by 224 the node, but there is an inherent advantage in the Binding SID to be 225 allocated by a PCE to allow SR policies to be dynamically created, 226 updated according to the network status and operations. This is 227 described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 228 Therefore, a PCE needs to obtain the authority and control to 229 allocate Binding SID actively from the PCC's label space as described 230 in above use case. 232 4. Overview 234 During PCEP Initialization Phase, Open messages are exchanged between 235 PCCs and PCEs. The OPEN object may also contain a set of TLVs used 236 to convey capabilities in the Open message. The term 'ID' in this 237 document, could be a MPLS label, SRv6 Function ID or any other future 238 ID space for PCE to control and allocate from. A PCC can include a 239 corresponding ID-CONTROL-SPACE TLVs in the OPEN Object to inform the 240 corresponding ID space information that it wants the PCE to control. 241 This TLV MUST NOT be included by the PCE and MUST be ignored on 242 receipt by a PCC. This is an optional TLV, the PCE could be aware of 243 the ID space from some other means outside of PCEP. 245 For delegating multiple types of ID space, multiple TLVs 246 corresponding to each ID type MUST be included in an Open message. 247 The ID type can be MPLS label or other type of ID. The following ID- 248 CONTROL-SPACE TLV is defined in this document - 250 o LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS) 252 o FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID 254 The procedure of ID space control to PCE is shown below: 256 +-+-+ +-+-+ 257 |PCC| |PCE| 258 +-+-+ +-+-+ 259 | | 260 | Open msg (LABEL-CONTROL-SPACE,etc) | 261 | | 262 |-------- | 263 | \ Open msg | 264 | \ -----------------------------| 265 | \/ | 266 | /\ | 267 | / ---------------------------->| 268 | / | 269 |<------ Keepalive | 270 | ----------------------------| 271 |Keepalive / | 272 |-------- / | 273 | \/ | 274 | /\ | 275 |<------ ------------------------------>| 276 | | 278 Figure 1: ID space control to PCE 280 If the ID space control procedure is successful, the PCE will return 281 a KeepAlive message to the PCC. If there is any error in processing 282 the corresponding TLV, an Error (PCErr) message will be sent to the 283 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 284 value=TBD (ID space control failure). 286 After this process, a stateful PCE can learn the PCE controlled ID 287 spaces of a node (PCC) under its control. A PCE can then allocate 288 IDs within the control ID space. For example, a PCE can actively 289 allocate labels and download forwarding instructions for the PCECC 290 LSP as described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 291 A PCE can also allocate labels from the PCE controlled portion of the 292 SRGB/SRLB for PCECC-SR 293 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The full SRGB/SRLB 294 of a node could be learned via existing IGP or BGP-LS mechanism. 296 5. Objects 298 5.1. Open Object 300 For advertising the PCE controlled ID space to a PCE, this document 301 defines several TLVs within the OPEN object. 303 5.1.1. LABEL-CONTROL-SPACE TLV 305 For a PCC to inform the label space under the PCE control, this 306 document defines a new LABEL-CONTROL-SPACE TLV. 308 The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object, 309 and its format is shown in the following figure: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type=TBA | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Block | Flags | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Start (1) | Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Range (1) | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | ... | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | ... | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Start (n) | Reserved | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Range (n) | Reserved | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: LABEL-CONTROL-SPACE TLV 333 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 334 has a variable value. 336 Block(8 bits): the number of ID blocks. The range of a block is 337 described by a start field and a range field. 339 Flags (24 bits): No flag is currently defined. The unassigned bits 340 of Flags field MUST be set to 0 on transmission and MUST be ignored 341 on receipt. 343 Start(i) (24 bits): indicates the beginning of the label block i. 345 Range(i) (24 bits): indicates the range of the label block i. 347 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on 348 reception. 350 LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open 351 Message. On receipt, only the first instance is processed and others 352 MUST be ignored. 354 A stateful PCE can actively allocate labels and download forwarding 355 instructions for the PCECC LSP as described in 356 [I-D.ietf-pce-pcep-extension-for-pce-controller]. A PCE can also 357 allocate labels from SRGB/SRLB for PCECC-SR 358 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The Binding 359 Segments can also be selected for the PCE controlled space 360 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 362 5.1.2. FUNCT-ID-CONTROL-SPACE TLV 364 For a PCC to inform the SRv6 SID Function ID space under the PCE 365 control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV. 367 The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 368 object, and its format is shown in the following figure: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type=TBA | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Block | Flags |L| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | Start (1) | 379 | | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Range (1) | 384 | | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ...... | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | Start (n) | 391 | | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 | Range (n) | 396 | | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Loc Size | Locator (variable)... | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 404 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 405 has a variable value. 407 Block(8 bits): the number of ID blocks. The range of a block is 408 described by a start field and a range field. 410 Flags (24 bits): Following flags are currently defined 412 o L-flag: Locator flag, set when the locator information is included 413 in this TLV. If L-flag is unset, Loc Size and variable Locator 414 field MUST NOT be included in this TLV, and the ID spaces are 415 applicable to all Locators. 417 The unassigned bits of Flags field MUST be set to 0 on transmission 418 and MUST be ignored on receipt. 420 Start(i) (128 bits): indicates the beginning of the Function ID block 421 i. 423 Range(i) (128 bits): indicates the range of the Function ID block i. 425 Loc size(8 bits): indicates the bit length of a Locator. Appears 426 only when the L-flag is set. 428 Locator (variable length): the value of a Locator. The Function ID 429 spaces specified in this TLV are associated with this locator. 431 As per [RFC5440], the value portion of the PCEP TLV needs to be 432 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 433 trailing zeros to a 4-byte boundary. 435 Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN object 436 to specify Function ID space specefic to each locator. 438 A stateful PCE can actively allocate SRv6 SID and download forwarding 439 instructions for the PCECC SRv6 path as described in 440 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 442 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 443 to be known at PCE and FUNCT is allocated from the PCE controlled 444 Function ID block. 446 6. Other Considerations 448 In case of multiple PCEs, a PCC MAY decide to give control over 449 different ID space to each instance of the PCE. In case a PCC 450 includes the same ID space to multiple PCEs, the PCE SHOULD use 451 synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to 452 avoid allocating the same ID. 454 The PCE would allocate ID from the PCE controlled ID space. The PCC 455 would not allocate ID by itself from this space as long as it has an 456 active PCEP session to a PCE to which it has given control over the 457 ID space. 459 Note that if there is any change in the ID space, the PCC MUST bring 460 the session down and re-establish the session with new TLVs. During 461 state synchronization the PCE would need to consider the new ID space 462 into consideration and SHOULD re-establish the LSP/SR-paths if 463 needed. 465 The PCC can regain control of the ID space by closing the PCEP 466 session and require new session without ID space TLVs specified in 467 this document. 469 7. IANA Considerations 471 TBA. 473 8. Security Considerations 475 TBA. 477 9. Acknowledgements 479 TBD. 481 10. References 483 10.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 491 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 492 DOI 10.17487/RFC5440, March 2009, 493 . 495 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 496 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 497 May 2017, . 499 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 500 Computation Element Communication Protocol (PCEP) 501 Extensions for Stateful PCE", RFC 8231, 502 DOI 10.17487/RFC8231, September 2017, 503 . 505 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 506 Computation Element Communication Protocol (PCEP) 507 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 508 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 509 . 511 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 512 Architecture for Use of PCE and the PCE Communication 513 Protocol (PCEP) in a Network with Central Control", 514 RFC 8283, DOI 10.17487/RFC8283, December 2017, 515 . 517 10.2. Informative References 519 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 520 Element (PCE) Communication Protocol Generic 521 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 522 2006, . 524 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 525 Decraene, B., Litkowski, S., and R. Shakir, "Segment 526 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 527 July 2018, . 529 [I-D.ietf-pce-segment-routing] 530 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 531 and J. Hardwick, "PCEP Extensions for Segment Routing", 532 draft-ietf-pce-segment-routing-16 (work in progress), 533 March 2019. 535 [I-D.ietf-pce-pcep-extension-for-pce-controller] 536 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 537 and Protocol Extensions for Using PCE as a Central 538 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 539 extension-for-pce-controller-01 (work in progress), 540 February 2019. 542 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 543 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 544 and Protocol Extensions for Using PCE as a Central 545 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 546 extension-pce-controller-sr-04 (work in progress), 547 February 2019. 549 [I-D.litkowski-pce-state-sync] 550 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 551 Stateful Path Computation Element (PCE) Communication 552 Procedures.", draft-litkowski-pce-state-sync-05 (work in 553 progress), March 2019. 555 [I-D.ietf-spring-segment-routing-policy] 556 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 557 bogdanov@google.com, b., and P. Mattes, "Segment Routing 558 Policy Architecture", draft-ietf-spring-segment-routing- 559 policy-03 (work in progress), May 2019. 561 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 562 Negi, M., Li, Z., and X. Geng, "PCEP Procedures and 563 Protocol Extensions for Using PCE as a Central Controller 564 (PCECC) for SRv6", draft-dhody-pce-pcep-extension-pce- 565 controller-srv6-01 (work in progress), February 2019. 567 [I-D.ietf-spring-srv6-network-programming] 568 Filsfils, C., Camarillo, P., Leddy, J., 569 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 570 Network Programming", draft-ietf-spring-srv6-network- 571 programming-00 (work in progress), April 2019. 573 Appendix A. Contributors 575 Dhruv Dhody 577 Huawei Technologies 579 Divyashree Techno Park, Whitefield 581 Bangalore, Karnataka 560066 583 India 585 EMail: dhruv.ietf@gmail.com 587 Authors' Addresses 589 Cheng Li 590 Huawei Technologies 591 Huawei Campus, No. 156 Beiqing Rd. 592 Beijing 100095 593 China 595 EMail: chengli13@huawei.com 597 Mach(Guoyi) Chen 598 Huawei Technologies 599 Huawei Campus, No. 156 Beiqing Rd. 600 Beijing 100095 601 China 603 EMail: Mach.chen@huawei.com 605 Jie Dong 606 Huawei Technologies 607 Huawei Campus, No. 156 Beiqing Rd. 608 Beijing 100095 609 China 611 EMail: jie.dong@huawei.com 612 Zhenbin Li 613 Huawei Technologies 614 Huawei Campus, No. 156 Beiqing Rd. 615 Beijing 100095 616 China 618 EMail: lizhenbin@huawei.com 620 Aijun Wang 621 China Telecom 622 Beiqijia Town, 623 Beijing, Changping District 102209 624 China 626 EMail: wangaj.bri@chinatelecom.cn 628 Weiqiang Cheng 629 China Mobile 631 EMail: chengweiqiang@chinamobile.com 633 Chao Zhou 634 Cisco System 635 San Jose 636 USA 638 EMail: chao.zhou@cisco.com