idnits 2.17.00 (12 Aug 2021) /tmp/idnits2389/draft-li-pce-controlled-id-space-11.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 document date (21 March 2022) is 54 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-12 == Outdated reference: A later version (-02) exists of draft-ietf-pce-state-sync-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-21 == Outdated reference: A later version (-15) exists of draft-ietf-pce-binding-label-sid-14 Summary: 0 errors (**), 0 flaws (~~), 4 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 H. Shi 4 Intended status: Experimental Huawei Technologies 5 Expires: 22 September 2022 A. Wang 6 China Telecom 7 W. Cheng 8 China Mobile 9 C. Zhou 10 HPE 11 21 March 2022 13 PCE Controlled ID Space 14 draft-li-pce-controlled-id-space-11 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 22 September 2022. 60 Copyright Notice 62 Copyright (c) 2022 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 (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Revised BSD License text as 71 described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . 9 89 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 11 92 7.2. LABEL-CONTROL-SPACE TLV's Flag field . . . . . . . . . . 11 93 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field . . . . . . . . . 12 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 98 10.2. Informative References . . . . . . . . . . . . . . . . . 14 99 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 [RFC5440] defines the stateless Path Computation Element 105 Communication Protocol (PCEP) for the Path Computation Elements 106 (PCEs) to perform path computation in response to Path Computation 107 Clients (PCCs) requests. For supporting stateful operations, 108 [RFC8231] specifies a set of extensions to PCEP to enable stateful 109 control of LSPs within and across PCEP sessions in compliance with 110 [RFC4657]. Furthermore, [RFC8281] describes the setup, maintenance, 111 and teardown of PCE-initiated LSPs under the stateful PCE model, 112 without the need for local configuration on the PCC, thus allowing 113 for a dynamic network that is centrally controlled and deployed. 115 [RFC8283] introduces the architecture for PCE as a central 116 controller, it examines the motivations and applicability for PCEP as 117 a control protocol in this environment, and introduces the 118 implications for the protocol. Also, [RFC9050] specifies the 119 procedures and PCEP extensions for using the PCE as a Central 120 Controller (PCECC), where LSPs are calculated/set up/initiated and 121 label forwarding entries are downloaded through extending PCEP. 122 However, the document assumes that label range to be used by a PCE is 123 known and set on both PCEP peers. This extension adds the capability 124 to advertise the label range via a PCEP extension. 126 Similarly, [RFC9050] specifies the procedures and PCEP extensions 127 when a PCE-based controller is also responsible for configuring the 128 forwarding actions on the routers (SR SID distribution in this case), 129 in addition to computing the paths for packet flows in a segment 130 routing network and telling the edge routers what instructions to 131 attach to packets as they enter the network. However, the document 132 assumes that label range to be used by a PCE is known and set on both 133 PCEP peers. This extension adds the capability to advertise the 134 range (from SRGB or SRLB of the node) via a PCEP extension. 136 In addition, [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 137 specifies the procedures and PCEP extensions of PCECC for SRv6. An 138 SRv6 SID is represented as LOC:FUNCT ([RFC8986]) where LOC is the L 139 most significant bits and FUNCT is the 128-L least significant bits. 140 The FUNCT part of the SID is an opaque identification of a local 141 function bound to the SID. This extension adds the capability to 142 advertise the range of Function ID (FUNCT part) via a PCEP extension. 144 Once the PCC/node has given control over an ID space (for example 145 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 TLV format is 155 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/set up/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 [RFC9050] describes a mode where LSPs are provisioned as explicit 184 label instructions at each hop on the end-to-end path. Each router 185 along the path must be told what label forwarding instructions to 186 program and what resources to reserve. The controller uses PCEP to 187 communicate with each router along the path of the end-to-end LSP. 188 For this to work, the PCE-based controller will take responsibility 189 for managing some part of the MPLS label space for each router that 190 it controls as described in section 3.1.2. of [RFC8283]. A mechanism 191 for a PCC to inform the PCE of such a label space to control is 192 needed within PCEP. 194 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 195 compute, update or initiate SR-TE paths. [RFC9050] describes the 196 mechanism for PCECC to allocate and distribute the node/prefix/ 197 adjacency label (SID) via PCEP. To make such allocation, PCE needs 198 to be aware of the label space from Segment Routing Global Block 199 (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node 200 that it can control. A mechanism for a PCC to inform the PCE of such 201 label space to control is needed within PCEP. The full SRGB/SRLB of 202 a node could be learned via existing IGP or BGP-LS mechanism. 204 3.1.2. PCECC for SRv6 206 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] describes the 207 mechanism for PCECC to allocate and provision the SRv6 SID via PCEP. 208 An SRv6 SID is represented as LOC:FUNCT ([RFC8986]) where LOC is the 209 L most significant bits and FUNCT is the 128-L least significant 210 bits. The FUNCT part of the SID is an opaque identification of a 211 local function bound to the SID. To make such allocation, PCE needs 212 to be aware of the Function ID space (FUNCT part) of the node that it 213 controls. A mechanism for a PCC to inform the PCE of such a Function 214 ID space to control is needed within PCEP. 216 3.2. Binding SID Allocation 218 The headend of an SR Policy binds a Binding SID (BSID) 219 [I-D.ietf-pce-binding-label-sid] to its policy 220 [I-D.ietf-spring-segment-routing-policy]. The instantiation of which 221 may involve a list of SIDs. The Binding SID can be allocated by the 222 node as described in [I-D.ietf-pce-binding-label-sid], but there is 223 an inherent advantage in the Binding SID to be allocated by a PCE to 224 allow SR policies to be dynamically created, updated according to the 225 network status and operations. This is described in [RFC9050]. 226 Therefore, a PCE needs to obtain the authority and control to 227 allocate Binding SID actively from the PCC's label space as described 228 in above use case. 230 This is applicable for both SR-MPLS and SRv6 BSID. 232 4. Overview 234 During PCEP Initialization Phase, Open messages are exchanged between 235 the PCCs and the PCEs. The OPEN object may also contain a set of 236 TLVs used to convey the capabilities in the Open message. The term 237 'ID' in this document, could be a MPLS label, SRv6 Function ID or any 238 other future ID space for PCE to control and allocate from. A PCC 239 can include a corresponding ID-CONTROL-SPACE TLVs in the OPEN Object 240 to inform the corresponding ID space information that it wants the 241 PCE to control. This TLV MUST NOT be included by the PCE and MUST be 242 ignored on receipt by a PCC. This is an optional TLV, the PCE could 243 be aware of the ID space from some other means outside of PCEP. 245 For delegating multiple types of ID space, multiple TLVs 246 corresponding to each ID type MUST be included in an Open message. 247 The ID type can be MPLS label or other type of ID. The following ID- 248 CONTROL-SPACE TLV is defined in this document - 250 * LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS) 252 * FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID 254 The procedure of ID space control to PCE is shown below: 256 +-+-+ +-+-+ 257 |PCC| |PCE| 258 +-+-+ +-+-+ 259 | | 260 | Open msg (LABEL-CONTROL-SPACE,etc) | 261 | | 262 |-------- | 263 | \ Open msg | 264 | \ -----------------------------| 265 | \/ | 266 | /\ | 267 | / ---------------------------->| 268 | / | 269 |<------ Keepalive | 270 | ----------------------------| 271 |Keepalive / | 272 |-------- / | 273 | \/ | 274 | /\ | 275 |<------ ------------------------------>| 276 | | 278 Figure 1: ID space control to PCE 280 If the ID space control procedure is successful, the PCE will return 281 a KeepAlive message to the PCC. If there is any error in processing 282 the corresponding TLV, an Error (PCErr) message will be sent to the 283 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 284 value=TBD (ID space control failure). 286 After this process, a stateful PCE can learn the PCE-controlled ID 287 spaces of a node (PCC) under its control. A PCE can then allocate 288 IDs within the controlled-ID space. For example, a PCE can actively 289 allocate labels and download forwarding instructions for the PCECC 290 LSP as described in [RFC9050]. A PCE can also allocate labels from 291 the PCE controlled portion of the SRGB/SRLB for PCECC-SR [RFC9050]. 292 The full SRGB/SRLB of a node could be learned via existing IGP or 293 BGP-LS mechanism. 295 The procedure for handling the FUNCTION-ID-CONTROL-SPACE TLV is same 296 as above. 298 5. Objects 300 5.1. Open Object 302 For advertising the PCE-controlled ID space to a PCE, this document 303 defines several TLVs within the OPEN object. 305 5.1.1. LABEL-CONTROL-SPACE TLV 307 For a PCC to inform the label space under the PCE control, this 308 document defines a new LABEL-CONTROL-SPACE TLV. 310 The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object, 311 and its format is shown in the following figure: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type=TBD1 | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Block | Flags | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Start (1) | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Range (1) | Reserved | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | ... | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | ... | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Start (n) | Reserved | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Range (n) | Reserved | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 2: LABEL-CONTROL-SPACE TLV 335 The type (16 bits) of the TLV is TBD1. The length field (16 bits) 336 and has a variable value. 338 Block(8 bits): the number of ID blocks. The range of a block is 339 described by a start field and a range field. 341 Flags (24 bits): No flag is currently defined. The unassigned bits 342 of Flags field MUST be set to 0 on transmission and MUST be ignored 343 on receipt. 345 Start(i) (24 bits): indicates the beginning of the label block i. 347 Range(i) (24 bits): indicates the range of the label block i. 349 Reserved: MUST be set to 0 on transmission and MUST be ignored on 350 reception. 352 LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open 353 Message. On receipt, only the first instance is processed and others 354 MUST be ignored. 356 A stateful PCE can actively allocate labels and download forwarding 357 instructions for the PCECC LSP as described in [RFC9050]. A PCE can 358 also allocate labels from SRGB/SRLB for PCECC-SR 359 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. The Binding 360 Segments can also be selected for the PCE controlled space [RFC9050]. 362 5.1.2. FUNCT-ID-CONTROL-SPACE TLV 364 For a PCC to inform the SRv6 SID Function ID space under the PCE 365 control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV. 367 The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 368 object, and its format is shown in the following figure: 370 0 1 2 3 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type=TBD2 | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Block | Flags |L| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | SID | 378 | Structure | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 | Start (1) | 382 | | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 | Range (1) | 387 | | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | ...... | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | Start (n) | 394 | | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 | Range (n) | 399 | | 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Loc Size | Locator (variable)... | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 3: FUNCT-ID-CONTROL-SPACE TLV 407 The type (16 bits) of the TLV is TBD2. The length field (16 bits) 408 and has a variable value. 410 Block(8 bits): the number of ID blocks. The range of a block is 411 described by a start field and a range field. 413 Flags (24 bits): Following flags are currently defined 415 * L-flag: Locator flag, set when the locator information is included 416 in this TLV. If L-flag is unset, Loc Size and variable Locator 417 field MUST NOT be included in this TLV, and the ID spaces are 418 applicable to all Locators. 420 The unassigned bits of Flags field MUST be set to 0 on transmission 421 and MUST be ignored on receipt. 423 SID Structure: 64-bit field formatted as per "SID Structure" in 424 [I-D.ietf-pce-segment-routing-ipv6]. 426 Start(i) (128 bits): indicates the beginning of the Function ID block 427 i. 429 Range(i) (128 bits): indicates the range of the Function ID block i. 431 Loc size(8 bits): indicates the bit length of a Locator. Appears 432 only when the L-flag is set. 434 Locator (variable length): the value of a Locator. The Function ID 435 spaces specified in this TLV are associated with this locator. 437 As per [RFC5440], the value portion of the PCEP TLV needs to be 438 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with 439 trailing zeros to a 4-byte boundary. 441 Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN object 442 to specify Function ID space specefic to each locator. 444 A stateful PCE can actively allocate SRv6 SID and download SIDs for 445 the PCECC-SRv6 as described in 446 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 448 Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is assumed 449 to be known at PCE and FUNCT is allocated from the PCE controlled 450 Function ID block. 452 6. Other Considerations 454 In case of multiple PCEs, a PCC MAY decide to give control over 455 different ID space to each instance of the PCE. In case a PCC 456 includes the same ID space to multiple PCEs, the PCE MUST use 457 synchronization mechanism (such as [I-D.ietf-pce-state-sync]) to 458 avoid allocating the same ID. 460 The PCE would allocate ID from the PCE controlled ID space. The PCC 461 would not allocate ID by itself from this space as long as it has an 462 active PCEP session to a PCE to which it has given control over the 463 ID space. 465 Note that if there is any change in the ID space, the PCC MUST bring 466 the session down and re-establish the session with new TLVs. During 467 state synchronization the PCE would need to consider the new ID space 468 into consideration and SHOULD re-establish the LSP/SR-paths if 469 needed. 471 The PCC can regain control of the ID space by closing the PCEP 472 session and require new session without ID space TLVs specified in 473 this document. 475 7. IANA Considerations 477 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 478 registry. This document requests IANA actions to allocate code 479 points for the protocol elements defined in this document. 481 7.1. PCEP TLV Type Indicators 483 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 484 is requested to make an assignment from this subregistry as follows: 486 Value | Meaning | Reference 487 --------+------------------------------+------------- 488 TBD1 | LABEL-CONTROL-SPACE TLV | [This.I-D] 489 TBD2 | FUNCT-ID-CONTROL-SPACE TLV | [This.I-D] 491 7.2. LABEL-CONTROL-SPACE TLV's Flag field 493 This document defines the LABEL-CONTROL-SPACE TLV and requests that 494 IANA to create a new sub-registry to manage the value of the LABEL- 495 CONTROL-SPACE TLV's 24-bits Flag field. New values are to be 496 assigned by Standards Action [RFC8126]. Each bit should be tracked 497 with the following qualities: 499 * Bit number (counting from bit 0 as the most significant bit) 501 * Capability description 503 * Defining RFC 505 Currently, there is no allocation in this registry. 507 Bit | Name | Reference 508 --------+------------------------------+------------- 509 0-23 | Unassigned | [This.I-D] 511 7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field 513 This document defines the FUNCT-ID-CONTROL-SPACE TLV and requests 514 that IANA to create a new sub-registry to manage the value of the 515 FUNCT-ID-CONTROL-SPACE TLV's 24-bits Flag field. New values are to 516 be assigned by Standards Action [RFC8126]. Each bit should be 517 tracked with the following qualities: 519 * Bit number (counting from bit 0 as the most significant bit) 521 * Capability description 523 * Defining RFC 525 Currently, there is no allocation in this registry. 527 Bit | Name | Reference 528 --------+------------------------------+------------- 529 23 | L-Bit | [This.I-D] 530 0-22 | Unassigned | [This.I-D] 532 8. Security Considerations 534 The security considerations described in [RFC9050], 535 [I-D.ietf-pce-pcep-extension-pce-controller-sr], and 536 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] and apply to the 537 extensions described in this document. 539 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 540 be activated on authenticated and encrypted sessions across PCEs and 541 PCCs belonging to the same administrative authority, using Transport 542 Layer Security (TLS) [RFC8253] as per the recommendations and best 543 current practices in [RFC7525] (unless explicitly set aside in 544 [RFC8253]). 546 9. Acknowledgements 548 TBD. 550 10. References 552 10.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, 556 DOI 10.17487/RFC2119, March 1997, 557 . 559 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 560 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 561 DOI 10.17487/RFC5440, March 2009, 562 . 564 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 565 Writing an IANA Considerations Section in RFCs", BCP 26, 566 RFC 8126, DOI 10.17487/RFC8126, June 2017, 567 . 569 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 570 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 571 May 2017, . 573 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 574 Computation Element Communication Protocol (PCEP) 575 Extensions for Stateful PCE", RFC 8231, 576 DOI 10.17487/RFC8231, September 2017, 577 . 579 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 580 Computation Element Communication Protocol (PCEP) 581 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 582 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 583 . 585 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 586 "PCEPS: Usage of TLS to Provide a Secure Transport for the 587 Path Computation Element Communication Protocol (PCEP)", 588 RFC 8253, DOI 10.17487/RFC8253, October 2017, 589 . 591 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 592 Architecture for Use of PCE and the PCE Communication 593 Protocol (PCEP) in a Network with Central Control", 594 RFC 8283, DOI 10.17487/RFC8283, December 2017, 595 . 597 [I-D.ietf-pce-segment-routing-ipv6] 598 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 599 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 600 Routing leveraging the IPv6 data plane", Work in Progress, 601 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-12, 6 602 March 2022, . 605 10.2. Informative References 607 [RFC4657] Ash, J., Ed. and J.L. 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 "Path Computation Element Communication Protocol (PCEP) 639 Procedures and Extensions for Using PCE as a Central 640 Controller (PCECC) for Segment Routing (SR) MPLS Segment 641 Identifier (SID) Allocation and Distribution.", Work in 642 Progress, Internet-Draft, draft-ietf-pce-pcep-extension- 643 pce-controller-sr-04, 6 March 2022, 644 . 647 [I-D.ietf-pce-state-sync] 648 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 649 Stateful Path Computation Element (PCE) Communication 650 Procedures.", Work in Progress, Internet-Draft, draft- 651 ietf-pce-state-sync-01, 20 October 2021, 652 . 655 [I-D.ietf-spring-segment-routing-policy] 656 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 657 P. Mattes, "Segment Routing Policy Architecture", Work in 658 Progress, Internet-Draft, draft-ietf-spring-segment- 659 routing-policy-21, 19 March 2022, 660 . 663 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 664 Li, Z., Peng, S., Geng, X., and M. Negi, "Path Computation 665 Element Communication Protocol (PCEP) Procedures and 666 Extensions for Using the PCE as a Central Controller 667 (PCECC) for SRv6 SID Allocation and Distribution.", Work 668 in Progress, Internet-Draft, draft-dhody-pce-pcep- 669 extension-pce-controller-srv6-08, 6 March 2022, 670 . 673 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 674 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 675 (SRv6) Network Programming", RFC 8986, 676 DOI 10.17487/RFC8986, February 2021, 677 . 679 [I-D.ietf-pce-binding-label-sid] 680 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 681 and C. L. (editor), "Carrying Binding Label/Segment 682 Identifier (SID) in PCE-based Networks.", Work in 683 Progress, Internet-Draft, draft-ietf-pce-binding-label- 684 sid-14, 3 March 2022, . 687 Appendix A. Contributors 689 Dhruv Dhody 690 Huawei Technologies 691 Divyashree Techno Park, Whitefield 692 Bangalore, Karnataka 560066 693 India 695 EMail: dhruv.ietf@gmail.com 697 Mach Chen 698 Huawei Technologies 699 China 701 EMail: Mach.chen@huawei.com 703 Zhenbin Li 704 Huawei Technologies 705 Huawei Campus, No. 156 Beiqing Rd. 706 Beijing 100095 707 China 709 EMail: lizhenbin@huawei.com 711 Jie Dong 712 Huawei Technologies 713 Huawei Campus, No. 156 Beiqing Rd. 714 Beijing 100095 715 China 717 EMail: jie.dong@huawei.com 719 Authors' Addresses 721 Cheng Li 722 Huawei Technologies 723 Huawei Campus, No. 156 Beiqing Rd. 724 Beijing 725 100095 726 China 727 Email: c.l@huawei.com 729 Hang Shi 730 Huawei Technologies 731 Huawei Campus, No. 156 Beiqing Rd. 732 Beijing 733 100095 734 China 735 Email: shihang9@huawei.com 737 Aijun Wang 738 China Telecom 739 Beiqijia Town, 740 Beijing 741 Changping District, 102209 742 China 743 Email: wangaj3@chinatelecom.cn 745 Weiqiang Cheng 746 China Mobile 747 Email: chengweiqiang@chinamobile.com 749 Chao Zhou 750 HPE 751 Email: chaozhou_us@yahoo.com