idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-p2mp-07.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 (27 August 2021) is 974 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-07 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track X. Geng 5 Expires: 28 February 2022 Huawei Technologies 6 M. Negi 7 RtBrick Inc 8 27 August 2021 10 Path Computation Element Communication Protocol (PCEP) Procedures and 11 Extensions for Using the PCE as a Central Controller (PCECC) of P2MP 12 LSPs 13 draft-dhody-pce-pcep-extension-pce-controller-p2mp-07 15 Abstract 17 The Path Computation Element (PCE) is a core component of Software- 18 Defined Networking (SDN) systems. 20 The PCE has been identified as an appropriate technology for the 21 determination of the paths of point-to-multipoint (P2MP) TE Label 22 Switched Paths (LSPs). 24 A PCE-based Central Controller (PCECC) can simplify the processing of 25 a distributed control plane by blending it with elements of SDN and 26 without necessarily completely replacing it. Thus, the P2MP LSP can 27 be calculated/set up/initiated and the label-forwarding entries can 28 also be downloaded through a centralized PCE server to each network 29 device along the P2MP path, while leveraging the existing PCE 30 technologies as much as possible. 32 This document specifies the procedures and Path Computation Element 33 Communication Protocol (PCEP) extensions for using the PCE as the 34 central controller for provisioning labels along the path of the 35 static P2MP LSP. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 28 February 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 73 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Procedures for Using the PCE as a Central Controller (PCECC) 75 for P2MP . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 5 77 4.2. PCECC Capability Advertisement . . . . . . . . . . . . . 5 78 4.3. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 79 4.3.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 6 80 4.3.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 7 81 4.3.3. Central Control Instructions . . . . . . . . . . . . 7 82 4.3.3.1. Label Download CCI . . . . . . . . . . . . . . . 7 83 4.3.3.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 9 84 4.3.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 9 85 4.3.5. Re-delegation and Cleanup . . . . . . . . . . . . . . 9 86 4.3.6. Synchronization of Central Controllers 87 Instructions . . . . . . . . . . . . . . . . . . . . 9 88 4.3.7. PCECC LSP State Report . . . . . . . . . . . . . . . 9 89 4.3.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 9 90 5. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 91 6. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10 92 6.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10 93 6.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 94 6.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 95 6.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 11 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 97 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 98 8.1. Control of Function and Policy . . . . . . . . . . . . . 11 99 8.2. Information and Data Models . . . . . . . . . . . . . . . 12 100 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 101 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 102 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 103 8.6. Impact On Network Operations . . . . . . . . . . . . . . 12 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 105 9.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 12 106 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 13 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 110 11.2. Informative References . . . . . . . . . . . . . . . . . 14 111 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 16 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 114 1. Introduction 116 The Path Computation Element (PCE) [RFC4655] was developed to offload 117 the path computation function from routers in an MPLS traffic- 118 engineered (TE) network. It can compute optimal paths for traffic 119 across a network and can also update the paths to reflect changes in 120 the network or traffic demands. Since then, the role and function of 121 the PCE have grown to cover a number of other uses (such as GMPLS 122 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 123 use of network resources [RFC8281]. 125 According to [RFC7399], Software-Defined Networking (SDN) refers to a 126 separation between the control elements and the forwarding components 127 so that software running in a centralized system, called a 128 controller, can act to program the devices in the network to behave 129 in specific ways. A required element in an SDN architecture is a 130 component that plans how the network resources will be used and how 131 the devices will be programmed. It is possible to view this 132 component as performing specific computations to place traffic flows 133 within the network given knowledge of the availability of network 134 resources, how other forwarding devices are programmed, and the way 135 that other flows are routed. This is the function and purpose of a 136 PCE, and the way that a PCE integrates into a wider network control 137 system (including an SDN system) is presented in [RFC7491]. 139 In early PCE implementations, where the PCE was used to derive paths 140 for MPLS Label Switched Paths (LSPs), paths were requested by network 141 elements (known as Path Computation Clients (PCCs)), and the results 142 of the path computations were supplied to network elements using the 143 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 144 This protocol was later extended to allow a PCE to send unsolicited 145 requests to the network for LSP establishment [RFC8281]. 147 [RFC8283] introduces the architecture for PCE as a central controller 148 as an extension of the architecture described in [RFC4655] and 149 assumes the continued use of PCEP as the protocol used between PCE 150 and PCC. [RFC8283] further examines the motivations and 151 applicability for PCEP as a Southbound Interface (SBI), and 152 introduces the implications for the protocol. 154 A PCECC can simplify the processing of a distributed control plane by 155 blending it with elements of SDN and without necessarily completely 156 replacing it. Thus, the LSP can be calculated/set up/initiated and 157 the label-forwarding entries can also be downloaded through a 158 centralized PCE server to each network device along the path while 159 leveraging the existing PCE technologies as much as possible. 161 [RFC9050] specify the procedures and PCEP extensions for using the 162 PCE as the central controller for static P2P LSPs, where LSPs can be 163 provisioned as explicit label instructions at each hop on the end-to- 164 end path. Each router along the path must be told what label- 165 forwarding instructions to program and what resources to reserve. 166 The PCE-based controller keeps a view of the network and determines 167 the paths of the end-to-end LSPs, and the controller uses PCEP to 168 communicate with each router along the path of the end-to-end LSP. 170 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 171 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 172 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 173 PCE has been identified as a suitable application for the computation 174 of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to 175 request path computation for P2MP TE LSPs are described in [RFC8306]. 176 Further [RFC8623] specify the extensions that are necessary in order 177 for the deployment of stateful PCEs to support P2MP TE LSPs as well 178 as the setup, maintenance and teardown of PCE-initiated P2MP LSPs 179 under the stateful PCE model. 181 This document extends [RFC9050] to specify the procedures and PCEP 182 extensions for using the PCE as the central controller for static 183 P2MP LSPs, where LSPs can be provisioned as explicit label 184 instructions at each hop on the end-to-end path with an added 185 functionality of a P2MP branch node. As per [RFC4875], a branch node 186 is an LSR that replicates the incoming data on to one or more 187 outgoing interfaces. [I-D.ietf-teas-pcecc-use-cases] describes the 188 use cases for P2MP in PCECC architecture. 190 2. Terminology 192 Terminologies used in this document is the same as described in the 193 draft [RFC8283]. 195 2.1. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 3. Basic PCECC Mode 205 Section 3 of [RFC9050] describe the PCECC model of operation. 207 This document extends the functionality to include support for 208 central control instruction for replication at the branch nodes for 209 the P2MP LSP. 211 The rest of the processing at the root node is similar to the 212 existing stateful PCE mechanism for P2MP [RFC8623]. 214 4. Procedures for Using the PCE as a Central Controller (PCECC) for 215 P2MP 217 4.1. Stateful PCE Model 219 Active stateful PCE is described in [RFC8231] and extended for P2MP 220 [RFC8623]. A PCE as a Central Controller (PCECC) reuses the existing 221 active stateful PCE mechanism as much as possible to control the 222 LSPs. 224 [RFC9050] extends PCEP messages - PCInitiate, PCRpt, and PCUpd 225 message for the Central Controller's Instructions (CCI) (label- 226 forwarding instructions in the context of this document). This 227 document specify the procedure for additional instruction for branch 228 node needed for P2MP. 230 4.2. PCECC Capability Advertisement 232 As per Section 5.4 of [RFC9050], during the PCEP initialization 233 phase, PCEP Speakers (PCE or PCC) advertise their support of and 234 willingness to use PCEP extension for the PCECC using a new Path 235 Setup Type (PST) in PATH-SETUP-TYPE-CAPABILITY TLV and a new PCECC- 236 CAPABILITY sub-TLV. 238 A new M bit is added in the PCECC-CAPABILITY sub-TLV to indicate 239 support for PCECC-P2MP. A PCC MUST set the M bit in the PCECC- 240 CAPABILITY sub-TLV and include STATEFUL-PCE-CAPABILITY TLV with the 241 P2MP bits set (as per [RFC8623]) in the OPEN object to support the 242 PCECC P2MP extensions defined in this document. 244 If the M bit is set in PCECC-CAPABILITY sub-TLV and the STATEFUL-PCE- 245 CAPABILITY TLV is not advertised, or is advertised without the N bit 246 set, in the OPEN object, the receiver MUST: 248 * send a PCErr message with Error-Type=19 (Invalid Operation) and 249 Error-value=TBD2 (P2MP capability was not advertised) and 251 * terminate the session. 253 The rest of the processing is as per [RFC9050]. 255 4.3. LSP Operations 257 The PCEP messages pertaining to a PCECC includes the PATH-SETUP-TYPE 258 TLV [RFC8408] in the SRP object [RFC8231] with the PST set to '2' to 259 clearly identify the the PCECC LSP is intended as per [RFC9050]. 261 4.3.1. PCE-Initiated PCECC LSP 263 The LSP instantiation operation is the same as defined in [RFC8281] 264 and [RFC8623]. 266 In order to set up a PCE-Initiated P2MP LSP based on the PCECC 267 mechanism, a PCE sends a PCInitiate message with the PST set to '2' 268 for the PCECC ([RFC9050]) to the ingress PCC (root node). 270 As described in [RFC9050], the label-forwarding instructions from 271 PCECC are sent after the initial PCInitiate and PCRpt exchange. This 272 is done so that the PCEP-specific identifier for the LSP (PLSP-ID) 273 and other LSP identifiers can be obtained from the ingress and can be 274 included in the label-forwarding instruction in the next set of 275 PCInitiate message along the path. 277 An P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for the PCECC 278 P2MP LSPs, it uniquely identifies the P2MP LSP in the network. As 279 per [RFC9050], the LSP object is included in the central controller's 280 instructions (label download) to identify the PCECC P2MP LSP for this 281 instruction. The handling of PLSP-ID is as per [RFC9050]. 283 The ingress PCC (root) also sets the D (Delegate) flag (see 284 [RFC8231]) and C (Create) flag (see [RFC8281]) in the LSP object of 285 the PCRpt message. As per [RFC9050], when the PCE receives this 286 PCRpt message with the PLSP-ID, it assigns labels along the path and 287 sets up the path by sending a PCInitiate message to each node along 288 the path of the P2MP Tree as per the PCECC technique. The CC-ID 289 uniquely identifies the central controller instruction within a PCEP 290 session. Each node along the path (PCC) responds with the PCRpt 291 messages to acknowledge the CCI with the PCRpt messages including the 292 CCI and the LSP objects. The only new extension required is the 293 instructions on the branch nodes for replications to more than one 294 outgoing interface with the respective label. The rest of the 295 operations remains the same as [RFC9050] and [RFC8623]. 297 4.3.2. PCC-Initiated PCECC LSP 299 In order to set up a P2MP LSP based on the PCECC mechanism where the 300 LSP is configured at the PCC, a PCC MUST delegate the P2MP LSP by 301 sending a PCRpt message with the PST set for the PCECC and D 302 (Delegate) flag (see [RFC8623]) set in the LSP object. 304 When a PCE receives the initial PCRpt message with the D flags and 305 PST Type set to '2', it SHOULD calculate the P2MP tree and assign 306 labels along the P2MP tree in addition to setting up the P2MP LSP by 307 sending PCInitiate message to each node along the path of the P2MP 308 LSP as per [RFC9050]. The only new extension required is the 309 instructions on the branch nodes for replications to more than one 310 outgoing interface with the respective label. The rest of the 311 operations remains the same as [RFC9050] and [RFC8623]. 313 4.3.3. Central Control Instructions 315 The CCI for the label operations in PCEP are done via the PCInitiate 316 message as described in [RFC9050], by defining a PCEP Objects for CCI 317 operations. The local label range of each PCC is assumed to be known 318 by both the PCC and the PCE. 320 4.3.3.1. Label Download CCI 322 In order to set up an LSP based on the PCECC, the PCE sends a 323 PCInitiate message to each node along the path to download the label 324 instructions, as described in Section 4.3.1 and Section 4.3.2. 326 The CCI object MUST be included, along with the LSP object in the 327 PCInitiate message. As per [RFC9050], there are at most 2 instances 328 of CCI object in the PCInitiate message. For PCECC-P2MP operations, 329 multiple instances of CCI object for out-labels is allowed. 330 Similarly to acknowledge the central controller instructions, the 331 PCRpt message allows multiple instances of CCI object for PCECC-P2MP 332 operations. 334 The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object for 335 the PCECC based P2MP LSP. The SPEAKER-ENTITY-ID TLV SHOULD be 336 included in LSP object. 338 As described in [RFC9050], if a node (PCC) receives a PCInitiate 339 message that includes a label to download (as part of CCI) that is 340 out of the range set aside for the PCE, it send a PCErr message with 341 Error-type=3 (PCECC failure) and Error-value=1 (Label out of range) 342 ([RFC9050]). If a PCC receives a PCInitiate message but fails to 343 download the label entry, it sends a PCErr message with Error-type=3 344 (PCECC failure) and Error-value=2 (Instruction failed) ([RFC9050]). 346 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 348 +----------+ 349 | R1 | Root node of the P2MP TE LSP 350 +----------+ 351 |6000 352 +----------+ 353 Transit Node | R2 | 354 branch +----------+ 355 * | * * 356 9001* | * *9002 357 * | * * 358 +-----------+ | * +-----------+ 359 | R4 | | * | R5 | Transit Nodes 360 +-----------+ | * +-----------+ 361 * | * * + 362 9003* | * * +9004 363 * | * * + 364 +-----------+ +-----------+ 365 | R3 | | R6 | Leaf Node 366 +-----------+ +-----------+ 367 9005| 368 +-----------+ 369 | R8 | Leaf Node 370 +-----------+ 372 PCECC would provision each node along the path and assign incoming 373 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 374 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 375 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 376 R2 are same as [RFC9050]. The branch node (R2) needs to be 377 instructed to replicate two copies of the incoming packet, and sent 378 towards R4 and R5 with 9001 and 9002 labels respectively). This done 379 via including 3 instances of CCI objects in the PCEP messages, one 380 for each label in the example, 6000 for incoming and 9001/9002 for 381 outgoing (along with remote nexthop). The message and procedure 382 remains exactly as [RFC9050] with only distinction that more than one 383 outgoing CCI MAY be present for the P2MP LSP. 385 4.3.3.2. Label Cleanup CCI 387 In order to delete a P2MP LSP based on the PCECC, the PCE sends a 388 Central Controller Instructions via a PCInitiate message to each node 389 along the path of the P2MP tree to clean up the label-forwarding 390 instruction as per [RFC9050]. In case of branch nodes, all instances 391 of CCIs needs to be present in the PCEP message. 393 4.3.4. PCECC LSP Update 395 In case of a modification of PCECC P2MP LSP with a new path, the 396 procedure, and instructions as described in [RFC9050] apply. 398 4.3.5. Re-delegation and Cleanup 400 In case of a re-delegation and clean up of PCECC P2MP LSP, the 401 procedure, and instructions as described in [RFC9050] apply. 403 4.3.6. Synchronization of Central Controllers Instructions 405 The procedure and instructions are as per [RFC9050]. 407 4.3.7. PCECC LSP State Report 409 An ingress PCC MAY choose to apply any Operations, Administration, 410 and Maintenance (OAM) mechanism to check the status of the LSP in the 411 data plane and MAY further send its status in the PCRpt message (as 412 per [RFC8623]) to the PCE. 414 4.3.8. PCC-Based Allocations 416 The PCE can request the PCC to allocate the label using the 417 PCInitiate message. The procedure and instructions are as per 418 Section 5.5.8 of [RFC9050]. 420 5. PCEP Messages 422 [RFC9050] specify the extension to PCInitiate and PCRpt message for 423 PCECC. For P2P LSP, only two instances of CCI objects can be 424 included. In the case of the P2MP LSP, multiple CCI objects are 425 allowed. The message format and other procedures continue to apply. 427 6. PCEP Objects 429 6.1. OPEN Object 431 6.1.1. PCECC Capability sub-TLV 433 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 434 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 435 CAPABILITY TLV as specified in [RFC9050]. 437 This document adds a new flag (M Bit) in the PCECC-CAPABILITY sub-TLV 438 to indicate the support for P2MP in PCECC. 440 M (PCECC-P2MP-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 441 speaker, it indicates that the PCEP speaker is capable of PCECC-P2MP 442 capability. 444 A PCC MUST set the M Bit in the PCECC-CAPABILITY sub-TLV and set the 445 N (P2MP-CAPABILITY), the M (P2MP-LSP-UPDATE-CAPABILITY), and the P 446 (P2MP-LSP-INSTANTIATION-CAPABILITY) bits (as per [RFC8623]) in the 447 STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support the PCECC-P2MP 448 extensions defined in this document. If the M Bit is set in PCECC- 449 CAPABILITY sub-TLV and the P2MP bits (in the STATEFUL-PCE-CAPABILITY 450 TLV) are not set in the OPEN Object, a PCEP speaker SHOULD send a 451 PCErr message with Error-Type=19 (Invalid Operation) and Error- 452 value=TBD2 (P2MP capability was not advertised) and terminate the 453 session. 455 6.2. PATH-SETUP-TYPE TLV 457 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; [RFC9050] defines a 458 PST value for PCECC as '2', which is applicable for P2MP LSP as well. 460 6.3. CCI Object 462 The CCI object [RFC9050] is used by the PCE to specify the forwarding 463 instructions (label information in the context of this document) to 464 the PCC, and optionally carried within PCInitiate or PCRpt message 465 for label download/report. The CCI Object Type 1 for MPLS Label is 466 defined in [RFC9050], which is used for the P2MP LSPs as well. The 467 address TLVs are defined in [RFC9050], they associate the next-hop 468 information in case of an outgoing label. 470 If a node (PCC) receives a PCInitiate message with more than one CCI 471 with O-bit set for the outgoing label and the node does not support 472 the P2MP branch/replication capability, it MUST respond with PCErr 473 message with Error-Type=2 (Capability not supported) (defined in 474 [RFC5440]). 476 The rest of the processing is same as [RFC9050]. 478 7. Security Considerations 480 As per [RFC8283], the security considerations for a PCE-based 481 controller are a little different from those for any other PCE 482 system. That is, the operation relies heavily on the use and 483 security of PCEP, so consideration should be given to the security 484 features discussed in [RFC5440] and the additional mechanisms 485 described in [RFC8253]. It further lists the vulnerability of a 486 central controller architecture, such as a central point of failure, 487 denial of service, and a focus for interception and modification of 488 messages sent to individual Network Elements (NEs). 490 The security considerations described in [RFC8231], [RFC8281], 491 [RFC8623], and [RFC9050] apply to the extensions described in this 492 document. 494 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 495 be activated on authenticated and encrypted sessions across PCEs and 496 PCCs belonging to the same administrative authority, using Transport 497 Layer Security (TLS) [RFC8253] as per the recommendations and best 498 current practices in [RFC7525] (unless explicitly set aside in 499 [RFC8253]). 501 8. Manageability Considerations 503 8.1. Control of Function and Policy 505 A PCE or PCC implementation SHOULD allow to configure to enable/ 506 disable PCECC-P2MP capability as a global configuration. 508 8.2. Information and Data Models 510 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 511 PCECC capability status. 513 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 514 enable/disable PCECC-P2MP capability. 516 8.3. Liveness Detection and Monitoring 518 Mechanisms defined in this document do not imply any new liveness 519 detection and monitoring requirements in addition to those already 520 listed in [RFC5440]. 522 8.4. Verify Correct Operations 524 Mechanisms defined in this document do not imply any new operation 525 verification requirements in addition to those already listed in 526 [RFC5440] and [RFC8231]. 528 8.5. Requirements On Other Protocols 530 PCEP extensions defined in this document do not put new requirements 531 on other protocols. 533 8.6. Impact On Network Operations 535 PCEP extensions defined in this document do not put new requirements 536 on network operations. 538 9. IANA Considerations 540 9.1. PCECC-CAPABILITY sub-TLV 542 [RFC9050] defines the PCECC-CAPABILITY sub-TLV and requests that IANA 543 creates a registry to manage the value of the PCECC-CAPABILITY sub- 544 TLV's Flag field. IANA is requested to allocate a new bit in the 545 PCECC-CAPABILITY sub-TLV Flag Field registry, as follows: 547 +======+=============+===============+ 548 | Bit | Description | Reference | 549 +======+=============+===============+ 550 | TBD1 | P2MP | This document | 551 +------+-------------+---------------+ 553 Table 1 555 9.2. PCEP-Error Object 557 IANA is requested to allocate a new error value within the "PCEP- 558 ERROR Object Error Types and Values" sub-registry of the PCEP Numbers 559 registry for the following errors: 561 Error-Type Meaning 562 ---------- ------- 563 19 Invalid operation. 564 Error-value = TBD2 : P2MP capability was 565 not advertised 567 The Reference is marked as "This document". 569 10. Acknowledgments 571 11. References 573 11.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 581 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 582 DOI 10.17487/RFC5440, March 2009, 583 . 585 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 586 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 587 May 2017, . 589 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 590 Computation Element Communication Protocol (PCEP) 591 Extensions for Stateful PCE", RFC 8231, 592 DOI 10.17487/RFC8231, September 2017, 593 . 595 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 596 "PCEPS: Usage of TLS to Provide a Secure Transport for the 597 Path Computation Element Communication Protocol (PCEP)", 598 RFC 8253, DOI 10.17487/RFC8253, October 2017, 599 . 601 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 602 Computation Element Communication Protocol (PCEP) 603 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 604 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 605 . 607 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 608 Path Computation Element (PCE) Protocol Extensions for 609 Usage with Point-to-Multipoint TE Label Switched Paths 610 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 611 . 613 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 614 Computation Element Communication Protocol (PCEP) 615 Procedures and Extensions for Using the PCE as a Central 616 Controller (PCECC) of LSPs", RFC 9050, 617 DOI 10.17487/RFC9050, July 2021, 618 . 620 11.2. Informative References 622 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 623 Computation Element (PCE)-Based Architecture", RFC 4655, 624 DOI 10.17487/RFC4655, August 2006, 625 . 627 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 628 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 629 June 2007, . 631 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 632 Yasukawa, Ed., "Extensions to Resource Reservation 633 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 634 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 635 DOI 10.17487/RFC4875, May 2007, 636 . 638 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 639 Path Computation Element (PCE) to Point-to-Multipoint 640 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 641 DOI 10.17487/RFC5671, October 2009, 642 . 644 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 645 Margaria, "Requirements for GMPLS Applications of PCE", 646 RFC 7025, DOI 10.17487/RFC7025, September 2013, 647 . 649 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 650 Computation Element Architecture", RFC 7399, 651 DOI 10.17487/RFC7399, October 2014, 652 . 654 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 655 Hardwick, "Path Computation Element Communication Protocol 656 (PCEP) Management Information Base (MIB) Module", 657 RFC 7420, DOI 10.17487/RFC7420, December 2014, 658 . 660 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 661 Application-Based Network Operations", RFC 7491, 662 DOI 10.17487/RFC7491, March 2015, 663 . 665 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 666 "Recommendations for Secure Use of Transport Layer 667 Security (TLS) and Datagram Transport Layer Security 668 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 669 2015, . 671 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 672 Architecture for Use of PCE and the PCE Communication 673 Protocol (PCEP) in a Network with Central Control", 674 RFC 8283, DOI 10.17487/RFC8283, December 2017, 675 . 677 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 678 "Extensions to the Path Computation Element Communication 679 Protocol (PCEP) for Point-to-Multipoint Traffic 680 Engineering Label Switched Paths", RFC 8306, 681 DOI 10.17487/RFC8306, November 2017, 682 . 684 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 685 Hardwick, "Conveying Path Setup Type in PCE Communication 686 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 687 July 2018, . 689 [I-D.ietf-teas-pcecc-use-cases] 690 Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., 691 Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. 692 Gulida, "The Use Cases for Path Computation Element (PCE) 693 as a Central Controller (PCECC).", Work in Progress, 694 Internet-Draft, draft-ietf-teas-pcecc-use-cases-07, 8 695 March 2021, . 698 [I-D.ietf-pce-pcep-yang] 699 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 700 "A YANG Data Model for Path Computation Element 701 Communications Protocol (PCEP)", Work in Progress, 702 Internet-Draft, draft-ietf-pce-pcep-yang-16, 22 February 703 2021, . 706 Appendix A. Contributor Addresses 708 Dhruv Dhody 709 Huawei Technologies 710 Divyashree Techno Park, Whitefield 711 Bangalore, Karnataka 560066 712 India 714 EMail: dhruv.ietf@gmail.com 716 Udayasree Palle 718 EMail: udayasreereddy@gmail.com 720 Authors' Addresses 722 Zhenbin Li 723 Huawei Technologies 724 Huawei Bld., No.156 Beiqing Rd. 725 Beijing 726 100095 727 China 729 Email: lizhenbin@huawei.com 731 Shuping Peng 732 Huawei Technologies 733 Huawei Bld., No.156 Beiqing Rd. 734 Beijing 735 100095 736 China 738 Email: pengshuping@huawei.com 739 Xuesong Geng 740 Huawei Technologies 741 China 743 Email: gengxuesong@huawei.com 745 Mahendra Singh Negi 746 RtBrick Inc 747 N-17L, 18th Cross Rd, HSR Layout 748 Bangalore 560102 749 Karnataka 750 India 752 Email: mahend.ietf@gmail.com