idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-p2mp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 1157 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 (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-10 -- 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-06 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 Summary: 0 errors (**), 0 flaws (~~), 5 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: August 25, 2021 Huawei Technologies 6 M. Negi 7 RtBrick Inc 8 February 21, 2021 10 PCEP Procedures and Protocol Extensions for Using PCE as a Central 11 Controller (PCECC) for P2MP LSPs 12 draft-dhody-pce-pcep-extension-pce-controller-p2mp-06 14 Abstract 16 The Path Computation Element (PCE) is a core component of Software- 17 Defined Networking (SDN) systems. It can compute optimal paths for 18 traffic across a network and can also update the paths to reflect 19 changes in the network or traffic demands. 21 The PCE has been identified as an appropriate technology for the 22 determination of the paths of point-to-multipoint (P2MP) TE Label 23 Switched Paths (LSPs). 25 PCE was developed to derive paths for MPLS P2MP LSPs, which are 26 supplied to the head end (root) of the LSP using PCEP. PCEP has been 27 proposed as a control protocol to allow the PCE to be fully enabled 28 as a central controller. 30 A PCE-based Central Controller (PCECC) can simplify the processing of 31 a distributed control plane by blending it with elements of SDN and 32 without necessarily completely replacing it. Thus, the P2MP LSP can 33 be calculated/set up/initiated and the label forwarding entries can 34 also be downloaded through a centralized PCE server to each network 35 device along the P2MP path, while leveraging the existing PCE 36 technologies as much as possible. 38 This document specifies the procedures and PCEP extensions for using 39 the PCE as the central controller for P2MP TE LSP by provisioning 40 labels along the path of the static P2MP LSP. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 25, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Procedures for Using the PCE as a Central Controller (PCECC) 81 for P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 83 4.2. PCECC Capability Advertisement . . . . . . . . . . . . . 6 84 4.3. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 85 4.3.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 7 86 4.3.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 7 87 4.3.3. Central Control Instructions . . . . . . . . . . . . 8 88 4.3.3.1. Label Download CCI . . . . . . . . . . . . . . . 8 89 4.3.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 9 90 4.3.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 10 91 4.3.5. Re-Delegation and Clean up . . . . . . . . . . . . . 10 92 4.3.6. Synchronization of Central Controllers Instructions . 10 93 4.3.7. PCECC LSP State Report . . . . . . . . . . . . . . . 10 94 4.3.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 10 95 5. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 96 6. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10 97 6.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10 98 6.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 99 6.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 11 100 6.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 11 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 102 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 103 8.1. Control of Function and Policy . . . . . . . . . . . . . 12 104 8.2. Information and Data Models . . . . . . . . . . . . . . . 12 105 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 106 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 107 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 108 8.6. Impact On Network Operations . . . . . . . . . . . . . . 13 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 110 9.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 13 111 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 13 112 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 115 11.2. Informative References . . . . . . . . . . . . . . . . . 15 116 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 17 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 119 1. Introduction 121 The Path Computation Element (PCE) [RFC4655] was developed to offload 122 the path computation function from routers in an MPLS traffic- 123 engineered network. Since then, the role and function of the PCE has 124 grown to cover a number of other uses (such as GMPLS [RFC7025]) and 125 to allow delegated control [RFC8231] and PCE-initiated use of network 126 resources [RFC8281]. 128 According to [RFC7399], Software-Defined Networking (SDN) refers to a 129 separation between the control elements and the forwarding components 130 so that software running in a centralized system, called a 131 controller, can act to program the devices in the network to behave 132 in specific ways. A required element in an SDN architecture is a 133 component that plans how the network resources will be used and how 134 the devices will be programmed. It is possible to view this 135 component as performing specific computations to place traffic flows 136 within the network given knowledge of the availability of network 137 resources, how other forwarding devices are programmed, and the way 138 that other flows are routed. This is the function and purpose of a 139 PCE, and the way that a PCE integrates into a wider network control 140 system (including an SDN system) is presented in [RFC7491]. 142 In early PCE implementations, where the PCE was used to derive paths 143 for MPLS Label Switched Paths (LSPs), paths were requested by network 144 elements (known as Path Computation Clients (PCCs)), and the results 145 of the path computations were supplied to network elements using the 146 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 147 This protocol was later extended to allow a PCE to send unsolicited 148 requests to the network for LSP establishment [RFC8281]. 150 [RFC8283] introduces the architecture for PCE as a central controller 151 as an extension of the architecture described in [RFC4655] and 152 assumes the continued use of PCEP as the protocol used between PCE 153 and PCC. [RFC8283] further examines the motivations and 154 applicability for PCEP as a Southbound Interface (SBI), and 155 introduces the implications for the protocol. 157 A PCE-based Central Controller (PCECC) can simplify the processing of 158 a distributed control plane by blending it with elements of SDN and 159 without necessarily completely replacing it. Thus, the LSP can be 160 calculated/setup/initiated and the label forwarding entries can also 161 be downloaded through a centralized PCE server to each network 162 devices along the path while leveraging the existing PCE technologies 163 as much as possible. 165 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 166 procedures and PCEP extensions for using the PCE as the central 167 controller for static P2P LSPs, where LSPs can be provisioned as 168 explicit label instructions at each hop on the end-to-end path. Each 169 router along the path must be told what label-forwarding instructions 170 to program and what resources to reserve. The PCE-based controller 171 keeps a view of the network and determines the paths of the end-to- 172 end LSPs, and the controller uses PCEP to communicate with each 173 router along the path of the end-to-end LSP. 175 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 176 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 177 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 178 PCE has been identified as a suitable application for the computation 179 of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to 180 request path computation for P2MP TE LSPs are described in [RFC8306]. 181 Further [RFC8623] specify the extensions that are necessary in order 182 for the deployment of stateful PCEs to support P2MP TE LSPs as well 183 as the setup, maintenance and teardown of PCE-initiated P2MP LSPs 184 under the stateful PCE model. 186 This document extends 187 [I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the 188 procedures and PCEP extensions for using the PCE as the central 189 controller for static P2MP LSPs, where LSPs can be provisioned as 190 explicit label instructions at each hop on the end-to-end path with 191 an added functionality of a P2MP branch node. As per [RFC4875], a 192 branch node is an LSR that replicates the incoming data on to one or 193 more outgoing interfaces. [I-D.ietf-teas-pcecc-use-cases] describes 194 the use cases for P2MP in PCECC architecture. 196 1.1. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 2. Terminology 206 Terminologies used in this document is the same as described in the 207 draft [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 209 3. Basic PCECC Mode 211 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in 212 this mode LSPs are provisioned as explicit label instructions at each 213 hop on the end-to-end path. Each router along the path must be told 214 what label forwarding instructions to program and what resources to 215 reserve. The controller uses PCEP to communicate with each router 216 along the path of the end-to-end LSP. 218 Note that the PCE-based controller will take responsibility for 219 managing some part of the MPLS label space for each of the routers 220 that it controls, and may taker wider responsibility for partitioning 221 the label space for each router and allocating different parts for 222 different uses. As per 223 [I-D.ietf-pce-pcep-extension-for-pce-controller], the PCC must not 224 make allocations from the label space set aside for the PCE to avoid 225 overlap and collisions of label allocations. This is also described 226 in section 3.1.2. of [RFC8283]. For the purpose of this document, it 227 is assumed that the label range to be used by a PCE is known and set 228 on both PCEP peers. A future extension could add the capability to 229 advertise the range via possible PCEP extensions as well (see 230 [I-D.li-pce-controlled-id-space]). The rest of the processing is 231 similar to the existing stateful PCE mechanism. 233 This document extends the functionality to include support for 234 central control instruction for replication at the branch nodes. 236 The rest of the processing is similar to the existing stateful PCE 237 mechanism for P2MP [RFC8623]. 239 4. Procedures for Using the PCE as a Central Controller (PCECC) for 240 P2MP 242 4.1. Stateful PCE Model 244 Active stateful PCE is described in [RFC8231] and extended for P2MP 245 [RFC8623]. PCE as a Central Controller (PCECC) reuses the existing 246 active stateful PCE mechanism as much as possible to control the 247 LSPs. 249 [I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP 250 messages - PCRpt, PCInitiate message for the Central Controller's 251 Instructions (CCI) (label forwarding instructions in the context of 252 this document). This document specify the procedure for additional 253 instruction for branch node needed for P2MP. 255 4.2. PCECC Capability Advertisement 257 As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP 258 Initialization Phase, PCEP Speakers (PCE or PCC) advertise their 259 support of the PCECC extensions by sending a PATH-SETUP-TYPE- 260 CAPABILITY TLV in the OPEN object with this PST=TBD 261 [I-D.ietf-pce-pcep-extension-for-pce-controller] included in the PST 262 list. 264 [I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the 265 PCECC Capability sub-TLV. A new M-bit is added in the PCECC- 266 CAPABILITY sub-TLV to indicate support for PCECC-P2MP. A PCC MUST 267 set M-bit in the PCECC-CAPABILITY sub-TLV and include STATEFUL-PCE- 268 CAPABILITY TLV with the P2MP bits set ([RFC8623]) in the OPEN Object 269 to support the PCECC P2MP extensions defined in this document. If 270 the M-bit is set in PCECC-CAPABILITY sub-TLV and N-bit in the 271 STATEFUL-PCE-CAPABILITY TLV is not set in the OPEN Object, the PCE 272 SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) 273 and Error-value=TBD2 (P2MP capability was not advertised) and 274 terminate the session. 276 The rest of the processing is as per 277 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 279 4.3. LSP Operations 281 The PCEP messages pertaining to a PCECC includes the PATH-SETUP-TYPE 282 TLV [RFC8408] with PST=TBD 283 [I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to 284 identify the PCECC LSP is intended as per 285 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 287 4.3.1. PCE-Initiated PCECC LSP 289 The LSP Instantiation operation is the same as defined in [RFC8281] 290 and [RFC8623]. 292 In order to set up a PCE-Initiated P2MP LSP based on the PCECC 293 mechanism, a PCE sends PCInitiate message with Path Setup Type set to 294 TBD for PCECC ([I-D.ietf-pce-pcep-extension-for-pce-controller]) to 295 the ingress PCC (root node). 297 P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for the PCECC P2MP 298 LSPs, the tuple uniquely identifies the P2MP LSP in the network. As 299 per [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object 300 is included in the central controller's instructions (label download) 301 to identify the PCECC P2MP LSP for this instruction. The handling of 302 PLSP-ID is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 304 The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 305 (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message. 306 The PCC responds with a PCRpt message with the status set to "GOING- 307 UP" and carrying the assigned PLSP-ID. As per 308 [I-D.ietf-pce-pcep-extension-for-pce-controller] when the PCE 309 receives this PCRpt message with the PLSP-ID, it assigns labels along 310 the path; and sets up the path by sending a PCInitiate message to 311 each node along the path of the P2MP Tree as per the PCECC technique. 312 The CC-ID uniquely identifies the central controller instruction 313 within a PCEP session. Each PCC further responds with the PCRpt 314 messages including the central controller instruction (CCI) and the 315 LSP objects. 317 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the 318 label forwarding instructions from PCECC are sent after the initial 319 PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and 320 other LSP identifiers can be obtained from the ingress and can be 321 included in the label forwarding instruction in the next PCInitiate 322 message. 324 4.3.2. PCC-Initiated PCECC LSP 326 In order to set up a P2MP LSP based on the PCECC mechanism where the 327 LSP is configured at the PCC, a PCC MUST delegate the P2MP LSP by 328 sending a PCRpt message with PST set for PCECC and D (Delegate) flag 329 (see [RFC8623]) set in the LSP object. 331 When a PCE receives the initial PCRpt message with the D flags and 332 PST Type set to TBD, it SHOULD calculate the P2MP tree and assigns 333 labels along the P2MP tree; and set up the P2MP LSP by sending 334 PCInitiate message to each node along the path of the P2MP LSP as per 336 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension 337 required is the instructions on the branch nodes for replications to 338 more than one outgoing interface with the respective label. The rest 339 of the operations remains the same as 340 [I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623]. 342 4.3.3. Central Control Instructions 344 The central controller's instructions (CCI) for the label operations 345 in PCEP is done via the PCInitiate message as described in 346 [I-D.ietf-pce-pcep-extension-for-pce-controller], by defining a PCEP 347 Objects for CCI operations. The local label range of each PCC is 348 assumed to be known by both the PCC and the PCE. 350 4.3.3.1. Label Download CCI 352 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 353 message to each node along the path to download the Label instruction 354 as described in Section 4.3.1 and Section 4.3.2. 356 The CCI object MUST be included, along with the LSP object in the 357 PCInitiate message. As per 358 [I-D.ietf-pce-pcep-extension-for-pce-controller], there are at most 2 359 instances of CCI object in the PCInitiate message. For PCECC-P2MP 360 operations, multiple instances of CCI object for out-labels is 361 allowed. Similarly to acknowledge the central controller 362 instructions, the PCRpt message allows multiple instances of CCI 363 object for PCECC-P2MP operations. 365 The LSP-IDENTIFIER TLV MUST be included in the LSP object. The 366 SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 368 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if 369 a node (PCC) receives a PCInitiate message which includes a Label to 370 download, as part of CCI, that is out of the range set aside for the 371 PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and 372 Error-value=TBD (Label out of range) (defined in 373 [I-D.ietf-pce-pcep-extension-for-pce-controller]). If a PCC receives 374 a PCInitiate message but fails to download the Label entry, it sends 375 a PCErr message with Error-type=TBD (PCECC failure) and Error- 376 value=TBD (Instruction failed) (defined in 377 [I-D.ietf-pce-pcep-extension-for-pce-controller]). 379 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 380 +----------+ 381 | R1 | Root node of the P2MP TE LSP 382 +----------+ 383 |6000 384 +----------+ 385 Transit Node | R2 | 386 branch +----------+ 387 * | * * 388 9001* | * *9002 389 * | * * 390 +-----------+ | * +-----------+ 391 | R4 | | * | R5 | Transit Nodes 392 +-----------+ | * +-----------+ 393 * | * * + 394 9003* | * * +9004 395 * | * * + 396 +-----------+ +-----------+ 397 | R3 | | R6 | Leaf Node 398 +-----------+ +-----------+ 399 9005| 400 +-----------+ 401 | R8 | Leaf Node 402 +-----------+ 404 PCECC would provision each node along the path and assign incoming 405 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 406 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 407 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 408 R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The 409 branch node (R2) needs to be instructed to replicate two copies of 410 the incoming packet, and sent towards R4 and R5 with 9001 and 9002 411 labels respectively). This done via including 3 instances of CCI 412 objects in the PCEP messages, one for each label in the example, 6000 413 for incoming and 9001/9002 for outgoing (along with remote nexthop). 414 The message and procedure remains exactly as 415 [I-D.ietf-pce-pcep-extension-for-pce-controller] with only 416 distinction that more than one outgoing CCI MAY be present for the 417 P2MP LSP. 419 4.3.3.2. Label Clean up CCI 421 In order to delete a P2MP LSP based on PCECC, the PCE sends a central 422 controller instructions via a PCInitiate message to each node along 423 the path of the P2MP tree to clean up the Label forwarding 424 instruction as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 425 In case of branch nodes, all instances of CCIs needs to be present in 426 the PCEP message. 428 4.3.4. PCECC LSP Update 430 In case of a modification of PCECC P2MP LSP with a new path, the 431 procedure, and instructions as described in 432 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 434 4.3.5. Re-Delegation and Clean up 436 In case of a re-delegation and clean up of PCECC P2MP LSP, the 437 procedure, and instructions as described in 438 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 440 4.3.6. Synchronization of Central Controllers Instructions 442 The procedure and instructions are as per 443 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 445 4.3.7. PCECC LSP State Report 447 An ingress PCC MAY choose to apply any OAM mechanism to check the 448 status of LSP in the Data plane and MAY further send its status in 449 PCRpt message (as per [RFC8623]) to the PCE. 451 4.3.8. PCC-Based Allocations 453 The PCE can request the PCC to allocate the label using the 454 PCInitiate message. The procedure and instructions are as per 455 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 457 5. PCEP Messages 459 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 460 extension to PCInitiate and PCRpt message for PCECC. For P2P LSP, 461 only two instances of CCI objects can be included. In the case of 462 the P2MP LSP, multiple CCI objects are allowed. The message format 463 and other procedures continue to apply. 465 6. PCEP Objects 467 6.1. OPEN Object 469 6.1.1. PCECC Capability sub-TLV 471 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 472 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 473 CAPABILITY TLV as specified in 474 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 476 This document adds a new flag (M-bit) in the PCECC-CAPABILITY sub-TLV 477 to indicate the support for P2MP in PCECC. 479 M (PCECC-P2MP-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 480 speaker, it indicates that the PCEP speaker is capable of PCECC-P2MP 481 capability. 483 A PCC MUST set the M-bit in the PCECC-CAPABILITY sub-TLV and set the 484 N (P2MP-CAPABILITY), the M (P2MP-LSP-UPDATE-CAPABILITY), and the P 485 (P2MP-LSP-INSTANTIATION-CAPABILITY) bits (as per [RFC8623]) in the 486 STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support the PCECC-P2MP 487 extensions defined in this document. If the M-bit is set in PCECC- 488 CAPABILITY sub-TLV and the P2MP bits (in the STATEFUL-PCE-CAPABILITY 489 TLV) are not set in the OPEN Object, a PCEP speaker SHOULD send a 490 PCErr message with Error-Type=19 (Invalid Operation) and Error- 491 value=TBD2 (P2MP capability was not advertised) and terminate the 492 session. 494 6.2. PATH-SETUP-TYPE TLV 496 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; 497 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value 498 for PCECC, which is applicable for P2MP LSP as well. 500 6.3. CCI Object 502 The Central Control Instructions (CCI) Object 503 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE 504 to specify the forwarding instructions (Label information in the 505 context of this document) to the PCC, and optionally carried within 506 PCInitiate or PCRpt message for label download/report. The CCI 507 Object Type 1 for MPLS Label is defined in 508 [I-D.ietf-pce-pcep-extension-for-pce-controller], which is used for 509 the P2MP LSPs as well. The address TLVs are defined in 510 [I-D.ietf-pce-pcep-extension-for-pce-controller], they associate the 511 next-hop information in case of an outgoing label. 513 If a node (PCC) receives a PCInitiate message with more than one CCI 514 with O-bit set for the outgoing label and the node does not support 515 the P2MP branch/replication capability, it MUST respond with PCErr 516 message with Error-Type=2 (Capability not supported) (defined in 517 [RFC5440]). 519 The rest of the processing is same as 520 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 522 7. Security Considerations 524 As per [RFC8283], the security considerations for a PCE-based 525 controller is a little different from those for any other PCE system. 526 That is, the operation relies heavily on the use and security of 527 PCEP, so consideration should be given to the security features 528 discussed in [RFC5440] and the additional mechanisms described in 529 [RFC8253]. It further lists the vulnerability of a central 530 controller architecture, such as a central point of failure, denial- 531 of-service, and a focus for interception and modification of messages 532 sent to individual NEs. 534 The security considerations described in [RFC8231], [RFC8281], 535 [RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] apply 536 to the extensions described in this document. 538 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 539 be activated on authenticated and encrypted sessions across PCEs and 540 PCCs belonging to the same administrative authority, using Transport 541 Layer Security (TLS) [RFC8253] as per the recommendations and best 542 current practices in [RFC7525] (unless explicitly set aside in 543 [RFC8253]). 545 8. Manageability Considerations 547 8.1. Control of Function and Policy 549 A PCE or PCC implementation SHOULD allow to configure to enable/ 550 disable PCECC-P2MP capability as a global configuration. 552 8.2. Information and Data Models 554 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 555 PCECC capability status. 557 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 558 enable/disable PCECC-P2MP capability. 560 8.3. Liveness Detection and Monitoring 562 Mechanisms defined in this document do not imply any new liveness 563 detection and monitoring requirements in addition to those already 564 listed in [RFC5440]. 566 8.4. Verify Correct Operations 568 Mechanisms defined in this document do not imply any new operation 569 verification requirements in addition to those already listed in 570 [RFC5440] and [RFC8231]. 572 8.5. Requirements On Other Protocols 574 PCEP extensions defined in this document do not put new requirements 575 on other protocols. 577 8.6. Impact On Network Operations 579 PCEP extensions defined in this document do not put new requirements 580 on network operations. 582 9. IANA Considerations 584 9.1. PCECC-CAPABILITY sub-TLV 586 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 587 CAPABILITY sub-TLV and requests that IANA creates a registry to 588 manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. IANA 589 is requested to allocate a new bit in the PCECC-CAPABILITY sub-TLV 590 Flag Field registry, as follows: 592 Bit Description Reference 593 TBD1 P2MP This document 595 9.2. PCEP-Error Object 597 IANA is requested to allocate a new error value within the "PCEP- 598 ERROR Object Error Types and Values" sub-registry of the PCEP Numbers 599 registry for the following errors: 601 Error-Type Meaning 602 ---------- ------- 603 19 Invalid operation. 605 Error-value = TBD2 : P2MP capability was 606 not advertised 608 The Reference is marked as "This document". 610 10. Acknowledgments 612 11. References 614 11.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 622 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 623 DOI 10.17487/RFC5440, March 2009, 624 . 626 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 627 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 628 May 2017, . 630 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 631 Computation Element Communication Protocol (PCEP) 632 Extensions for Stateful PCE", RFC 8231, 633 DOI 10.17487/RFC8231, September 2017, 634 . 636 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 637 "PCEPS: Usage of TLS to Provide a Secure Transport for the 638 Path Computation Element Communication Protocol (PCEP)", 639 RFC 8253, DOI 10.17487/RFC8253, October 2017, 640 . 642 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 643 Computation Element Communication Protocol (PCEP) 644 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 645 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 646 . 648 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 649 Path Computation Element (PCE) Protocol Extensions for 650 Usage with Point-to-Multipoint TE Label Switched Paths 651 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 652 . 654 [I-D.ietf-pce-pcep-extension-for-pce-controller] 655 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 656 Procedures and Protocol Extensions for Using PCE as a 657 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 658 extension-for-pce-controller-10 (work in progress), 659 January 2021. 661 11.2. Informative References 663 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 664 Element (PCE)-Based Architecture", RFC 4655, 665 DOI 10.17487/RFC4655, August 2006, 666 . 668 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 669 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 670 June 2007, . 672 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 673 Yasukawa, Ed., "Extensions to Resource Reservation 674 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 675 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 676 DOI 10.17487/RFC4875, May 2007, 677 . 679 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 680 Path Computation Element (PCE) to Point-to-Multipoint 681 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 682 DOI 10.17487/RFC5671, October 2009, 683 . 685 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 686 Margaria, "Requirements for GMPLS Applications of PCE", 687 RFC 7025, DOI 10.17487/RFC7025, September 2013, 688 . 690 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 691 Computation Element Architecture", RFC 7399, 692 DOI 10.17487/RFC7399, October 2014, 693 . 695 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 696 Hardwick, "Path Computation Element Communication Protocol 697 (PCEP) Management Information Base (MIB) Module", 698 RFC 7420, DOI 10.17487/RFC7420, December 2014, 699 . 701 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 702 Application-Based Network Operations", RFC 7491, 703 DOI 10.17487/RFC7491, March 2015, 704 . 706 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 707 "Recommendations for Secure Use of Transport Layer 708 Security (TLS) and Datagram Transport Layer Security 709 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 710 2015, . 712 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 713 Architecture for Use of PCE and the PCE Communication 714 Protocol (PCEP) in a Network with Central Control", 715 RFC 8283, DOI 10.17487/RFC8283, December 2017, 716 . 718 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 719 "Extensions to the Path Computation Element Communication 720 Protocol (PCEP) for Point-to-Multipoint Traffic 721 Engineering Label Switched Paths", RFC 8306, 722 DOI 10.17487/RFC8306, November 2017, 723 . 725 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 726 Hardwick, "Conveying Path Setup Type in PCE Communication 727 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 728 July 2018, . 730 [I-D.ietf-teas-pcecc-use-cases] 731 Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang, 732 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 733 Gulida, "The Use Cases for Path Computation Element (PCE) 734 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 735 use-cases-06 (work in progress), September 2020. 737 [I-D.ietf-pce-pcep-yang] 738 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 739 YANG Data Model for Path Computation Element 740 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 741 yang-15 (work in progress), October 2020. 743 [I-D.li-pce-controlled-id-space] 744 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 745 Controlled ID Space", draft-li-pce-controlled-id-space-07 746 (work in progress), October 2020. 748 Appendix A. Contributor Addresses 750 Dhruv Dhody 751 Huawei Technologies 752 Divyashree Techno Park, Whitefield 753 Bangalore, Karnataka 560066 754 India 756 EMail: dhruv.ietf@gmail.com 758 Udayasree Palle 760 EMail: udayasreereddy@gmail.com 762 Authors' Addresses 764 Zhenbin Li 765 Huawei Technologies 766 Huawei Bld., No.156 Beiqing Rd. 767 Beijing 100095 768 China 770 EMail: lizhenbin@huawei.com 772 Shuping Peng 773 Huawei Technologies 774 Huawei Bld., No.156 Beiqing Rd. 775 Beijing 100095 776 China 778 EMail: pengshuping@huawei.com 780 Xuesong Geng 781 Huawei Technologies 782 China 784 EMail: gengxuesong@huawei.com 785 Mahendra Singh Negi 786 RtBrick Inc 787 N-17L, 18th Cross Rd, HSR Layout 788 Bangalore, Karnataka 560102 789 India 791 EMail: mahend.ietf@gmail.com