idnits 2.17.1 draft-li-pce-controlled-id-space-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2020) is 1389 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-05 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-06 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 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 Huawei Technologies 5 Expires: January 7, 2021 A. Wang 6 China Telecom 7 W. Cheng 8 China Mobile 9 C. Zhou 10 Cisco System 11 July 6, 2020 13 PCE Controlled ID Space 14 draft-li-pce-controlled-id-space-06 16 Abstract 18 The Path Computation Element Communication Protocol (PCEP) provides 19 mechanisms for Path Computation Elements (PCEs) to perform path 20 computations in response to Path Computation Clients (PCCs) requests. 21 The Stateful PCE extensions allow stateful control of Multiprotocol 22 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 23 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 24 in SR networks. 26 Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a 27 model where the PCC delegates control over one or more locally 28 configured LSPs to the PCE. Further, stateful PCE could also create 29 and delete PCE-initiated LSPs itself. A PCE-based central controller 30 (PCECC) simplify the processing of a distributed control plane by 31 integrating with elements of Software-Defined Networking (SDN). 33 In some use cases, such as PCECC or Binding Segment Identifier (SID) 34 for Segment Routing (SR), there are requirements for a stateful PCE 35 to make allocation of labels, SIDs, etc. These use cases require PCE 36 aware of various identifier spaces where to make allocations on 37 behalf of PCC. This document describes a mechanism for PCC to inform 38 the PCE of the identifier space under its control via PCEP. The 39 identifier could be MPLS label, SID or any other to-be-defined 40 identifier to be allocated by a PCE. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 7, 2021. 59 Copyright Notice 61 Copyright (c) 2020 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 79 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 81 3.1.1. PCECC for MPLS/SR-MPLS . . . . . . . . . . . . . . . 4 82 3.1.2. PCECC for SRv6 . . . . . . . . . . . . . . . . . . . 5 83 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 84 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 87 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 88 5.1.2. FUNCT-ID-CONTROL-SPACE TLV . . . . . . . . . . . . . 8 89 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 10.2. Informative References . . . . . . . . . . . . . . . . . 12 96 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 [RFC5440] defines the stateless Path Computation Element 102 communication Protocol (PCEP) for Path Computation Elements (PCEs) to 103 perform path computations in response to Path Computation Clients 104 (PCCs) requests. For supporting stateful operations, [RFC8231] 105 specifies a set of extensions to PCEP to enable stateful control of 106 LSPs within and across PCEP sessions in compliance with [RFC4657]. 107 Furthermore, [RFC8281] describes the setup, maintenance, and teardown 108 of PCE-initiated LSPs under the stateful PCE model, without the need 109 for local configuration on the PCC, thus allowing for a dynamic 110 network that is centrally controlled and deployed. 112 [RFC8283] introduces the architecture for PCE as a central 113 controller, it examines the motivations and applicability for PCEP as 114 a control protocol in this environment, and introduces the 115 implications for the protocol. Also, 116 [I-D.ietf-pce-pcep-extension-for-pce-controller] specifies the 117 procedures and PCEP protocol extensions for using the PCE as the 118 central controller, where LSPs are calculated/setup/initiated and 119 label forwarding entries are downloaded through extending PCEP. 120 However, the document assumes that label range to be used by a PCE is 121 known and set on both PCEP peers. This extension adds the capability 122 to advertise the range via a PCEP extension. 124 Similarly, [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies 125 the procedures and PCEP protocol extensions when a PCE-based 126 controller is also responsible for configuring the forwarding actions 127 on the routers (SR SID distribution in this case), in addition to 128 computing the paths for packet flows in a segment routing network and 129 telling the edge routers what instructions to attach to packets as 130 they enter the network. However, the document assumes that label 131 range to be used by a PCE is known and set on both PCEP peers. This 132 extension adds the capability to advertise the range (from SRGB or 133 SRLB of the node) via a PCEP extension. 135 In addition, [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 136 specifies the procedures and PCEP protocol extensions of PCECC for 137 SRv6. An SRv6 SID is represented as LOC:FUNCT where LOC is the L 138 most significant bits and FUNCT is the 128-L least significant bits. 139 The FUNCT part of the SID is an opaque identification of a local 140 function bound to the SID. This extension adds the capability to 141 advertise the range of Function ID (FUNCT part) via a PCEP extension. 143 Once the PCC/node has given control over an ID space (for example 144 labels), the PCC/node MUST NOT allocate the ID from this ID space. 146 For example, a PCC/node MUST NOT use this labels from the PCE 147 controlled label space to make allocation for VPN Prefix distributed 148 via BGP or labels used for LDP/RSVP-TE signalling. This is done to 149 make sure that the PCE control over ID space does not conflict with 150 the existing node allocation. 152 The use case are described in Section 3. The ID space range 153 information can be advertised via the TLVs in the Open message. The 154 detailed procedures are described in Section 4, and the objects' 155 format is specified in Section 5. 157 2. Terminology 159 This memo makes use of the terms defined in [RFC5440], [RFC8231], 160 [RFC8283] and [RFC8402]. 162 2.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. Use cases 172 3.1. PCE-based Central Control 174 A PCE-based central controller (PCECC) can simplify the processing of 175 a distributed control plane by integrating with elements of SDN. 176 Thus, the LSP/SR path can be calculated/setup/initiated and the 177 label/SID forwarding entries can also be downloaded through a 178 centralized PCE server to each network devices along the path while 179 leveraging the existing PCE technologies as much as possible. 181 3.1.1. PCECC for MPLS/SR-MPLS 183 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes a mode 184 where LSPs are provisioned as explicit label instructions at each hop 185 on the end-to-end path. Each router along the path must be told what 186 label forwarding instructions to program and what resources to 187 reserve. The controller uses PCEP to communicate with each router 188 along the path of the end-to-end LSP. For this to work, the PCE- 189 based controller will take responsibility for managing some part of 190 the MPLS label space for each router that it controls as described in 191 section 3.1.2. of [RFC8283]. A mechanism for a PCC to inform the PCE 192 of such a label space to control is needed within PCEP. 194 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 195 allow a stateful PCE to compute, update or initiate SR-TE paths. 196 [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the 197 mechanism for PCECC to allocate and provision the node/prefix/ 198 adjacency label (SID) via PCEP. To make such allocation, PCE needs 199 to be aware of the label space from Segment Routing Global Block 200 (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node 201 that it controls. A mechanism for a PCC to inform the PCE of such 202 label space to control is needed within PCEP. The full SRGB/SRLB of 203 a node could be learned via existing IGP or BGP-LS mechanism. 205 3.1.2. PCECC for SRv6 207 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] describes the 208 mechanism for PCECC to allocate and provision the SRv6 SID via PCEP. 209 An SRv6 SID is represented as LOC:FUNCT 210 ([I-D.ietf-spring-srv6-network-programming]) where LOC is the L most 211 significant bits and FUNCT is the 128-L least significant bits. The 212 FUNCT part of the SID is an opaque identification of a local function 213 bound to the SID. To make such allocation, PCE needs to be aware of 214 the Function ID space (FUNCT part) of the node that it controls. A 215 mechanism for a PCC to inform the PCE of such a Function ID space to 216 control is needed within PCEP. 218 3.2. Binding SID Allocation 220 The headend of an SR Policy binds a Binding SID to its policy 221 [I-D.ietf-spring-segment-routing-policy]. The instantiation of which 222 may involve a list of SIDs. Currently Binding SID are allocated by 223 the node, but there is an inherent advantage in the Binding SID to be 224 allocated by a PCE to allow SR policies to be dynamically created, 225 updated according to the network status and operations. This is 226 described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 227 Therefore, a PCE needs to obtain the authority and control to 228 allocate Binding SID actively from the PCC's label space as described 229 in above use case. 231 4. Overview 233 During PCEP Initialization Phase, Open messages are exchanged between 234 PCCs and PCEs. The OPEN object may also contain a set of TLVs used 235 to convey capabilities in the Open message. The term 'ID' in this 236 document, could be a MPLS label, SRv6 Function ID or any other future 237 ID space for PCE to control and allocate from. A PCC can include a 238 corresponding ID-CONTROL-SPACE TLVs in the OPEN Object to inform the 239 corresponding ID space information that it wants the PCE to control. 240 This TLV MUST NOT be included by the PCE and MUST be ignored on 241 receipt by a PCC. This is an optional TLV, the PCE could be aware of 242 the ID space from some other means outside of PCEP. 244 For delegating multiple types of ID space, multiple TLVs 245 corresponding to each ID type MUST be included in an Open message. 246 The ID type can be MPLS label or other type of ID. The following ID- 247 CONTROL-SPACE TLV is defined in this document - 249 o LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS) 251 o FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID 253 The procedure of ID space control to PCE is shown below: 255 +-+-+ +-+-+ 256 |PCC| |PCE| 257 +-+-+ +-+-+ 258 | | 259 | Open msg (LABEL-CONTROL-SPACE,etc) | 260 | | 261 |-------- | 262 | \ Open msg | 263 | \ -----------------------------| 264 | \/ | 265 | /\ | 266 | / ---------------------------->| 267 | / | 268 |<------ Keepalive | 269 | ----------------------------| 270 |Keepalive / | 271 |-------- / | 272 | \/ | 273 | /\ | 274 |<------ ------------------------------>| 275 | | 277 Figure 1: ID space control to PCE 279 If the ID space control procedure is successful, the PCE will return 280 a KeepAlive message to the PCC. If there is any error in processing 281 the corresponding TLV, an Error (PCErr) message will be sent to the 282 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 283 value=TBD (ID space control failure). 285 After this process, a stateful PCE can learn the PCE controlled ID 286 spaces of a node (PCC) under its control. A PCE can then allocate 287 IDs within the control ID space. For example, a PCE can actively 288 allocate labels and download forwarding instructions for the PCECC 289 LSP as described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 290 A PCE can also allocate labels from the PCE controlled portion of the 291 SRGB/SRLB for PCECC-SR 292 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The full SRGB/SRLB 293 of a node could be learned via existing IGP or BGP-LS mechanism. 295 5. Objects 297 5.1. Open Object 299 For advertising the PCE controlled ID space to a PCE, this document 300 defines several TLVs within the OPEN object. 302 5.1.1. LABEL-CONTROL-SPACE TLV 304 For a PCC to inform the label space under the PCE control, this 305 document defines a new LABEL-CONTROL-SPACE TLV. 307 The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object, 308 and its format is shown in the following figure: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type=TBA | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Block | Flags | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Start (1) | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Range (1) | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | ... | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | ... | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Start (n) | Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Range (n) | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 2: LABEL-CONTROL-SPACE TLV 332 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 333 has a variable value. 335 Block(8 bits): the number of ID blocks. The range of a block is 336 described by a start field and a range field. 338 Flags (24 bits): No flag is currently defined. The unassigned bits 339 of Flags field MUST be set to 0 on transmission and MUST be ignored 340 on receipt. 342 Start(i) (24 bits): indicates the beginning of the label block i. 344 Range(i) (24 bits): indicates the range of the label block i. 346 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on 347 reception. 349 LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open 350 Message. On receipt, only the first instance is processed and others 351 MUST be ignored. 353 A stateful PCE can actively allocate labels and download forwarding 354 instructions for the PCECC LSP as described in 355 [I-D.ietf-pce-pcep-extension-for-pce-controller]. A PCE can also 356 allocate labels from SRGB/SRLB for PCECC-SR 357 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The Binding 358 Segments can also be selected for the PCE controlled space 359 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 361 5.1.2. FUNCT-ID-CONTROL-SPACE TLV 363 For a PCC to inform the SRv6 SID Function ID space under the PCE 364 control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV. 366 The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 367 object, and its format is shown in the following figure: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type=TBA | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Block | Flags |L| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | Start (1) | 378 | | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 | Range (1) | 383 | | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | ...... | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 | Start (n) | 390 | | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 | Range (n) | 395 | | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Loc Size | Locator (variable)... | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 403 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 404 has a variable value. 406 Block(8 bits): the number of ID blocks. The range of a block is 407 described by a start field and a range field. 409 Flags (24 bits): Following flags are currently defined 411 o L-flag: Locator flag, set when the locator information is included 412 in this TLV. If L-flag is unset, Loc Size and variable Locator 413 field MUST NOT be included in this TLV, and the ID spaces are 414 applicable to all Locators. 416 The unassigned bits of Flags field MUST be set to 0 on transmission 417 and MUST be ignored on receipt. 419 Start(i) (128 bits): indicates the beginning of the Function ID block 420 i. 422 Range(i) (128 bits): indicates the range of the Function ID block i. 424 Loc size(8 bits): indicates the bit length of a Locator. Appears 425 only when the L-flag is set. 427 Locator (variable length): the value of a Locator. The Function ID 428 spaces specified in this TLV are associated with this locator. 430 As per [RFC5440], the value portion of the PCEP TLV needs to be 431 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 432 trailing zeros to a 4-byte boundary. 434 Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN object 435 to specify Function ID space specefic to each locator. 437 A stateful PCE can actively allocate SRv6 SID and download forwarding 438 instructions for the PCECC SRv6 path as described in 439 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 441 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 442 to be known at PCE and FUNCT is allocated from the PCE controlled 443 Function ID block. 445 6. Other Considerations 447 In case of multiple PCEs, a PCC MAY decide to give control over 448 different ID space to each instance of the PCE. In case a PCC 449 includes the same ID space to multiple PCEs, the PCE SHOULD use 450 synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to 451 avoid allocating the same ID. 453 The PCE would allocate ID from the PCE controlled ID space. The PCC 454 would not allocate ID by itself from this space as long as it has an 455 active PCEP session to a PCE to which it has given control over the 456 ID space. 458 Note that if there is any change in the ID space, the PCC MUST bring 459 the session down and re-establish the session with new TLVs. During 460 state synchronization the PCE would need to consider the new ID space 461 into consideration and SHOULD re-establish the LSP/SR-paths if 462 needed. 464 The PCC can regain control of the ID space by closing the PCEP 465 session and require new session without ID space TLVs specified in 466 this document. 468 7. IANA Considerations 470 TBA. 472 8. Security Considerations 474 TBA. 476 9. Acknowledgements 478 TBD. 480 10. References 482 10.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 490 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 491 DOI 10.17487/RFC5440, March 2009, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 499 Computation Element Communication Protocol (PCEP) 500 Extensions for Stateful PCE", RFC 8231, 501 DOI 10.17487/RFC8231, September 2017, 502 . 504 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 505 Computation Element Communication Protocol (PCEP) 506 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 507 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 508 . 510 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 511 Architecture for Use of PCE and the PCE Communication 512 Protocol (PCEP) in a Network with Central Control", 513 RFC 8283, DOI 10.17487/RFC8283, December 2017, 514 . 516 10.2. Informative References 518 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 519 Element (PCE) Communication Protocol Generic 520 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 521 2006, . 523 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 524 Decraene, B., Litkowski, S., and R. Shakir, "Segment 525 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 526 July 2018, . 528 [I-D.ietf-pce-segment-routing] 529 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 530 and J. Hardwick, "PCEP Extensions for Segment Routing", 531 draft-ietf-pce-segment-routing-16 (work in progress), 532 March 2019. 534 [I-D.ietf-pce-pcep-extension-for-pce-controller] 535 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 536 Procedures and Protocol Extensions for Using PCE as a 537 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 538 extension-for-pce-controller-05 (work in progress), June 539 2020. 541 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 542 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 543 Procedures and Protocol Extensions for Using PCE as a 544 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 545 pcep-extension-pce-controller-sr-06 (work in progress), 546 March 2020. 548 [I-D.litkowski-pce-state-sync] 549 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 550 Stateful Path Computation Element (PCE) Communication 551 Procedures.", draft-litkowski-pce-state-sync-07 (work in 552 progress), January 2020. 554 [I-D.ietf-spring-segment-routing-policy] 555 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 556 P. Mattes, "Segment Routing Policy Architecture", draft- 557 ietf-spring-segment-routing-policy-07 (work in progress), 558 May 2020. 560 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 561 Negi, M., Li, Z., Geng, X., and S. Peng, "PCEP Procedures 562 and Protocol Extensions for Using PCE as a Central 563 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 564 extension-pce-controller-srv6-03 (work in progress), March 565 2020. 567 [I-D.ietf-spring-srv6-network-programming] 568 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 569 Matsushima, S., and Z. Li, "SRv6 Network Programming", 570 draft-ietf-spring-srv6-network-programming-16 (work in 571 progress), June 2020. 573 Appendix A. Contributors 575 Dhruv Dhody 576 Huawei Technologies 577 Divyashree Techno Park, Whitefield 578 Bangalore, Karnataka 560066 579 India 581 EMail: dhruv.ietf@gmail.com 583 Zhenbin Li 584 Huawei Technologies 585 Huawei Campus, No. 156 Beiqing Rd. 586 Beijing 100095 587 China 589 EMail: lizhenbin@huawei.com 591 Jie Dong 592 Huawei Technologies 593 Huawei Campus, No. 156 Beiqing Rd. 594 Beijing 100095 595 China 597 EMail: jie.dong@huawei.com 599 Authors' Addresses 601 Cheng Li 602 Huawei Technologies 603 Huawei Campus, No. 156 Beiqing Rd. 604 Beijing 100095 605 China 607 EMail: c.l@huawei.com 609 Mach(Guoyi) Chen 610 Huawei Technologies 611 Huawei Campus, No. 156 Beiqing Rd. 612 Beijing 100095 613 China 615 EMail: Mach.chen@huawei.com 616 Aijun Wang 617 China Telecom 618 Beiqijia Town, 619 Beijing, Changping District 102209 620 China 622 EMail: wangaj3@chinatelecom.cn 624 Weiqiang Cheng 625 China Mobile 627 EMail: chengweiqiang@chinamobile.com 629 Chao Zhou 630 Cisco System 631 San Jose 632 USA 634 EMail: chao.zhou@cisco.com