idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-p2mp-04.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 (July 13, 2020) is 1382 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-05 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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: January 14, 2021 Huawei Technologies 6 M. Negi 7 RtBrick India 8 July 13, 2020 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-04 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/setup/initiated and the label forwarding entries can 34 also be downloaded through a centralized PCE server to each network 35 devices along the P2MP path while leveraging the existing PCE 36 technologies as much as possible. 38 This document specifies the procedures and PCEP protocol extensions 39 for using the PCE as the central controller for P2MP TE LSP. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 14, 2021. 58 Copyright Notice 60 Copyright (c) 2020 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Procedures for Using the PCE as the Central Controller 80 (PCECC) for P2MP . . . . . . . . . . . . . . . . . . . . . . 5 81 4.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 5 82 4.2. PCECC Capability Advertisement . . . . . . . . . . . . . 6 83 4.3. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 84 4.3.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 6 85 4.3.2. Central Control Instructions . . . . . . . . . . . . 7 86 4.3.2.1. Label Download CCI . . . . . . . . . . . . . . . 7 87 4.3.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 8 88 4.3.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 9 89 4.3.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 9 90 4.3.5. Re-Delegation and Cleanup . . . . . . . . . . . . . . 9 91 4.3.6. Synchronization of Central Controllers Instructions . 9 92 4.3.7. PCECC LSP State Report . . . . . . . . . . . . . . . 9 93 5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10 95 5.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 97 5.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 98 5.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 100 7. Manageability Considerations . . . . . . . . . . . . . . . . 11 101 7.1. Control of Function and Policy . . . . . . . . . . . . . 11 102 7.2. Information and Data Models . . . . . . . . . . . . . . . 11 103 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 104 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 105 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 106 7.6. Impact On Network Operations . . . . . . . . . . . . . . 11 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 108 8.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 12 109 8.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 12 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 113 10.2. Informative References . . . . . . . . . . . . . . . . . 13 114 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 16 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 117 1. Introduction 119 The Path Computation Element (PCE) [RFC4655] was developed to offload 120 path computation function from routers in an MPLS traffic-engineered 121 network. Since then, the role and function of the PCE has grown to 122 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 123 delegated control [RFC8231] and PCE-initiated use of network 124 resources [RFC8281]. 126 According to [RFC7399], Software-Defined Networking (SDN) refers to a 127 separation between the control elements and the forwarding components 128 so that software running in a centralized system, called a 129 controller, can act to program the devices in the network to behave 130 in specific ways. A required element in an SDN architecture is a 131 component that plans how the network resources will be used and how 132 the devices will be programmed. It is possible to view this 133 component as performing specific computations to place traffic flows 134 within the network given knowledge of the availability of network 135 resources, how other forwarding devices are programmed, and the way 136 that other flows are routed. This is the function and purpose of a 137 PCE, and the way that a PCE integrates into a wider network control 138 system (including an SDN system) is presented in [RFC7491]. 140 In early PCE implementations, where the PCE was used to derive paths 141 for MPLS Label Switched Paths (LSPs), paths were requested by network 142 elements (known as Path Computation Clients (PCCs)), and the results 143 of the path computations were supplied to network elements using the 144 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 146 This protocol was later extended to allow a PCE to send unsolicited 147 requests to the network for LSP establishment [RFC8281]. 149 [RFC8283] introduces the architecture for PCE as a central controller 150 as an extension of the architecture described in [RFC4655] and 151 assumes the continued use of PCEP as the protocol used between PCE 152 and PCC. [RFC8283] further examines the motivations and 153 applicability for PCEP as a Southbound Interface (SBI), and 154 introduces the implications for the protocol. 156 A PCE-based central controller (PCECC) can simplify the processing of 157 a distributed control plane by blending it with elements of SDN and 158 without necessarily completely replacing it. Thus, the LSP can be 159 calculated/setup/initiated and the label forwarding entries can also 160 be downloaded through a centralized PCE server to each network 161 devices along the path while leveraging the existing PCE technologies 162 as much as possible. 164 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 165 procedures and PCEP protocol extensions for using the PCE as the 166 central controller for static P2P LSPs, where LSPs can be provisioned 167 as explicit label instructions at each hop on the end-to-end path. 168 Each router along the path must be told what label-forwarding 169 instructions to program and what resources to reserve. The PCE-based 170 controller keeps a view of the network and determines the paths of 171 the end-to-end LSPs, and the controller uses PCEP to communicate with 172 each router along the path of the end-to-end LSP. 174 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 175 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 176 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 177 PCE has been identified as a suitable application for the computation 178 of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to 179 request path computation for P2MP TE LSPs are described in [RFC8306]. 180 Further [RFC8623] specify the extensions that are necessary in order 181 for the deployment of stateful PCEs to support P2MP TE LSPs as well 182 as the setup, maintenance and teardown of PCE-initiated P2MP LSPs 183 under the stateful PCE model. 185 This document extends 186 [I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the 187 procedures and PCEP protocol extensions for using the PCE as the 188 central controller for static P2MP LSPs, where LSPs can be 189 provisioned as explicit label instructions at each hop on the end-to- 190 end path with an added functionality of a P2MP branch node. As per 191 [RFC4875], a branch node is an LSR that replicates the incoming data 192 on to one or more outgoing interfaces. 194 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for P2MP in 195 PCECC architecture. 197 1.1. Requirements Language 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 2. Terminology 207 Terminologies used in this document is same as described in the draft 208 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 210 3. Basic PCECC Mode 212 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in 213 this mode LSPs are provisioned as explicit label instructions at each 214 hop on the end-to-end path. Each router along the path must be told 215 what label forwarding instructions to program and what resources to 216 reserve. The controller uses PCEP to communicate with each router 217 along the path of the end-to-end LSP. Note that the PCE-based 218 controller will take responsibility for managing some part of the 219 MPLS label space for each of the routers that it controls, and may 220 taker wider responsibility for partitioning the label space for each 221 router and allocating different parts for different uses. This is 222 also described in section 3.1.2. of [RFC8283]. For the purpose of 223 this document, it is assumed that label range to be used by a PCE is 224 known and set on both PCEP peers. A future extension could add this 225 capability to advertise the range via possible PCEP extensions as 226 well. 228 This document extends the functionality to include support for 229 central control instruction for replication at the branch nodes. 231 The rest of processing is similar to the existing stateful PCE 232 mechanism for P2MP. 234 4. Procedures for Using the PCE as the Central Controller (PCECC) for 235 P2MP 237 4.1. Stateful PCE Model 239 Active stateful PCE is described in [RFC8231] and extended for P2MP 240 [RFC8623]. PCE as a central controller (PCECC) reuses existing 241 Active stateful PCE mechanism as much as possible to control the LSP. 243 [I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP 244 messages - PCRpt, PCInitiate, PCUpd message for the Central 245 Controller's Instructions (CCI) (label forwarding instructions in the 246 context of this document). This documents specify the procedure for 247 additional instruction for branch node needed for P2MP. 249 4.2. PCECC Capability Advertisement 251 As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP 252 Initialization Phase, PCEP Speakers (PCE or PCC) advertise their 253 support of PCECC extensions by sending a PATH-SETUP-TYPE-CAPABILITY 254 TLV in the OPEN object with this PST=PCECC included in the PST list. 256 [I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the 257 PCECC Capability sub-TLV. A new M-bit is added in PCECC-CAPABILITY 258 TLV to indicate support for PCECC-P2MP. A PCC MUST set M-bit in 259 PCECC-CAPABILITY TLV and include STATEFUL-PCE-CAPABILITY TLV with 260 P2MP bits set ([RFC8623]) in OPEN Object to support the PCECC P2MP 261 extensions defined in this document. If M-bit is set in PCECC- 262 CAPABILITY TLV and N-bit in STATEFUL-PCE-CAPABILITY TLV is not set in 263 OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 264 (Invalid Operation) and Error-value=TBD2 (P2MP capability was not 265 advertised) and terminate the session. 267 4.3. LSP Operations 269 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 270 TLV [RFC8408] with PST=PCECC 271 [I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to 272 clearly identify the PCECC LSP is intended. 274 4.3.1. Basic PCECC LSP Setup 276 In order to setup a P2MP LSP based on PCECC mechanism, a PCC MUST 277 delegate the P2MP LSP by sending a PCRpt message with PST set for 278 PCECC and D (Delegate) flag (see [RFC8623]) set in the LSP object. 280 P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for PCECC LSP, the 281 tuple uniquely identifies the P2MP LSP in the network. As per 282 [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object is 283 included in central controller's instructions (label download) to 284 identify the PCECC LSP for this instruction. 286 When a PCE receives PCRpt message with D flags and PST Type set, it 287 calculates the P2MP tree and assigns labels along the path; and set 288 up the path by sending PCInitiate message to each node along the path 289 of the LSP, similar to 290 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension 291 required is the instructions on the branch nodes for replications to 292 more than one outgoing interfaces with respective labels. The rest 293 of the operations remains same as 294 [I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623]. 296 4.3.2. Central Control Instructions 298 The new central controller's instructions (CCI) for the label 299 operations in PCEP is done via the PCInitiate message as described in 300 [I-D.ietf-pce-pcep-extension-for-pce-controller], by defining a new 301 PCEP Objects for CCI operations. Local label range of each PCC is 302 assumed to be known at both the PCC and the PCE. 304 4.3.2.1. Label Download CCI 306 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 307 message to each node along the path to download the Label instruction 308 as described in Section 4.3.1. 310 The CCI object MUST be included, along with the LSP object in the 311 PCInitiate message. As per 312 [I-D.ietf-pce-pcep-extension-for-pce-controller], there are at most 2 313 instances of CCI object in the PCInitiate message. For PCECC-P2MP 314 operations, multiple instances of CCI object for out-labels is 315 allowed. Similarly to acknowledge the central controller 316 instructions, the PCRpt message allows multiple instances of CCI 317 object for PCECC-P2MP operations. 319 The LSP-IDENTIFIER TLV MUST be included in LSP object. The SPEAKER- 320 ENTITY-ID TLV SHOULD be included in LSP object. 322 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if 323 a node (PCC) receives a PCInitiate message which includes a Label to 324 download as part of CCI, that is out of the range set aside for the 325 PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and 326 Error-value=TBD (Label out of range) (defined in 327 [I-D.ietf-pce-pcep-extension-for-pce-controller]). If a PCC receives 328 a PCInitiate message but failed to download the Label entry, it sends 329 a PCErr message with Error-type=TBD (PCECC failure) and Error- 330 value=TBD (Instruction failed) (defined in 331 [I-D.ietf-pce-pcep-extension-for-pce-controller]). 333 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 334 +----------+ 335 | R1 | Root node of the P2MP TE LSP 336 +----------+ 337 |6000 338 +----------+ 339 Transit Node | R2 | 340 branch +----------+ 341 * | * * 342 9001* | * *9002 343 * | * * 344 +-----------+ | * +-----------+ 345 | R4 | | * | R5 | Transit Nodes 346 +-----------+ | * +-----------+ 347 * | * * + 348 9003* | * * +9004 349 * | * * + 350 +-----------+ +-----------+ 351 | R3 | | R6 | Leaf Node 352 +-----------+ +-----------+ 353 9005| 354 +-----------+ 355 | R8 | Leaf Node 356 +-----------+ 358 PCECC would provision each node along the path and assign incoming 359 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 360 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 361 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 362 R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The 363 branch node (R2) needs to be instructed to replicate two copies of 364 the incoming packet, and sent towards R4 and R5 with 9001 and 9002 365 labels respectively). This done via including 3 instances of CCI 366 objects in the PCEP messages, one for each label in the example, 6000 367 for incoming and 9001/9002 for outgoing (along with remote nexthop). 368 The message and procedure remains exactly as 369 [I-D.ietf-pce-pcep-extension-for-pce-controller] with only 370 distinction that more than one outgoing CCI MAY be present for the 371 P2MP LSP. 373 4.3.2.2. Label Cleanup CCI 375 In order to delete an P2MP LSP based on PCECC, the PCE sends a 376 central controller instructions via a PCInitiate message to each node 377 along the path of the LSP to cleanup the Label forwarding instruction 378 as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. In case of 379 branch nodes all instances of CCIs needs to be present in the PCEP 380 message. 382 4.3.3. PCE Initiated PCECC LSP 384 The LSP Instantiation operation is same as defined in [RFC8281] and 385 [RFC8623]. 387 In order to setup a P2MP PCE Initiated LSP based on the PCECC 388 mechanism, a PCE sends PCInitiate message with Path Setup Type set 389 for PCECC (see Section 5.2) to the Ingress PCC (root). 391 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 392 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 393 PCC responds with first PCRpt message with the status as "GOING-UP" 394 and assigned PLSP-ID. 396 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the 397 label forwarding instructions from PCECC are send after the initial 398 PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and 399 other LSP identifiers can be obtained from the ingress and can be 400 included in the label forwarding instruction in the next PCInitiate 401 message. The rest of the PCECC LSP setup operations are same as 402 those described in Section 4.3.1. 404 4.3.4. PCECC LSP Update 406 In case of a modification of PCECC P2MP LSP with a new path, the 407 procedure and instructions as described in 408 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 410 4.3.5. Re-Delegation and Cleanup 412 In case of a redelegation and cleanup of PCECC P2MP LSP, the 413 procedure and instructions as described in 414 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 416 4.3.6. Synchronization of Central Controllers Instructions 418 The procedure and instructions are as per 419 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 421 4.3.7. PCECC LSP State Report 423 An Ingress PCC MAY choose to apply any OAM mechanism to check the 424 status of LSP in the Data plane and MAY further send its status in 425 PCRpt message (as per [RFC8623]) to the PCE. 427 5. PCEP Objects 429 5.1. OPEN Object 431 5.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 436 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 438 This document adds a new flag (M-bit) in PCECC-CAPABILITY sub-TLV to 439 indicate the support for P2MP in PCECC. A PCC MUST set M-bit in 440 PCECC-CAPABILITY sub-TLV and set the N (P2MP-CAPABILITY), M (P2MP- 441 LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) (as 442 per [RFC8623]) in STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support 443 the PCECC P2MP extensions defined in this document. If M-bit is set 444 in PCECC-CAPABILITY sub-TLV and the P2MP bits in STATEFUL-PCE- 445 CAPABILITY TLV are not set in OPEN Object, PCE SHOULD send a PCErr 446 message with Error-Type=19 (Invalid Operation) and Error-value=TBD2 447 (P2MP capability was not advertised) and terminate the session. 449 5.2. PATH-SETUP-TYPE TLV 451 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; 452 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value 453 for PCECC, which is also used for P2MP. 455 5.3. CCI Object 457 The Central Control Instructions (CCI) Object 458 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE 459 to specify the forwarding instructions (Label information in the 460 context of this document) to the PCC, and optionally carried within 461 PCInitiate or PCRpt message for label download which defined Object 462 Type 1 for MPLS Label, which is also used for P2MP. The address TLVs 463 [I-D.ietf-pce-pcep-extension-for-pce-controller] associates the next- 464 hop information in case of an outgoing label. 466 If a node (PCC) receives a PCInitiate/PCUpd message with more than 467 one CCI with O-bit set for outgoing label and the node does not 468 support the P2MP branch/replication capability, it MUST respond with 469 PCErr message with Error-Type=2 (Capability not supported) (defined 470 in [RFC5440]). 472 6. Security Considerations 474 The security considerations described in [RFC8231], [RFC8281], 475 [RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] apply 476 to the extensions described in this document. 478 7. Manageability Considerations 480 7.1. Control of Function and Policy 482 A PCE or PCC implementation SHOULD allow to configure to enable/ 483 disable PCECC P2MP capability as a global configuration. 485 7.2. Information and Data Models 487 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 488 PCECC capability status. 490 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 491 enable/disable PCECC P2MP capability. 493 7.3. Liveness Detection and Monitoring 495 Mechanisms defined in this document do not imply any new liveness 496 detection and monitoring requirements in addition to those already 497 listed in [RFC5440]. 499 7.4. Verify Correct Operations 501 Mechanisms defined in this document do not imply any new operation 502 verification requirements in addition to those already listed in 503 [RFC5440] and [RFC8231]. 505 7.5. Requirements On Other Protocols 507 PCEP extensions defined in this document do not put new requirements 508 on other protocols. 510 7.6. Impact On Network Operations 512 PCEP extensions defined in this document do not put new requirements 513 on network operations. 515 8. IANA Considerations 516 8.1. PCECC-CAPABILITY TLV 518 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 519 CAPABILITY TLV and requests that IANA creates a registry to manage 520 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 521 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 522 Field registry, as follows: 524 Bit Description Reference 525 TBD1 M((PCECC-P2MP-CAPABILITY)) This document 527 8.2. PCEP-Error Object 529 IANA is requested to allocate new error types and error values within 530 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 531 PCEP Numbers registry for the following errors: 533 Error-Type Meaning 534 ---------- ------- 535 19 Invalid operation. 537 Error-value = TBD2 : P2MP capability was 538 not advertised 540 9. Acknowledgments 542 10. References 544 10.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 552 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 553 DOI 10.17487/RFC5440, March 2009, 554 . 556 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 557 Hardwick, "Path Computation Element Communication Protocol 558 (PCEP) Management Information Base (MIB) Module", 559 RFC 7420, DOI 10.17487/RFC7420, December 2014, 560 . 562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 564 May 2017, . 566 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 567 Computation Element Communication Protocol (PCEP) 568 Extensions for Stateful PCE", RFC 8231, 569 DOI 10.17487/RFC8231, September 2017, 570 . 572 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 573 Computation Element Communication Protocol (PCEP) 574 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 575 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 576 . 578 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 579 Path Computation Element (PCE) Protocol Extensions for 580 Usage with Point-to-Multipoint TE Label Switched Paths 581 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 582 . 584 [I-D.ietf-pce-pcep-extension-for-pce-controller] 585 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 586 Procedures and Protocol Extensions for Using PCE as a 587 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 588 extension-for-pce-controller-05 (work in progress), June 589 2020. 591 10.2. Informative References 593 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 594 Element (PCE)-Based Architecture", RFC 4655, 595 DOI 10.17487/RFC4655, August 2006, 596 . 598 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 599 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 600 June 2007, . 602 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 603 Yasukawa, Ed., "Extensions to Resource Reservation 604 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 605 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 606 DOI 10.17487/RFC4875, May 2007, 607 . 609 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 610 Path Computation Element (PCE) to Point-to-Multipoint 611 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 612 DOI 10.17487/RFC5671, October 2009, 613 . 615 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 616 Margaria, "Requirements for GMPLS Applications of PCE", 617 RFC 7025, DOI 10.17487/RFC7025, September 2013, 618 . 620 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 621 Computation Element Architecture", RFC 7399, 622 DOI 10.17487/RFC7399, October 2014, 623 . 625 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 626 Application-Based Network Operations", RFC 7491, 627 DOI 10.17487/RFC7491, March 2015, 628 . 630 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 631 Architecture for Use of PCE and the PCE Communication 632 Protocol (PCEP) in a Network with Central Control", 633 RFC 8283, DOI 10.17487/RFC8283, December 2017, 634 . 636 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 637 "Extensions to the Path Computation Element Communication 638 Protocol (PCEP) for Point-to-Multipoint Traffic 639 Engineering Label Switched Paths", RFC 8306, 640 DOI 10.17487/RFC8306, November 2017, 641 . 643 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 644 Hardwick, "Conveying Path Setup Type in PCE Communication 645 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 646 July 2018, . 648 [I-D.ietf-teas-pcecc-use-cases] 649 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 650 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 651 Gulida, "The Use Cases for Path Computation Element (PCE) 652 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 653 use-cases-05 (work in progress), March 2020. 655 [I-D.ietf-pce-pcep-yang] 656 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 657 YANG Data Model for Path Computation Element 658 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 659 yang-13 (work in progress), October 2019. 661 Appendix A. Contributor Addresses 663 Dhruv Dhody 664 Huawei Technologies 665 Divyashree Techno Park, Whitefield 666 Bangalore, Karnataka 560066 667 India 669 EMail: dhruv.ietf@gmail.com 671 Udayasree Palle 673 EMail: udayasreereddy@gmail.com 675 Authors' Addresses 677 Zhenbin Li 678 Huawei Technologies 679 Huawei Bld., No.156 Beiqing Rd. 680 Beijing 100095 681 China 683 EMail: lizhenbin@huawei.com 685 Shuping Peng 686 Huawei Technologies 687 Huawei Bld., No.156 Beiqing Rd. 688 Beijing 100095 689 China 691 EMail: pengshuping@huawei.com 693 Xuesong Geng 694 Huawei Technologies 695 China 697 EMail: gengxuesong@huawei.com 698 Mahendra Singh Negi 699 RtBrick India 700 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 701 Bangalore, Karnataka 560102 702 India 704 EMail: mahend.ietf@gmail.com