idnits 2.17.1 draft-li-pce-controlled-id-space-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 (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-08 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-10 == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-00 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-05 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-05 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). 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: August 26, 2021 A. Wang 6 China Telecom 7 W. Cheng 8 China Mobile 9 C. Zhou 10 HPE 11 February 22, 2021 13 PCE Controlled ID Space 14 draft-li-pce-controlled-id-space-08 16 Abstract 18 The Path Computation Element Communication Protocol (PCEP) provides a 19 mechanisms for the 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, PCE can be used for computing paths 24 in the 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 remove PCE-initiated LSPs by itself. A PCE-based Central 30 Controller (PCECC) simplify the processing of a distributed control 31 plane by integrating with elements of Software-Defined Networking 32 (SDN). 34 In some use cases, such as PCECC or Binding Segment Identifier (SID) 35 for Segment Routing (SR), there are requirements for a stateful PCE 36 to make allocation of labels, SIDs, etc. These use cases require PCE 37 aware of various identifier spaces from where to make allocations on 38 behalf of a PCC. This document describes a mechanism for a PCC to 39 inform the PCE of the identifier space set aside for the PCE control 40 via PCEP. The identifier could be an MPLS label, a SID or any other 41 to-be-defined identifier that can be allocated by a PCE. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on August 26, 2021. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 80 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 82 3.1.1. PCECC for MPLS/SR-MPLS . . . . . . . . . . . . . . . 4 83 3.1.2. PCECC for SRv6 . . . . . . . . . . . . . . . . . . . 5 84 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 85 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 88 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 89 5.1.2. FUNCT-ID-CONTROL-SPACE TLV . . . . . . . . . . . . . 9 90 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 12 93 7.2. LABEL-CONTROL-SPACE TLV's Flag field . . . . . . . . . . 12 94 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field . . . . . . . . . 13 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 99 10.2. Informative References . . . . . . . . . . . . . . . . . 15 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 [RFC5440] defines the stateless Path Computation Element 106 Communication Protocol (PCEP) for the Path Computation Elements 107 (PCEs) to perform path computation in response to Path Computation 108 Clients (PCCs) requests. For supporting stateful operations, 109 [RFC8231] specifies a set of extensions to PCEP to enable stateful 110 control of LSPs within and across PCEP sessions in compliance with 111 [RFC4657]. Furthermore, [RFC8281] describes the setup, maintenance, 112 and teardown of PCE-initiated LSPs under the stateful PCE model, 113 without the need for local configuration on the PCC, thus allowing 114 for a dynamic network that is centrally controlled and deployed. 116 [RFC8283] introduces the architecture for PCE as a central 117 controller, it examines the motivations and applicability for PCEP as 118 a control protocol in this environment, and introduces the 119 implications for the protocol. Also, 120 [I-D.ietf-pce-pcep-extension-for-pce-controller] specifies the 121 procedures and PCEP extensions for using the PCE as a Central 122 Controller (PCECC), where LSPs are calculated/set up/initiated and 123 label forwarding entries are downloaded through extending PCEP. 124 However, the document assumes that label range to be used by a PCE is 125 known and set on both PCEP peers. This extension adds the capability 126 to advertise the label range via a PCEP extension. 128 Similarly, [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies 129 the procedures and PCEP extensions when a PCE-based controller is 130 also responsible for configuring the forwarding actions on the 131 routers (SR SID distribution in this case), in addition to computing 132 the paths for packet flows in a segment routing network and telling 133 the edge routers what instructions to attach to packets as they enter 134 the network. However, the document assumes that label range to be 135 used by a PCE is known and set on both PCEP peers. This extension 136 adds the capability to advertise the range (from SRGB or SRLB of the 137 node) via a PCEP extension. 139 In addition, [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 140 specifies the procedures and PCEP extensions of PCECC for SRv6. An 141 SRv6 SID is represented as LOC:FUNCT 142 ([I-D.ietf-spring-srv6-network-programming]) where LOC is the L most 143 significant bits and FUNCT is the 128-L least significant bits. The 144 FUNCT part of the SID is an opaque identification of a local function 145 bound to the SID. This extension adds the capability to advertise 146 the range of Function ID (FUNCT part) via a PCEP extension. 148 Once the PCC/node has given control over an ID space (for example 149 labels), the PCC/node MUST NOT allocate the ID from this ID space. 150 For example, a PCC/node MUST NOT use this labels from the PCE 151 controlled label space to make allocation for VPN Prefix distributed 152 via BGP or labels used for LDP/RSVP-TE signalling. This is done to 153 make sure that the PCE control over ID space does not conflict with 154 the existing node allocation. 156 The use case are described in Section 3. The ID space range 157 information can be advertised via the TLVs in the Open message. The 158 detailed procedures are described in Section 4, and the TLV format is 159 specified in Section 5. 161 2. Terminology 163 This memo makes use of the terms defined in [RFC5440], [RFC8231], 164 [RFC8283] and [RFC8402]. 166 2.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 3. Use cases 176 3.1. PCE-based Central Control 178 A PCE-based Central Controller (PCECC) can simplify the processing of 179 a distributed control plane by integrating with elements of SDN. 180 Thus, the LSP/SR path can be calculated/set up/initiated and the 181 label/SID forwarding entries can also be downloaded through a 182 centralized PCE server to each network devices along the path while 183 leveraging the existing PCE technologies as much as possible. 185 3.1.1. PCECC for MPLS/SR-MPLS 187 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes a mode 188 where LSPs are provisioned as explicit label instructions at each hop 189 on the end-to-end path. Each router along the path must be told what 190 label forwarding instructions to program and what resources to 191 reserve. The controller uses PCEP to communicate with each router 192 along the path of the end-to-end LSP. For this to work, the PCE- 193 based controller will take responsibility for managing some part of 194 the MPLS label space for each router that it controls as described in 195 section 3.1.2. of [RFC8283]. A mechanism for a PCC to inform the PCE 196 of such a label space to control is needed within PCEP. 198 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 199 compute, update or initiate SR-TE paths. 200 [I-D.ietf-pce-pcep-extension-pce-controller-sr] describes the 201 mechanism for PCECC to allocate and distribute the node/prefix/ 202 adjacency label (SID) via PCEP. To make such allocation, PCE needs 203 to be aware of the label space from Segment Routing Global Block 204 (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node 205 that it can control. A mechanism for a PCC to inform the PCE of such 206 label space to control is needed within PCEP. The full SRGB/SRLB of 207 a node could be learned via existing IGP or BGP-LS mechanism. 209 3.1.2. PCECC for SRv6 211 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] describes the 212 mechanism for PCECC to allocate and provision the SRv6 SID via PCEP. 213 An SRv6 SID is represented as LOC:FUNCT 214 ([I-D.ietf-spring-srv6-network-programming]) where LOC is the L most 215 significant bits and FUNCT is the 128-L least significant bits. The 216 FUNCT part of the SID is an opaque identification of a local function 217 bound to the SID. To make such allocation, PCE needs to be aware of 218 the Function ID space (FUNCT part) of the node that it controls. A 219 mechanism for a PCC to inform the PCE of such a Function ID space to 220 control is needed within PCEP. 222 3.2. Binding SID Allocation 224 The headend of an SR Policy binds a Binding SID (BSID) 225 [I-D.ietf-pce-binding-label-sid] to its policy 226 [I-D.ietf-spring-segment-routing-policy]. The instantiation of which 227 may involve a list of SIDs. The Binding SID can be allocated by the 228 node as described in [I-D.ietf-pce-binding-label-sid], but there is 229 an inherent advantage in the Binding SID to be allocated by a PCE to 230 allow SR policies to be dynamically created, updated according to the 231 network status and operations. This is described in 232 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Therefore, a PCE 233 needs to obtain the authority and control to allocate Binding SID 234 actively from the PCC's label space as described in above use case. 236 This is applicable for both SR-MPLS and SRv6 BSID. 238 4. Overview 240 During PCEP Initialization Phase, Open messages are exchanged between 241 the PCCs and the PCEs. The OPEN object may also contain a set of 242 TLVs used to convey the capabilities in the Open message. The term 243 'ID' in this document, could be a MPLS label, SRv6 Function ID or any 244 other future ID space for PCE to control and allocate from. A PCC 245 can include a corresponding ID-CONTROL-SPACE TLVs in the OPEN Object 246 to inform the corresponding ID space information that it wants the 247 PCE to control. This TLV MUST NOT be included by the PCE and MUST be 248 ignored on receipt by a PCC. This is an optional TLV, the PCE could 249 be aware of the ID space from some other means outside of PCEP. 251 For delegating multiple types of ID space, multiple TLVs 252 corresponding to each ID type MUST be included in an Open message. 253 The ID type can be MPLS label or other type of ID. The following ID- 254 CONTROL-SPACE TLV is defined in this document - 256 o LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS) 258 o FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID 260 The procedure of ID space control to PCE is shown below: 262 +-+-+ +-+-+ 263 |PCC| |PCE| 264 +-+-+ +-+-+ 265 | | 266 | Open msg (LABEL-CONTROL-SPACE,etc) | 267 | | 268 |-------- | 269 | \ Open msg | 270 | \ -----------------------------| 271 | \/ | 272 | /\ | 273 | / ---------------------------->| 274 | / | 275 |<------ Keepalive | 276 | ----------------------------| 277 |Keepalive / | 278 |-------- / | 279 | \/ | 280 | /\ | 281 |<------ ------------------------------>| 282 | | 284 Figure 1: ID space control to PCE 286 If the ID space control procedure is successful, the PCE will return 287 a KeepAlive message to the PCC. If there is any error in processing 288 the corresponding TLV, an Error (PCErr) message will be sent to the 289 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 290 value=TBD (ID space control failure). 292 After this process, a stateful PCE can learn the PCE-controlled ID 293 spaces of a node (PCC) under its control. A PCE can then allocate 294 IDs within the controlled-ID space. For example, a PCE can actively 295 allocate labels and download forwarding instructions for the PCECC 296 LSP as described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. 297 A PCE can also allocate labels from the PCE controlled portion of the 298 SRGB/SRLB for PCECC-SR 299 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. The full SRGB/SRLB 300 of a node could be learned via existing IGP or BGP-LS mechanism. 302 The procedure for handling the FUNCTION-ID-CONTROL-SPACE TLV is same 303 as above. 305 5. Objects 307 5.1. Open Object 309 For advertising the PCE-controlled ID space to a PCE, this document 310 defines several TLVs within the OPEN object. 312 5.1.1. LABEL-CONTROL-SPACE TLV 314 For a PCC to inform the label space under the PCE control, this 315 document defines a new LABEL-CONTROL-SPACE TLV. 317 The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object, 318 and its format is shown in the following figure: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type=TBD1 | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Block | Flags | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Start (1) | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Range (1) | Reserved | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ... | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Start (n) | Reserved | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Range (n) | Reserved | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: LABEL-CONTROL-SPACE TLV 342 The type (16 bits) of the TLV is TBD1. The length field (16 bits) 343 and has a variable value. 345 Block(8 bits): the number of ID blocks. The range of a block is 346 described by a start field and a range field. 348 Flags (24 bits): No flag is currently defined. The unassigned bits 349 of Flags field MUST be set to 0 on transmission and MUST be ignored 350 on receipt. 352 Start(i) (24 bits): indicates the beginning of the label block i. 354 Range(i) (24 bits): indicates the range of the label block i. 356 Reserved: MUST be set to 0 on transmission and MUST be ignored on 357 reception. 359 LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open 360 Message. On receipt, only the first instance is processed and others 361 MUST be ignored. 363 A stateful PCE can actively allocate labels and download forwarding 364 instructions for the PCECC LSP as described in 365 [I-D.ietf-pce-pcep-extension-for-pce-controller]. A PCE can also 366 allocate labels from SRGB/SRLB for PCECC-SR 368 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. The Binding 369 Segments can also be selected for the PCE controlled space 370 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 372 5.1.2. FUNCT-ID-CONTROL-SPACE TLV 374 For a PCC to inform the SRv6 SID Function ID space under the PCE 375 control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV. 377 The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 378 object, and its format is shown in the following figure: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type=TBD2 | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Block | Flags |L| 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | SID | 388 | Structure | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | Start (1) | 392 | | 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 | Range (1) | 397 | | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | ...... | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | Start (n) | 404 | | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 | Range (n) | 409 | | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Loc Size | Locator (variable)... | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 417 The type (16 bits) of the TLV is TBD2. The length field (16 bits) 418 and has a variable value. 420 Block(8 bits): the number of ID blocks. The range of a block is 421 described by a start field and a range field. 423 Flags (24 bits): Following flags are currently defined 425 o L-flag: Locator flag, set when the locator information is included 426 in this TLV. If L-flag is unset, Loc Size and variable Locator 427 field MUST NOT be included in this TLV, and the ID spaces are 428 applicable to all Locators. 430 The unassigned bits of Flags field MUST be set to 0 on transmission 431 and MUST be ignored on receipt. 433 SID Structure: 64-bit field formatted as per "SID Structure" in 434 [I-D.ietf-pce-segment-routing-ipv6]. 436 Start(i) (128 bits): indicates the beginning of the Function ID block 437 i. 439 Range(i) (128 bits): indicates the range of the Function ID block i. 441 Loc size(8 bits): indicates the bit length of a Locator. Appears 442 only when the L-flag is set. 444 Locator (variable length): the value of a Locator. The Function ID 445 spaces specified in this TLV are associated with this locator. 447 As per [RFC5440], the value portion of the PCEP TLV needs to be 448 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 449 trailing zeros to a 4-byte boundary. 451 Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN object 452 to specify Function ID space specefic to each locator. 454 A stateful PCE can actively allocate SRv6 SID and download SIDs for 455 the PCECC-SRv6 as described in 456 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 458 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 459 to be known at PCE and FUNCT is allocated from the PCE controlled 460 Function ID block. 462 6. Other Considerations 464 In case of multiple PCEs, a PCC MAY decide to give control over 465 different ID space to each instance of the PCE. In case a PCC 466 includes the same ID space to multiple PCEs, the PCE MUST use 467 synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to 468 avoid allocating the same ID. 470 The PCE would allocate ID from the PCE controlled ID space. The PCC 471 would not allocate ID by itself from this space as long as it has an 472 active PCEP session to a PCE to which it has given control over the 473 ID space. 475 Note that if there is any change in the ID space, the PCC MUST bring 476 the session down and re-establish the session with new TLVs. During 477 state synchronization the PCE would need to consider the new ID space 478 into consideration and SHOULD re-establish the LSP/SR-paths if 479 needed. 481 The PCC can regain control of the ID space by closing the PCEP 482 session and require new session without ID space TLVs specified in 483 this document. 485 7. IANA Considerations 487 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 488 registry. This document requests IANA actions to allocate code 489 points for the protocol elements defined in this document. 491 7.1. PCEP TLV Type Indicators 493 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 494 is requested to make an assignment from this subregistry as follows: 496 Value | Meaning | Reference 497 --------+------------------------------+------------- 498 TBD1 | LABEL-CONTROL-SPACE TLV | [This.I-D] 499 TBD2 | FUNCT-ID-CONTROL-SPACE TLV | [This.I-D] 501 7.2. LABEL-CONTROL-SPACE TLV's Flag field 503 This document defines the LABEL-CONTROL-SPACE TLV and requests that 504 IANA to create a new sub-registry to manage the value of the LABEL- 505 CONTROL-SPACE TLV's 24-bits Flag field. New values are to be 506 assigned by Standards Action [RFC8126]. Each bit should be tracked 507 with the following qualities: 509 o Bit number (counting from bit 0 as the most significant bit) 511 o Capability description 513 o Defining RFC 515 Currently, there is no allocation in this registry. 517 Bit | Name | Reference 518 --------+------------------------------+------------- 519 0-23 | Unassigned | [This.I-D] 521 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field 523 This document defines the FUNCT-ID-CONTROL-SPACE TLV and requests 524 that IANA to create a new sub-registry to manage the value of the 525 FUNCT-ID-CONTROL-SPACE TLV's 24-bits Flag field. New values are to 526 be assigned by Standards Action [RFC8126]. Each bit should be 527 tracked with the following qualities: 529 o Bit number (counting from bit 0 as the most significant bit) 531 o Capability description 533 o Defining RFC 535 Currently, there is no allocation in this registry. 537 Bit | Name | Reference 538 --------+------------------------------+------------- 539 23 | L-Bit | [This.I-D] 540 0-22 | Unassigned | [This.I-D] 542 8. Security Considerations 544 The security considerations described in 545 [I-D.ietf-pce-pcep-extension-for-pce-controller], 546 [I-D.ietf-pce-pcep-extension-pce-controller-sr], and 547 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] and apply to the 548 extensions described in this document. 550 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 551 be activated on authenticated and encrypted sessions across PCEs and 552 PCCs belonging to the same administrative authority, using Transport 553 Layer Security (TLS) [RFC8253] as per the recommendations and best 554 current practices in [RFC7525] (unless explicitly set aside in 555 [RFC8253]). 557 9. Acknowledgements 559 TBD. 561 10. References 563 10.1. Normative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 571 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 572 DOI 10.17487/RFC5440, March 2009, 573 . 575 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 576 Writing an IANA Considerations Section in RFCs", BCP 26, 577 RFC 8126, DOI 10.17487/RFC8126, June 2017, 578 . 580 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 581 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 582 May 2017, . 584 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 585 Computation Element Communication Protocol (PCEP) 586 Extensions for Stateful PCE", RFC 8231, 587 DOI 10.17487/RFC8231, September 2017, 588 . 590 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 591 Computation Element Communication Protocol (PCEP) 592 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 593 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 594 . 596 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 597 "PCEPS: Usage of TLS to Provide a Secure Transport for the 598 Path Computation Element Communication Protocol (PCEP)", 599 RFC 8253, DOI 10.17487/RFC8253, October 2017, 600 . 602 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 603 Architecture for Use of PCE and the PCE Communication 604 Protocol (PCEP) in a Network with Central Control", 605 RFC 8283, DOI 10.17487/RFC8283, December 2017, 606 . 608 [I-D.ietf-pce-segment-routing-ipv6] 609 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 610 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 611 Routing leveraging the IPv6 data plane", draft-ietf-pce- 612 segment-routing-ipv6-08 (work in progress), November 2020. 614 10.2. Informative References 616 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 617 Element (PCE) Communication Protocol Generic 618 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 619 2006, . 621 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 622 "Recommendations for Secure Use of Transport Layer 623 Security (TLS) and Datagram Transport Layer Security 624 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 625 2015, . 627 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 628 Decraene, B., Litkowski, S., and R. Shakir, "Segment 629 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 630 July 2018, . 632 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 633 and J. Hardwick, "Path Computation Element Communication 634 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 635 DOI 10.17487/RFC8664, December 2019, 636 . 638 [I-D.ietf-pce-pcep-extension-for-pce-controller] 639 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 640 Procedures and Protocol Extensions for Using PCE as a 641 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 642 extension-for-pce-controller-10 (work in progress), 643 January 2021. 645 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 646 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 647 Procedures and Protocol Extensions for Using PCE as a 648 Central Controller (PCECC) for Segment Routing (SR) MPLS 649 Segment Identifier (SID) Allocation and Distribution.", 650 draft-ietf-pce-pcep-extension-pce-controller-sr-00 (work 651 in progress), December 2020. 653 [I-D.litkowski-pce-state-sync] 654 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 655 Stateful Path Computation Element (PCE) Communication 656 Procedures.", draft-litkowski-pce-state-sync-09 (work in 657 progress), November 2020. 659 [I-D.ietf-spring-segment-routing-policy] 660 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 661 P. Mattes, "Segment Routing Policy Architecture", draft- 662 ietf-spring-segment-routing-policy-09 (work in progress), 663 November 2020. 665 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 666 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 667 and Protocol Extensions for Using PCE as a Central 668 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 669 extension-pce-controller-srv6-05 (work in progress), 670 November 2020. 672 [I-D.ietf-spring-srv6-network-programming] 673 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 674 Matsushima, S., and Z. Li, "SRv6 Network Programming", 675 draft-ietf-spring-srv6-network-programming-28 (work in 676 progress), December 2020. 678 [I-D.ietf-pce-binding-label-sid] 679 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 680 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 681 in PCE-based Networks.", draft-ietf-pce-binding-label- 682 sid-05 (work in progress), October 2020. 684 Appendix A. Contributors 686 Dhruv Dhody 687 Huawei Technologies 688 Divyashree Techno Park, Whitefield 689 Bangalore, Karnataka 560066 690 India 692 EMail: dhruv.ietf@gmail.com 694 Zhenbin Li 695 Huawei Technologies 696 Huawei Campus, No. 156 Beiqing Rd. 697 Beijing 100095 698 China 700 EMail: lizhenbin@huawei.com 702 Jie Dong 703 Huawei Technologies 704 Huawei Campus, No. 156 Beiqing Rd. 705 Beijing 100095 706 China 708 EMail: jie.dong@huawei.com 710 Authors' Addresses 712 Cheng Li 713 Huawei Technologies 714 Huawei Campus, No. 156 Beiqing Rd. 715 Beijing 100095 716 China 718 EMail: c.l@huawei.com 720 Mach(Guoyi) Chen 721 Huawei Technologies 722 Huawei Campus, No. 156 Beiqing Rd. 723 Beijing 100095 724 China 726 EMail: Mach.chen@huawei.com 727 Aijun Wang 728 China Telecom 729 Beiqijia Town, 730 Beijing, Changping District 102209 731 China 733 EMail: wangaj3@chinatelecom.cn 735 Weiqiang Cheng 736 China Mobile 738 EMail: chengweiqiang@chinamobile.com 740 Chao Zhou 741 HPE 743 EMail: chaozhou_us@yahoo.com