idnits 2.17.1 draft-li-pce-controlled-id-space-01.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 (December 18, 2018) is 1948 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-00 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-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: June 21, 2019 Z. Li 6 Huawei Technologies 7 A. Wang 8 China Telecom 9 December 18, 2018 11 PCE Controlled ID Space 12 draft-li-pce-controlled-id-space-01 14 Abstract 16 The Path Computation Element Communication Protocol (PCEP) provides 17 mechanisms for Path Computation Elements (PCEs) to perform path 18 computations in response to Path Computation Clients (PCCs) requests. 19 The Stateful PCE extensions allow stateful control of Multiprotocol 20 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 21 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 22 in SR networks. 24 Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a 25 model where the PCC delegates control over one or more locally 26 configured LSPs to the PCE. Further, stateful PCE could also create 27 and delete PCE-initiated LSPs itself. A PCE-based central controller 28 (PCECC) simplify the processing of a distributed control plane by 29 blending it with elements of Software-Defined Networking (SDN) and 30 without necessarily completely replacing it. 32 In some use cases, such as PCECC, Binding Segment Identifier (SID) 33 for Segment Routing (SR), there are requirements for a stateful PCE 34 to make allocation of labels, SIDs, etc. These use cases require for 35 a PCE to be aware of the various identifier space from which to make 36 allocations on behalf of PCC. This documents specify a mechanism for 37 a PCC to inform the PCE of the identifier space under its control via 38 PCEP. The identifier could be MPLS label, SID or another future 39 identifier to be allocated by a PCE. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on June 21, 2019. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 80 3.1.1. PCECC for MPLS/SR-MPLS . . . . . . . . . . . . . . . 4 81 3.1.2. PCECC for SRv6 . . . . . . . . . . . . . . . . . . . 5 82 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 83 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 86 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 87 5.1.2. FUNCT-ID-CONTROL-SPACE TLV . . . . . . . . . . . . . 8 88 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 11.2. Informative References . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 usecase 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 will be described in Section 4, and the objects' 155 format will be introduced 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 blending it with elements of SDN and 176 without necessarily completely replacing it. Thus, the LSP/SR path 177 can be calculated/setup/initiated and the label/SID forwarding 178 entries can also be downloaded through a centralized PCE server to 179 each network devices along the path while leveraging the existing PCE 180 technologies as much as possible. 182 3.1.1. PCECC for MPLS/SR-MPLS 184 [I-D.ietf-pce-pcep-extension-for-pce-controller] describe 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 of the routers that it controls as 192 described in section 3.1.2. of [RFC8283]. A mechanism for a PCC to 193 inform the PCE of such a label space to control is needed within 194 PCEP. 196 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 197 allow a stateful PCE to compute, update or initiate SR-TE paths. 198 [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the 199 mechanism for PCECC to allocate and provision the node/prefix/ 200 adjacency label (SID) via PCEP. To make such allocation, PCE needs 201 to be aware of the label space from Segment Routing Global Block 202 (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node 203 that it controls. A mechanism for a PCC to inform the PCE of such a 204 label space to control is needed within PCEP. The full SRGB/SRLB of 205 a node could be learned via existing IGP or BGP-LS mechanism. 207 3.1.2. PCECC for SRv6 209 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] describes the 210 mechanism for PCECC to allocate and provision the SRv6 SID via PCEP. 211 An SRv6 SID is represented as LOC:FUNCT 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. Therefore, a 227 PCE needs to obtain the authority and control to allocate Binding SID 228 actively from the PCC's label space as described in above use case. 230 4. Overview 232 During PCEP Initialization Phase, Open messages are exchanged between 233 PCCs and PCEs. The OPEN object may also contain a set of TLVs used 234 to convey capabilities in the Open message. The ID in this document, 235 could be a MPLS label, SRv6 Function ID or any other future ID space 236 for PCE to control and allocate from. A PCC can include a 237 corresponding ID-CONTROL-SPACE TLVs in the OPEN Object to inform the 238 corresponding ID space information that it wants the PCE to control. 239 This TLV MUST NOT be included by the PCE and MUST be ignored on 240 receipt by a PCC. This is an optional TLV, the PCE could be aware of 241 the ID space from some other means outside of PCEP. 243 For delegating multiple types of ID space, multiple TLVs 244 corresponding to each ID type MUST be included in a Open message. 245 The ID type can be MPLS label or other ID. The following ID-CONTROL- 246 SPACE TLV is defined in this document - 248 o LABEL-CONTROL-SPACE - for MPLS Labels (including for SR-MPLS) 250 o FUNCTION-ID-CONTROL-SPACE - for SRv6 SID Function ID 252 The procedure of ID space control to PCE is shown below: 254 +-+-+ +-+-+ 255 |PCC| |PCE| 256 +-+-+ +-+-+ 257 | | 258 | Open msg (LABEL-CONTROL-SPACE,etc) | 259 | | 260 |-------- | 261 | \ Open msg | 262 | \ -----------------------------| 263 | \/ | 264 | /\ | 265 | / ---------------------------->| 266 | / | 267 |<------ Keepalive | 268 | ----------------------------| 269 |Keepalive / | 270 |-------- / | 271 | \/ | 272 | /\ | 273 |<------ ------------------------------>| 274 | | 276 Figure 1: ID space control to PCE 278 If the ID space control procedure is successful, the PCE will return 279 a KeepAlive message to the PCC. If there is any error in processing 280 the corresponding TLV, an Error (PCErr) message will be sent to the 281 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 282 value=TBD (ID space control failure). 284 After this process, a stateful PCE can learn the PCE controlled ID 285 spaces of a node (PCC) under its control. A PCE can then allocate 286 IDs within the control ID space. For example, a PCE can actively 287 allocate labels and download forwarding instructions for the PCECC 288 LSP as described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 289 A PCE can also allocate labels from SRGB/SRLB for PCECC-SR 290 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The full SRGB/SRLB 291 of a node could be learned via existing IGP or BGP-LS mechanism. 293 5. Objects 295 5.1. Open Object 297 For advertising the PCE controlled ID space to a PCE, this document 298 defines several TLVs within the Open object. 300 5.1.1. LABEL-CONTROL-SPACE TLV 302 For a PCC to inform the label space under the PCE control, this 303 document defines a new LABEL-CONTROL-SPACE TLV. 305 The LABEL-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 306 object, and its format is shown in the following figure: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type=TBA | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Block | Flags |A| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Start (1) | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Range (1) | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ... | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | ... | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Start (n) | Reserved | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Range (n) | Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: LABEL-CONTROL-SPACE TLV 330 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 331 has a variable value. 333 Block(8 bits): the number of ID blocks. The range of a block is 334 described by a start field and a range field. 336 Flags (24 bits): Following flags are currently defined 338 o A-flag: All space flag, set when all the label space is delegated 339 to a PCE. When A-flag is set, the pair of Start and End SHOULD 340 NOT appear unless the PCC needs to notify the entire ID space to a 341 PCE. 343 The unassigned bits of Flags field MUST be set to 0 on transmission 344 and MUST be ignored on receipt. 346 Start(i) (24 bits): indicates the beginning of the label block i. 348 Range(i) (24 bits): indicates the range of the label block i. 350 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on 351 reception. 353 LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open 354 Message. On receipt, only the first instance is processed and others 355 MUST be ignored. 357 A stateful PCE can actively allocate labels and download forwarding 358 instructions for the PCECC LSP as described in 359 [I-D.ietf-pce-pcep-extension-for-pce-controller]. A PCE can also 360 allocate labels from SRGB/SRLB for PCECC-SR 361 [I-D.zhao-pce-pcep-extension-pce-controller-sr] and Binding Segments 362 can be selected for the PCE controlled space. 364 5.1.2. FUNCT-ID-CONTROL-SPACE TLV 366 For a PCC to inform the SRv6 SID Function ID space under the PCE 367 control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV. 369 The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 370 object, and its format is shown in the following figure: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type=TBA | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Block | Flags |L|A| 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 | Start (1) | 381 | | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | Range (1) | 386 | | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | ...... | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 | Start (n) | 393 | | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 | Range (n) | 398 | | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Loc Size | Locator (variable)... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 406 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 407 has a variable value. 409 Block(8 bits): the number of ID blocks. The range of a block is 410 described by a start field and a range field. 412 Flags (24 bits): Following flags are currently defined 414 o A-flag: All space flag, set when all the Function ID space is 415 delegated to a PCE. When A-flag is set, the pair of Start and End 416 SHOULD NOT appear unless the PCC needs to notify the entire ID 417 space to a PCE. 419 o L-flag: Locator flag, set when the locator information is included 420 in this TLV. If L-flag is unset, Loc Size and variable Locator 421 field will not be included in this TLV, and the ID spaces are 422 applicable to all Locators. 424 The unassigned bits of Flags field MUST be set to 0 on transmission 425 and MUST be ignored on receipt. 427 Start(i) (128 bits): indicates the beginning of the Function ID block 428 i. 430 Range(i) (128 bits): indicates the range of the Function ID block i. 432 Loc size(8 bits): indicates the bit length of a Locator. Appears 433 only when the L-flag is set. 435 Locator (variable length): the value of a Locator. The Function ID 436 spaces specified in this TLV are associated with this locator. 438 As per [RFC5440], the value portion of the PCEP TLV needs to be 439 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 440 trailing zeros to a 4-byte boundary. 442 Multiple FUNCT-ID-CONTROL-SPACE TLVs can be included in a OPEN 443 message to specify the Function ID space of locators. 445 A stateful PCE can actively allocate SRv6 SID and download forwarding 446 instructions for the PCECC SRv6 path as described in 447 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 449 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 450 to be known at PCE and FUNCT is allocated from the PCE controlled 451 Function ID block. 453 6. Other Considerations 455 In case of multiple PCEs, a PCC MAY decide to give control over 456 different ID space to each instance of the PCE. In case a PCC 457 includes the same ID space to multiple PCEs, the PCE SHOULD use 458 synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to 459 avoid allocating the same ID. 461 The PCE would allocated ID from the PCE controlled ID space. The PCC 462 would not allocated ID by itself from this space as long as it has an 463 active PCEP session to a PCE to which it has given control over the 464 ID space. 466 Note that if there is any change in the ID space, the PCC MUST bring 467 the session down and re-establish the session with new TLVs. During 468 state synchronization the PCE would need to consider the new ID space 469 into consideration and SHOULD re-establish the LSP/SR-paths if 470 needed. 472 The PCC can take control back of the ID space by closing the PCEP 473 session and not including the PCE Controlled ID space TLVs specified 474 in this document. 476 7. IANA Considerations 478 TBA. 480 8. Security Considerations 482 TBA. 484 9. Contributors 486 Dhruv Dhody 488 Huawei Technologies 490 Divyashree Techno Park, Whitefield 492 Bangalore, Karnataka 560066 494 India 496 EMail: dhruv.ietf@gmail.com 498 10. Acknowledgements 500 TBA. 502 11. References 504 11.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, 508 DOI 10.17487/RFC2119, March 1997, 509 . 511 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 512 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 513 DOI 10.17487/RFC5440, March 2009, 514 . 516 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 517 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 518 May 2017, . 520 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 521 Computation Element Communication Protocol (PCEP) 522 Extensions for Stateful PCE", RFC 8231, 523 DOI 10.17487/RFC8231, September 2017, 524 . 526 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 527 Computation Element Communication Protocol (PCEP) 528 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 529 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 530 . 532 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 533 Architecture for Use of PCE and the PCE Communication 534 Protocol (PCEP) in a Network with Central Control", 535 RFC 8283, DOI 10.17487/RFC8283, December 2017, 536 . 538 11.2. Informative References 540 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 541 Element (PCE) Communication Protocol Generic 542 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 543 2006, . 545 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 546 Decraene, B., Litkowski, S., and R. Shakir, "Segment 547 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 548 July 2018, . 550 [I-D.ietf-pce-segment-routing] 551 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 552 and J. Hardwick, "PCEP Extensions for Segment Routing", 553 draft-ietf-pce-segment-routing-14 (work in progress), 554 October 2018. 556 [I-D.ietf-pce-pcep-extension-for-pce-controller] 557 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 558 and C. Zhou, "PCEP Procedures and Protocol Extensions for 559 Using PCE as a Central Controller (PCECC) of LSPs", draft- 560 ietf-pce-pcep-extension-for-pce-controller-00 (work in 561 progress), November 2018. 563 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 564 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 565 and C. Zhou, "PCEP Procedures and Protocol Extensions for 566 Using PCE as a Central Controller (PCECC) of SR-LSPs", 567 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 568 in progress), June 2018. 570 [I-D.litkowski-pce-state-sync] 571 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 572 Stateful Path Computation Element communication 573 procedures", draft-litkowski-pce-state-sync-04 (work in 574 progress), October 2018. 576 [I-D.ietf-spring-segment-routing-policy] 577 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 578 bogdanov@google.com, b., and P. Mattes, "Segment Routing 579 Policy Architecture", draft-ietf-spring-segment-routing- 580 policy-02 (work in progress), October 2018. 582 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 583 Dhody, D. and Z. Li, "PCEP Procedures and Protocol 584 Extensions for Using PCE as a Central Controller (PCECC) 585 for SRv6", draft-dhody-pce-pcep-extension-pce-controller- 586 srv6-00 (work in progress), October 2018. 588 Authors' Addresses 590 Cheng Li 591 Huawei Technologies 592 Huawei Campus, No. 156 Beiqing Rd. 593 Beijing 100095 594 China 596 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 613 Zhenbin Li 614 Huawei Technologies 615 Huawei Campus, No. 156 Beiqing Rd. 616 Beijing 100095 617 China 619 EMail: lizhenbin@huawei.com 621 Aijun Wang 622 China Telecom 623 Beiqijia Town, 624 Beijing, Changping District 102209 625 China 627 EMail: wangaj.bri@chinatelecom.cn