idnits 2.17.1 draft-li-pce-controlled-id-space-09.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 (August 23, 2021) is 969 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-09 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-02 == Outdated reference: A later version (-07) exists of draft-ietf-pce-state-sync-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-10 Summary: 0 errors (**), 0 flaws (~~), 7 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: February 24, 2022 A. Wang 6 China Telecom 7 W. Cheng 8 China Mobile 9 C. Zhou 10 HPE 11 August 23, 2021 13 PCE Controlled ID Space 14 draft-li-pce-controlled-id-space-09 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 February 24, 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 11 92 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 11 93 7.2. LABEL-CONTROL-SPACE TLV's Flag field . . . . . . . . . . 11 94 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field . . . . . . . . . 12 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 99 10.2. Informative References . . . . . . . . . . . . . . . . . 14 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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, [RFC9050] specifies the 120 procedures and PCEP extensions for using the PCE as a Central 121 Controller (PCECC), where LSPs are calculated/set up/initiated and 122 label forwarding entries are downloaded through extending PCEP. 123 However, the document assumes that label range to be used by a PCE is 124 known and set on both PCEP peers. This extension adds the capability 125 to advertise the label range via a PCEP extension. 127 Similarly, [RFC9050] specifies the procedures and PCEP extensions 128 when a PCE-based controller is also responsible for configuring the 129 forwarding actions on the routers (SR SID distribution in this case), 130 in addition to computing the paths for packet flows in a segment 131 routing network and telling the edge routers what instructions to 132 attach to packets as they enter the network. However, the document 133 assumes that label range to be used by a PCE is known and set on both 134 PCEP peers. This extension adds the capability to advertise the 135 range (from SRGB or 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 extensions of PCECC for SRv6. An 139 SRv6 SID is represented as LOC:FUNCT ([RFC8986]) 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 TLV format is 156 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/set up/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 [RFC9050] describes a mode where LSPs are provisioned as explicit 185 label instructions at each hop on the end-to-end path. Each router 186 along the path must be told what label forwarding instructions to 187 program and what resources to reserve. The controller uses PCEP to 188 communicate with each router along the path of the end-to-end LSP. 189 For this to work, the PCE-based controller will take responsibility 190 for managing some part of the MPLS label space for each router that 191 it controls as described in section 3.1.2. of [RFC8283]. A mechanism 192 for a PCC to inform the PCE of such a label space to control is 193 needed within PCEP. 195 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 196 compute, update or initiate SR-TE paths. [RFC9050] describes the 197 mechanism for PCECC to allocate and distribute 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 can control. 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 ([RFC8986]) where LOC is the 210 L most significant bits and FUNCT is the 128-L least significant 211 bits. The FUNCT part of the SID is an opaque identification of a 212 local function bound to the SID. To make such allocation, PCE needs 213 to be aware of the Function ID space (FUNCT part) of the node that it 214 controls. A mechanism for a PCC to inform the PCE of such a Function 215 ID space to control is needed within PCEP. 217 3.2. Binding SID Allocation 219 The headend of an SR Policy binds a Binding SID (BSID) 220 [I-D.ietf-pce-binding-label-sid] to its policy 221 [I-D.ietf-spring-segment-routing-policy]. The instantiation of which 222 may involve a list of SIDs. The Binding SID can be allocated by the 223 node as described in [I-D.ietf-pce-binding-label-sid], but there is 224 an inherent advantage in the Binding SID to be allocated by a PCE to 225 allow SR policies to be dynamically created, updated according to the 226 network status and operations. This is described in [RFC9050]. 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 This is applicable for both SR-MPLS and SRv6 BSID. 233 4. Overview 235 During PCEP Initialization Phase, Open messages are exchanged between 236 the PCCs and the PCEs. The OPEN object may also contain a set of 237 TLVs used to convey the capabilities in the Open message. The term 238 'ID' in this document, could be a MPLS label, SRv6 Function ID or any 239 other future ID space for PCE to control and allocate from. A PCC 240 can include a corresponding ID-CONTROL-SPACE TLVs in the OPEN Object 241 to inform the corresponding ID space information that it wants the 242 PCE to control. This TLV MUST NOT be included by the PCE and MUST be 243 ignored on receipt by a PCC. This is an optional TLV, the PCE could 244 be aware of the ID space from some other means outside of PCEP. 246 For delegating multiple types of ID space, multiple TLVs 247 corresponding to each ID type MUST be included in an Open message. 248 The ID type can be MPLS label or other type of ID. The following ID- 249 CONTROL-SPACE TLV is defined in this document - 251 o LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS) 253 o FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID 255 The procedure of ID space control to PCE is shown below: 257 +-+-+ +-+-+ 258 |PCC| |PCE| 259 +-+-+ +-+-+ 260 | | 261 | Open msg (LABEL-CONTROL-SPACE,etc) | 262 | | 263 |-------- | 264 | \ Open msg | 265 | \ -----------------------------| 266 | \/ | 267 | /\ | 268 | / ---------------------------->| 269 | / | 270 |<------ Keepalive | 271 | ----------------------------| 272 |Keepalive / | 273 |-------- / | 274 | \/ | 275 | /\ | 276 |<------ ------------------------------>| 277 | | 279 Figure 1: ID space control to PCE 281 If the ID space control procedure is successful, the PCE will return 282 a KeepAlive message to the PCC. If there is any error in processing 283 the corresponding TLV, an Error (PCErr) message will be sent to the 284 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 285 value=TBD (ID space control failure). 287 After this process, a stateful PCE can learn the PCE-controlled ID 288 spaces of a node (PCC) under its control. A PCE can then allocate 289 IDs within the controlled-ID space. For example, a PCE can actively 290 allocate labels and download forwarding instructions for the PCECC 291 LSP as described in [RFC9050]. A PCE can also allocate labels from 292 the PCE controlled portion of the SRGB/SRLB for PCECC-SR [RFC9050]. 293 The full SRGB/SRLB of a node could be learned via existing IGP or 294 BGP-LS mechanism. 296 The procedure for handling the FUNCTION-ID-CONTROL-SPACE TLV is same 297 as above. 299 5. Objects 301 5.1. Open Object 303 For advertising the PCE-controlled ID space to a PCE, this document 304 defines several TLVs within the OPEN object. 306 5.1.1. LABEL-CONTROL-SPACE TLV 308 For a PCC to inform the label space under the PCE control, this 309 document defines a new LABEL-CONTROL-SPACE TLV. 311 The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object, 312 and its format is shown in the following figure: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type=TBD1 | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Block | Flags | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Start (1) | Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Range (1) | Reserved | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | ... | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Start (n) | Reserved | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Range (n) | Reserved | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 2: LABEL-CONTROL-SPACE TLV 336 The type (16 bits) of the TLV is TBD1. The length field (16 bits) 337 and has a variable value. 339 Block(8 bits): the number of ID blocks. The range of a block is 340 described by a start field and a range field. 342 Flags (24 bits): No flag is currently defined. The unassigned bits 343 of Flags field MUST be set to 0 on transmission and MUST be ignored 344 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: MUST 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 [RFC9050]. A PCE can 359 also allocate labels from SRGB/SRLB for PCECC-SR 361 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. The Binding 362 Segments can also be selected for the PCE controlled space [RFC9050]. 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=TBD2 | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Block | Flags |L| 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | SID | 380 | Structure | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Start (1) | 384 | | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | Range (1) | 389 | | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | ...... | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 | Start (n) | 396 | | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 | Range (n) | 401 | | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Loc Size | Locator (variable)... | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 409 The type (16 bits) of the TLV is TBD2. The length field (16 bits) 410 and has a variable value. 412 Block(8 bits): the number of ID blocks. The range of a block is 413 described by a start field and a range field. 415 Flags (24 bits): Following flags are currently defined 417 o L-flag: Locator flag, set when the locator information is included 418 in this TLV. If L-flag is unset, Loc Size and variable Locator 419 field MUST NOT be included in this TLV, and the ID spaces are 420 applicable to all Locators. 422 The unassigned bits of Flags field MUST be set to 0 on transmission 423 and MUST be ignored on receipt. 425 SID Structure: 64-bit field formatted as per "SID Structure" in 426 [I-D.ietf-pce-segment-routing-ipv6]. 428 Start(i) (128 bits): indicates the beginning of the Function ID block 429 i. 431 Range(i) (128 bits): indicates the range of the Function ID block i. 433 Loc size(8 bits): indicates the bit length of a Locator. Appears 434 only when the L-flag is set. 436 Locator (variable length): the value of a Locator. The Function ID 437 spaces specified in this TLV are associated with this locator. 439 As per [RFC5440], the value portion of the PCEP TLV needs to be 440 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 441 trailing zeros to a 4-byte boundary. 443 Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN object 444 to specify Function ID space specefic to each locator. 446 A stateful PCE can actively allocate SRv6 SID and download SIDs for 447 the PCECC-SRv6 as described in 448 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 450 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 451 to be known at PCE and FUNCT is allocated from the PCE controlled 452 Function ID block. 454 6. Other Considerations 456 In case of multiple PCEs, a PCC MAY decide to give control over 457 different ID space to each instance of the PCE. In case a PCC 458 includes the same ID space to multiple PCEs, the PCE MUST use 459 synchronization mechanism (such as [I-D.ietf-pce-state-sync]) to 460 avoid allocating the same ID. 462 The PCE would allocate ID from the PCE controlled ID space. The PCC 463 would not allocate ID by itself from this space as long as it has an 464 active PCEP session to a PCE to which it has given control over the 465 ID space. 467 Note that if there is any change in the ID space, the PCC MUST bring 468 the session down and re-establish the session with new TLVs. During 469 state synchronization the PCE would need to consider the new ID space 470 into consideration and SHOULD re-establish the LSP/SR-paths if 471 needed. 473 The PCC can regain control of the ID space by closing the PCEP 474 session and require new session without ID space TLVs specified in 475 this document. 477 7. IANA Considerations 479 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 480 registry. This document requests IANA actions to allocate code 481 points for the protocol elements defined in this document. 483 7.1. PCEP TLV Type Indicators 485 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 486 is requested to make an assignment from this subregistry as follows: 488 Value | Meaning | Reference 489 --------+------------------------------+------------- 490 TBD1 | LABEL-CONTROL-SPACE TLV | [This.I-D] 491 TBD2 | FUNCT-ID-CONTROL-SPACE TLV | [This.I-D] 493 7.2. LABEL-CONTROL-SPACE TLV's Flag field 495 This document defines the LABEL-CONTROL-SPACE TLV and requests that 496 IANA to create a new sub-registry to manage the value of the LABEL- 497 CONTROL-SPACE TLV's 24-bits Flag field. New values are to be 498 assigned by Standards Action [RFC8126]. Each bit should be tracked 499 with the following qualities: 501 o Bit number (counting from bit 0 as the most significant bit) 503 o Capability description 505 o Defining RFC 507 Currently, there is no allocation in this registry. 509 Bit | Name | Reference 510 --------+------------------------------+------------- 511 0-23 | Unassigned | [This.I-D] 513 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field 515 This document defines the FUNCT-ID-CONTROL-SPACE TLV and requests 516 that IANA to create a new sub-registry to manage the value of the 517 FUNCT-ID-CONTROL-SPACE TLV's 24-bits Flag field. New values are to 518 be assigned by Standards Action [RFC8126]. Each bit should be 519 tracked with the following qualities: 521 o Bit number (counting from bit 0 as the most significant bit) 523 o Capability description 525 o Defining RFC 527 Currently, there is no allocation in this registry. 529 Bit | Name | Reference 530 --------+------------------------------+------------- 531 23 | L-Bit | [This.I-D] 532 0-22 | Unassigned | [This.I-D] 534 8. Security Considerations 536 The security considerations described in [RFC9050], 537 [I-D.ietf-pce-pcep-extension-pce-controller-sr], and 538 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] and apply to the 539 extensions described in this document. 541 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 542 be activated on authenticated and encrypted sessions across PCEs and 543 PCCs belonging to the same administrative authority, using Transport 544 Layer Security (TLS) [RFC8253] as per the recommendations and best 545 current practices in [RFC7525] (unless explicitly set aside in 546 [RFC8253]). 548 9. Acknowledgements 550 TBD. 552 10. References 554 10.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 562 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 563 DOI 10.17487/RFC5440, March 2009, 564 . 566 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 567 Writing an IANA Considerations Section in RFCs", BCP 26, 568 RFC 8126, DOI 10.17487/RFC8126, June 2017, 569 . 571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 573 May 2017, . 575 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 576 Computation Element Communication Protocol (PCEP) 577 Extensions for Stateful PCE", RFC 8231, 578 DOI 10.17487/RFC8231, September 2017, 579 . 581 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 582 Computation Element Communication Protocol (PCEP) 583 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 584 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 585 . 587 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 588 "PCEPS: Usage of TLS to Provide a Secure Transport for the 589 Path Computation Element Communication Protocol (PCEP)", 590 RFC 8253, DOI 10.17487/RFC8253, October 2017, 591 . 593 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 594 Architecture for Use of PCE and the PCE Communication 595 Protocol (PCEP) in a Network with Central Control", 596 RFC 8283, DOI 10.17487/RFC8283, December 2017, 597 . 599 [I-D.ietf-pce-segment-routing-ipv6] 600 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 601 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 602 Routing leveraging the IPv6 data plane", draft-ietf-pce- 603 segment-routing-ipv6-09 (work in progress), May 2021. 605 10.2. Informative References 607 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 608 Element (PCE) Communication Protocol Generic 609 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 610 2006, . 612 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 613 "Recommendations for Secure Use of Transport Layer 614 Security (TLS) and Datagram Transport Layer Security 615 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 616 2015, . 618 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 619 Decraene, B., Litkowski, S., and R. Shakir, "Segment 620 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 621 July 2018, . 623 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 624 and J. Hardwick, "Path Computation Element Communication 625 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 626 DOI 10.17487/RFC8664, December 2019, 627 . 629 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 630 Computation Element Communication Protocol (PCEP) 631 Procedures and Extensions for Using the PCE as a Central 632 Controller (PCECC) of LSPs", RFC 9050, 633 DOI 10.17487/RFC9050, July 2021, 634 . 636 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 637 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 638 "PCEP Procedures and Protocol Extensions for Using PCE as 639 a Central Controller (PCECC) for Segment Routing (SR) MPLS 640 Segment Identifier (SID) Allocation and Distribution.", 641 draft-ietf-pce-pcep-extension-pce-controller-sr-02 (work 642 in progress), March 2021. 644 [I-D.ietf-pce-state-sync] 645 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 646 Stateful Path Computation Element (PCE) Communication 647 Procedures.", draft-ietf-pce-state-sync-00 (work in 648 progress), June 2021. 650 [I-D.ietf-spring-segment-routing-policy] 651 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 652 P. Mattes, "Segment Routing Policy Architecture", draft- 653 ietf-spring-segment-routing-policy-13 (work in progress), 654 May 2021. 656 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 657 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 658 and Protocol Extensions for Using PCE as a Central 659 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 660 extension-pce-controller-srv6-06 (work in progress), 661 February 2021. 663 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 664 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 665 (SRv6) Network Programming", RFC 8986, 666 DOI 10.17487/RFC8986, February 2021, 667 . 669 [I-D.ietf-pce-binding-label-sid] 670 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 671 and C. L. (editor), "Carrying Binding Label/Segment 672 Identifier in PCE-based Networks.", draft-ietf-pce- 673 binding-label-sid-10 (work in progress), July 2021. 675 Appendix A. Contributors 677 Dhruv Dhody 678 Huawei Technologies 679 Divyashree Techno Park, Whitefield 680 Bangalore, Karnataka 560066 681 India 683 EMail: dhruv.ietf@gmail.com 685 Zhenbin Li 686 Huawei Technologies 687 Huawei Campus, No. 156 Beiqing Rd. 688 Beijing 100095 689 China 691 EMail: lizhenbin@huawei.com 693 Jie Dong 694 Huawei Technologies 695 Huawei Campus, No. 156 Beiqing Rd. 696 Beijing 100095 697 China 699 EMail: jie.dong@huawei.com 701 Authors' Addresses 703 Cheng Li 704 Huawei Technologies 705 Huawei Campus, No. 156 Beiqing Rd. 706 Beijing 100095 707 China 709 EMail: c.l@huawei.com 711 Mach(Guoyi) Chen 712 Huawei Technologies 713 Huawei Campus, No. 156 Beiqing Rd. 714 Beijing 100095 715 China 717 EMail: Mach.chen@huawei.com 718 Aijun Wang 719 China Telecom 720 Beiqijia Town, 721 Beijing, Changping District 102209 722 China 724 EMail: wangaj3@chinatelecom.cn 726 Weiqiang Cheng 727 China Mobile 729 EMail: chengweiqiang@chinamobile.com 731 Chao Zhou 732 HPE 734 EMail: chaozhou_us@yahoo.com