idnits 2.17.00 (12 Aug 2021) /tmp/idnits29227/draft-dhody-pce-pcep-extension-pce-controller-p2mp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (6 March 2022) is 69 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) == Outdated reference: A later version (-09) exists of draft-ietf-teas-pcecc-use-cases-08 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: 7 September 2022 Huawei Technologies 6 M. Negi 7 RtBrick Inc 8 6 March 2022 10 Path Computation Element Communication Protocol (PCEP) Procedures and 11 Extensions for Using the PCE as a Central Controller (PCECC) of point- 12 to-multipoint (P2MP) LSPs 13 draft-dhody-pce-pcep-extension-pce-controller-p2mp-08 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 7 September 2022. 54 Copyright Notice 56 Copyright (c) 2022 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 Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 12 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 109 10.2. Informative References . . . . . . . . . . . . . . . . . 14 110 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 113 1. Introduction 115 The Path Computation Element (PCE) [RFC4655] was developed to offload 116 the path computation function from routers in an MPLS traffic- 117 engineered (TE) network. It can compute optimal paths for traffic 118 across a network and can also update the paths to reflect changes in 119 the network or traffic demands. Since then, the role and function of 120 the PCE have grown to cover a number of other uses (such as GMPLS 121 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 122 use of network resources [RFC8281]. 124 According to [RFC7399], Software-Defined Networking (SDN) refers to a 125 separation between the control elements and the forwarding components 126 so that software running in a centralized system, called a 127 controller, can act to program the devices in the network to behave 128 in specific ways. A required element in an SDN architecture is a 129 component that plans how the network resources will be used and how 130 the devices will be programmed. It is possible to view this 131 component as performing specific computations to place traffic flows 132 within the network given knowledge of the availability of network 133 resources, how other forwarding devices are programmed, and the way 134 that other flows are routed. This is the function and purpose of a 135 PCE, and the way that a PCE integrates into a wider network control 136 system (including an SDN system) is presented in [RFC7491]. 138 In early PCE implementations, where the PCE was used to derive paths 139 for MPLS Label Switched Paths (LSPs), paths were requested by network 140 elements (known as Path Computation Clients (PCCs)), and the results 141 of the path computations were supplied to network elements using the 142 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 143 This protocol was later extended to allow a PCE to send unsolicited 144 requests to the network for LSP establishment [RFC8281]. 146 [RFC8283] introduces the architecture for PCE as a central controller 147 as an extension of the architecture described in [RFC4655] and 148 assumes the continued use of PCEP as the protocol used between PCE 149 and PCC. [RFC8283] further examines the motivations and 150 applicability for PCEP as a Southbound Interface (SBI), and 151 introduces the implications for the protocol. 153 A PCECC can simplify the processing of a distributed control plane by 154 blending it with elements of SDN and without necessarily completely 155 replacing it. Thus, the LSP can be calculated/set up/initiated and 156 the label-forwarding entries can also be downloaded through a 157 centralized PCE server to each network device along the path while 158 leveraging the existing PCE technologies as much as possible. 160 [RFC9050] specify the procedures and PCEP extensions for using the 161 PCE as the central controller for static P2P LSPs, where LSPs can be 162 provisioned as explicit label instructions at each hop on the end-to- 163 end path. Each router along the path must be told what label- 164 forwarding instructions to program and what resources to reserve. 165 The PCE-based controller keeps a view of the network and determines 166 the paths of the end-to-end LSPs, and the controller uses PCEP to 167 communicate with each router along the path of the end-to-end LSP. 169 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 170 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 171 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 172 PCE has been identified as a suitable application for the computation 173 of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to 174 request path computation for P2MP TE LSPs are described in [RFC8306]. 175 Further [RFC8623] specify the extensions that are necessary in order 176 for the deployment of stateful PCEs to support P2MP TE LSPs as well 177 as the setup, maintenance and teardown of PCE-initiated P2MP LSPs 178 under the stateful PCE model. 180 This document extends [RFC9050] to specify the procedures and PCEP 181 extensions for using the PCE as the central controller for static 182 P2MP LSPs, where LSPs can be provisioned as explicit label 183 instructions at each hop on the end-to-end path with an added 184 functionality of a P2MP branch node. As per [RFC4875], a branch node 185 is an LSR that replicates the incoming data on to one or more 186 outgoing interfaces. [I-D.ietf-teas-pcecc-use-cases] describes the 187 use cases for P2MP in PCECC architecture. 189 2. Terminology 191 Terminologies used in this document is the same as described in the 192 draft [RFC8283]. 194 2.1. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in BCP 199 14 [RFC2119] [RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 3. Basic PCECC Mode 204 Section 3 of [RFC9050] describe the PCECC model of operation. 206 This document extends the functionality to include support for 207 central control instruction for replication at the branch nodes for 208 the P2MP LSP. 210 The rest of the processing at the root node is similar to the 211 existing stateful PCE mechanism for P2MP [RFC8623]. 213 4. Procedures for Using the PCE as a Central Controller (PCECC) for 214 P2MP 216 4.1. Stateful PCE Model 218 Active stateful PCE is described in [RFC8231] and extended for P2MP 219 [RFC8623]. A PCE as a Central Controller (PCECC) reuses the existing 220 active stateful PCE mechanism as much as possible to control the 221 LSPs. 223 [RFC9050] extends PCEP messages - PCInitiate, PCRpt, and PCUpd 224 message for the Central Controller's Instructions (CCI) (label- 225 forwarding instructions in the context of this document). This 226 document specify the procedure for additional instruction for branch 227 node needed for P2MP. 229 4.2. PCECC Capability Advertisement 231 As per Section 5.4 of [RFC9050], during the PCEP initialization 232 phase, PCEP Speakers (PCE or PCC) advertise their support of and 233 willingness to use PCEP extension for the PCECC using a new Path 234 Setup Type (PST) in PATH-SETUP-TYPE-CAPABILITY TLV and a new PCECC- 235 CAPABILITY sub-TLV. 237 A new M bit is added in the PCECC-CAPABILITY sub-TLV to indicate 238 support for PCECC-P2MP. A PCC MUST set the M bit in the PCECC- 239 CAPABILITY sub-TLV and include STATEFUL-PCE-CAPABILITY TLV with the 240 P2MP bits set (as per [RFC8623]) in the OPEN object to support the 241 PCECC P2MP extensions defined in this document. 243 If the M bit is set in PCECC-CAPABILITY sub-TLV and the STATEFUL-PCE- 244 CAPABILITY TLV is not advertised, or is advertised without the N bit 245 set, in the OPEN object, the receiver MUST: 247 * send a PCErr message with Error-Type=19 (Invalid Operation) and 248 Error-value=TBD2 (P2MP capability was not advertised) and 250 * terminate the session. 252 The rest of the processing is as per [RFC9050]. 254 4.3. LSP Operations 256 The PCEP messages pertaining to a PCECC includes the PATH-SETUP-TYPE 257 TLV [RFC8408] in the SRP object [RFC8231] with the PST set to '2' to 258 clearly identify the the PCECC LSP is intended as per [RFC9050]. 260 4.3.1. PCE-Initiated PCECC LSP 262 The LSP instantiation operation is the same as defined in [RFC8281] 263 and [RFC8623]. 265 In order to set up a PCE-Initiated P2MP LSP based on the PCECC 266 mechanism, a PCE sends a PCInitiate message with the PST set to '2' 267 for the PCECC ([RFC9050]) to the ingress PCC (root node). 269 As described in [RFC9050], the label-forwarding instructions from 270 PCECC are sent after the initial PCInitiate and PCRpt exchange. This 271 is done so that the PCEP-specific identifier for the LSP (PLSP-ID) 272 and other LSP identifiers can be obtained from the ingress and can be 273 included in the label-forwarding instruction in the next set of 274 PCInitiate message along the path. 276 An P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for the PCECC 277 P2MP LSPs, it uniquely identifies the P2MP LSP in the network. As 278 per [RFC9050], the LSP object is included in the central controller's 279 instructions (label download) to identify the PCECC P2MP LSP for this 280 instruction. The handling of PLSP-ID is as per [RFC9050]. 282 The ingress PCC (root) also sets the D (Delegate) flag (see 283 [RFC8231]) and C (Create) flag (see [RFC8281]) in the LSP object of 284 the PCRpt message. As per [RFC9050], when the PCE receives this 285 PCRpt message with the PLSP-ID, it assigns labels along the path and 286 sets up the path by sending a PCInitiate message to each node along 287 the path of the P2MP Tree as per the PCECC technique. The CC-ID 288 uniquely identifies the central controller instruction within a PCEP 289 session. Each node along the path (PCC) responds with the PCRpt 290 messages to acknowledge the CCI with the PCRpt messages including the 291 CCI and the LSP objects. The only new extension required is the 292 instructions on the branch nodes for replications to more than one 293 outgoing interface with the respective label. The rest of the 294 operations remains the same as [RFC9050] and [RFC8623]. 296 4.3.2. PCC-Initiated PCECC LSP 298 In order to set up a P2MP LSP based on the PCECC mechanism where the 299 LSP is configured at the PCC, a PCC MUST delegate the P2MP LSP by 300 sending a PCRpt message with the PST set for the PCECC and D 301 (Delegate) flag (see [RFC8623]) set in the LSP object. 303 When a PCE receives the initial PCRpt message with the D flags and 304 PST Type set to '2', it SHOULD calculate the P2MP tree and assign 305 labels along the P2MP tree in addition to setting up the P2MP LSP by 306 sending PCInitiate message to each node along the path of the P2MP 307 LSP as per [RFC9050]. The only new extension required is the 308 instructions on the branch nodes for replications to more than one 309 outgoing interface with the respective label. The rest of the 310 operations remains the same as [RFC9050] and [RFC8623]. 312 4.3.3. Central Control Instructions 314 The CCI for the label operations in PCEP are done via the PCInitiate 315 message as described in [RFC9050], by defining a PCEP Objects for CCI 316 operations. The local label range of each PCC is assumed to be known 317 by both the PCC and the PCE. 319 4.3.3.1. Label Download CCI 321 In order to set up an LSP based on the PCECC, the PCE sends a 322 PCInitiate message to each node along the path to download the label 323 instructions, as described in Section 4.3.1 and Section 4.3.2. 325 The CCI object MUST be included, along with the LSP object in the 326 PCInitiate message. As per [RFC9050], there are at most 2 instances 327 of CCI object in the PCInitiate message. For PCECC-P2MP operations, 328 multiple instances of CCI object for out-labels is allowed. 329 Similarly to acknowledge the central controller instructions, the 330 PCRpt message allows multiple instances of CCI object for PCECC-P2MP 331 operations. 333 The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object for 334 the PCECC based P2MP LSP. The SPEAKER-ENTITY-ID TLV SHOULD be 335 included in LSP object. 337 As described in [RFC9050], if a node (PCC) receives a PCInitiate 338 message that includes a label to download (as part of CCI) that is 339 out of the range set aside for the PCE, it send a PCErr message with 340 Error-type=3 (PCECC failure) and Error-value=1 (Label out of range) 341 ([RFC9050]). If a PCC receives a PCInitiate message but fails to 342 download the label entry, it sends a PCErr message with Error-type=3 343 (PCECC failure) and Error-value=2 (Instruction failed) ([RFC9050]). 345 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 347 +----------+ 348 | R1 | Root node of the P2MP TE LSP 349 +----------+ 350 |6000 351 +----------+ 352 Transit Node | R2 | 353 branch +----------+ 354 * | * * 355 9001* | * *9002 356 * | * * 357 +-----------+ | * +-----------+ 358 | R4 | | * | R5 | Transit Nodes 359 +-----------+ | * +-----------+ 360 * | * * + 361 9003* | * * +9004 362 * | * * + 363 +-----------+ +-----------+ 364 | R3 | | R6 | Leaf Node 365 +-----------+ +-----------+ 366 9005| 367 +-----------+ 368 | R8 | Leaf Node 369 +-----------+ 371 PCECC would provision each node along the path and assign incoming 372 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 373 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 374 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 375 R2 are same as [RFC9050]. The branch node (R2) needs to be 376 instructed to replicate two copies of the incoming packet, and sent 377 towards R4 and R5 with 9001 and 9002 labels respectively). This done 378 via including 3 instances of CCI objects in the PCEP messages, one 379 for each label in the example, 6000 for incoming and 9001/9002 for 380 outgoing (along with remote nexthop). The message and procedure 381 remains exactly as [RFC9050] with only distinction that more than one 382 outgoing CCI MAY be present for the P2MP LSP. 384 4.3.3.2. Label Cleanup CCI 386 In order to delete a P2MP LSP based on the PCECC, the PCE sends a 387 Central Controller Instructions via a PCInitiate message to each node 388 along the path of the P2MP tree to clean up the label-forwarding 389 instruction as per [RFC9050]. In case of branch nodes, all instances 390 of CCIs needs to be present in the PCEP message. 392 4.3.4. PCECC LSP Update 394 In case of a modification of PCECC P2MP LSP with a new path, the 395 procedure, and instructions as described in [RFC9050] apply. 397 4.3.5. Re-delegation and Cleanup 399 In case of a re-delegation and clean up of PCECC P2MP LSP, the 400 procedure, and instructions as described in [RFC9050] apply. 402 4.3.6. Synchronization of Central Controllers Instructions 404 The procedure and instructions are as per [RFC9050]. 406 4.3.7. PCECC LSP State Report 408 An ingress PCC MAY choose to apply any Operations, Administration, 409 and Maintenance (OAM) mechanism to check the status of the LSP in the 410 data plane and MAY further send its status in the PCRpt message (as 411 per [RFC8623]) to the PCE. 413 4.3.8. PCC-Based Allocations 415 The PCE can request the PCC to allocate the label using the 416 PCInitiate message. The procedure and instructions are as per 417 Section 5.5.8 of [RFC9050]. 419 5. PCEP Messages 421 [RFC9050] specify the extension to PCInitiate and PCRpt message for 422 PCECC. For P2P LSP, only two instances of CCI objects can be 423 included. In the case of the P2MP LSP, multiple CCI objects are 424 allowed. The message format and other procedures continue to apply. 426 6. PCEP Objects 428 6.1. OPEN Object 430 6.1.1. PCECC Capability sub-TLV 432 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 433 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 434 CAPABILITY TLV as specified in [RFC9050]. 436 This document adds a new flag (M Bit) in the PCECC-CAPABILITY sub-TLV 437 to indicate the support for P2MP in PCECC. 439 M (PCECC-P2MP-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 440 speaker, it indicates that the PCEP speaker is capable of PCECC-P2MP 441 capability. 443 A PCC MUST set the M Bit in the PCECC-CAPABILITY sub-TLV and set the 444 N (P2MP-CAPABILITY), the M (P2MP-LSP-UPDATE-CAPABILITY), and the P 445 (P2MP-LSP-INSTANTIATION-CAPABILITY) bits (as per [RFC8623]) in the 446 STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support the PCECC-P2MP 447 extensions defined in this document. If the M Bit is set in PCECC- 448 CAPABILITY sub-TLV and the P2MP bits (in the STATEFUL-PCE-CAPABILITY 449 TLV) are not set in the OPEN Object, a PCEP speaker SHOULD send a 450 PCErr message with Error-Type=19 (Invalid Operation) and Error- 451 value=TBD2 (P2MP capability was not advertised) and terminate the 452 session. 454 6.2. PATH-SETUP-TYPE TLV 456 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; [RFC9050] defines a 457 PST value for PCECC as '2', which is applicable for P2MP LSP as well. 459 6.3. CCI Object 461 The CCI object [RFC9050] is used by the PCE to specify the forwarding 462 instructions (label information in the context of this document) to 463 the PCC, and optionally carried within PCInitiate or PCRpt message 464 for label download/report. The CCI Object Type 1 for MPLS Label is 465 defined in [RFC9050], which is used for the P2MP LSPs as well. The 466 address TLVs are defined in [RFC9050], they associate the next-hop 467 information in case of an outgoing label. 469 If a node (PCC) receives a PCInitiate message with more than one CCI 470 with O-bit set for the outgoing label and the node does not support 471 the P2MP branch/replication capability, it MUST respond with PCErr 472 message with Error-Type=2 (Capability not supported) (defined in 473 [RFC5440]). 475 The rest of the processing is same as [RFC9050]. 477 7. Security Considerations 479 As per [RFC8283], the security considerations for a PCE-based 480 controller are a little different from those for any other PCE 481 system. That is, the operation relies heavily on the use and 482 security of PCEP, so consideration should be given to the security 483 features discussed in [RFC5440] and the additional mechanisms 484 described in [RFC8253]. It further lists the vulnerability of a 485 central controller architecture, such as a central point of failure, 486 denial of service, and a focus for interception and modification of 487 messages sent to individual Network Elements (NEs). 489 The security considerations described in [RFC8231], [RFC8281], 490 [RFC8623], and [RFC9050] apply to the extensions described in this 491 document. 493 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 494 be activated on authenticated and encrypted sessions across PCEs and 495 PCCs belonging to the same administrative authority, using Transport 496 Layer Security (TLS) [RFC8253] as per the recommendations and best 497 current practices in [RFC7525] (unless explicitly set aside in 498 [RFC8253]). 500 8. Manageability Considerations 502 8.1. Control of Function and Policy 504 A PCE or PCC implementation SHOULD allow to configure to enable/ 505 disable PCECC-P2MP capability as a global configuration. 507 8.2. Information and Data Models 509 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 510 PCECC capability status. 512 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 513 enable/disable PCECC-P2MP capability. 515 8.3. Liveness Detection and Monitoring 517 Mechanisms defined in this document do not imply any new liveness 518 detection and monitoring requirements in addition to those already 519 listed in [RFC5440]. 521 8.4. Verify Correct Operations 523 Mechanisms defined in this document do not imply any new operation 524 verification requirements in addition to those already listed in 525 [RFC5440] and [RFC8231]. 527 8.5. Requirements On Other Protocols 529 PCEP extensions defined in this document do not put new requirements 530 on other protocols. 532 8.6. Impact On Network Operations 534 PCEP extensions defined in this document do not put new requirements 535 on network operations. 537 9. IANA Considerations 539 9.1. PCECC-CAPABILITY sub-TLV 541 [RFC9050] defines the PCECC-CAPABILITY sub-TLV and requests that IANA 542 creates a registry to manage the value of the PCECC-CAPABILITY sub- 543 TLV's Flag field. IANA is requested to allocate a new bit in the 544 PCECC-CAPABILITY sub-TLV Flag Field registry, as follows: 546 +======+=============+===============+ 547 | Bit | Description | Reference | 548 +======+=============+===============+ 549 | TBD1 | P2MP | This document | 550 +------+-------------+---------------+ 552 Table 1 554 9.2. PCEP-Error Object 556 IANA is requested to allocate a new error value within the "PCEP- 557 ERROR Object Error Types and Values" sub-registry of the PCEP Numbers 558 registry for the following errors: 560 Error-Type Meaning 561 ---------- ------- 562 19 Invalid operation. 564 Error-value = TBD2 : P2MP capability was 565 not advertised 567 The Reference is marked as "This document". 569 10. References 571 10.1. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 579 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 580 DOI 10.17487/RFC5440, March 2009, 581 . 583 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 584 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 585 May 2017, . 587 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 588 Computation Element Communication Protocol (PCEP) 589 Extensions for Stateful PCE", RFC 8231, 590 DOI 10.17487/RFC8231, September 2017, 591 . 593 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 594 "PCEPS: Usage of TLS to Provide a Secure Transport for the 595 Path Computation Element Communication Protocol (PCEP)", 596 RFC 8253, DOI 10.17487/RFC8253, October 2017, 597 . 599 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 600 Computation Element Communication Protocol (PCEP) 601 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 602 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 603 . 605 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 606 Path Computation Element (PCE) Protocol Extensions for 607 Usage with Point-to-Multipoint TE Label Switched Paths 608 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 609 . 611 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 612 Computation Element Communication Protocol (PCEP) 613 Procedures and Extensions for Using the PCE as a Central 614 Controller (PCECC) of LSPs", RFC 9050, 615 DOI 10.17487/RFC9050, July 2021, 616 . 618 10.2. Informative References 620 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 621 Computation Element (PCE)-Based Architecture", RFC 4655, 622 DOI 10.17487/RFC4655, August 2006, 623 . 625 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 626 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 627 June 2007, . 629 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 630 Yasukawa, Ed., "Extensions to Resource Reservation 631 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 632 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 633 DOI 10.17487/RFC4875, May 2007, 634 . 636 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 637 Path Computation Element (PCE) to Point-to-Multipoint 638 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 639 DOI 10.17487/RFC5671, October 2009, 640 . 642 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 643 Margaria, "Requirements for GMPLS Applications of PCE", 644 RFC 7025, DOI 10.17487/RFC7025, September 2013, 645 . 647 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 648 Computation Element Architecture", RFC 7399, 649 DOI 10.17487/RFC7399, October 2014, 650 . 652 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 653 Hardwick, "Path Computation Element Communication Protocol 654 (PCEP) Management Information Base (MIB) Module", 655 RFC 7420, DOI 10.17487/RFC7420, December 2014, 656 . 658 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 659 Application-Based Network Operations", RFC 7491, 660 DOI 10.17487/RFC7491, March 2015, 661 . 663 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 664 "Recommendations for Secure Use of Transport Layer 665 Security (TLS) and Datagram Transport Layer Security 666 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 667 2015, . 669 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 670 Architecture for Use of PCE and the PCE Communication 671 Protocol (PCEP) in a Network with Central Control", 672 RFC 8283, DOI 10.17487/RFC8283, December 2017, 673 . 675 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 676 "Extensions to the Path Computation Element Communication 677 Protocol (PCEP) for Point-to-Multipoint Traffic 678 Engineering Label Switched Paths", RFC 8306, 679 DOI 10.17487/RFC8306, November 2017, 680 . 682 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 683 Hardwick, "Conveying Path Setup Type in PCE Communication 684 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 685 July 2018, . 687 [I-D.ietf-teas-pcecc-use-cases] 688 Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., 689 Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. 690 Gulida, "The Use Cases for Path Computation Element (PCE) 691 as a Central Controller (PCECC).", Work in Progress, 692 Internet-Draft, draft-ietf-teas-pcecc-use-cases-08, 25 693 October 2021, . 696 [I-D.ietf-pce-pcep-yang] 697 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 698 "A YANG Data Model for Path Computation Element 699 Communications Protocol (PCEP)", Work in Progress, 700 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 701 2022, . 704 Appendix A. Contributor Addresses 705 Dhruv Dhody 706 Huawei Technologies 707 Divyashree Techno Park, Whitefield 708 Bangalore, Karnataka 560066 709 India 711 EMail: dhruv.ietf@gmail.com 713 Udayasree Palle 715 EMail: udayasreereddy@gmail.com 717 Authors' Addresses 719 Zhenbin Li 720 Huawei Technologies 721 Huawei Bld., No.156 Beiqing Rd. 722 Beijing 723 100095 724 China 725 Email: lizhenbin@huawei.com 727 Shuping Peng 728 Huawei Technologies 729 Huawei Bld., No.156 Beiqing Rd. 730 Beijing 731 100095 732 China 733 Email: pengshuping@huawei.com 735 Xuesong Geng 736 Huawei Technologies 737 China 738 Email: gengxuesong@huawei.com 740 Mahendra Singh Negi 741 RtBrick Inc 742 N-17L, 18th Cross Rd, HSR Layout 743 Bangalore 560102 744 Karnataka 745 India 746 Email: mahend.ietf@gmail.com