idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-p2mp-03.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 (March 9, 2020) is 1471 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-04 == 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 M. Negi 3 Internet-Draft Z. Li 4 Intended status: Standards Track X. Geng 5 Expires: September 10, 2020 S. Peng 6 Huawei Technologies 7 March 9, 2020 9 PCEP Procedures and Protocol Extensions for Using PCE as a Central 10 Controller (PCECC) for P2MP LSPs 11 draft-dhody-pce-pcep-extension-pce-controller-p2mp-03 13 Abstract 15 The Path Computation Element (PCE) is a core component of Software- 16 Defined Networking (SDN) systems. It can compute optimal paths for 17 traffic across a network and can also update the paths to reflect 18 changes in the network or traffic demands. 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 PCE was developed to derive paths for MPLS P2MP LSPs, which are 25 supplied to the head end (root) of the LSP using PCEP. PCEP has been 26 proposed as a control protocol to allow the PCE to be fully enabled 27 as a central controller. 29 A PCE-based central controller (PCECC) can simplify the processing of 30 a distributed control plane by blending it with elements of SDN and 31 without necessarily completely replacing it. Thus, the P2MP LSP can 32 be calculated/setup/initiated and the label forwarding entries can 33 also be downloaded through a centralized PCE server to each network 34 devices along the P2MP path while leveraging the existing PCE 35 technologies as much as possible. 37 This document specifies the procedures and PCEP protocol extensions 38 for using the PCE as the central controller for P2MP TE LSP. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 10, 2020. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Procedures for Using the PCE as the Central Controller 79 (PCECC) for P2MP . . . . . . . . . . . . . . . . . . . . . . 5 80 4.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 5 81 4.2. PCECC Capability Advertisement . . . . . . . . . . . . . 6 82 4.3. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 83 4.3.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 6 84 4.3.2. Central Control Instructions . . . . . . . . . . . . 7 85 4.3.2.1. Label Download . . . . . . . . . . . . . . . . . 7 86 4.3.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 8 87 4.3.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 9 88 4.3.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 9 89 4.3.5. Re Delegation and Cleanup . . . . . . . . . . . . . . 9 90 4.3.6. Synchronization of Central Controllers Instructions . 9 91 4.3.7. PCECC LSP State Report . . . . . . . . . . . . . . . 9 92 5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 95 5.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 96 5.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 98 7. Manageability Considerations . . . . . . . . . . . . . . . . 11 99 7.1. Control of Function and Policy . . . . . . . . . . . . . 11 100 7.2. Information and Data Models . . . . . . . . . . . . . . . 11 101 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 102 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 103 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 104 7.6. Impact On Network Operations . . . . . . . . . . . . . . 11 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 106 8.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 12 107 8.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 12 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 111 10.2. Informative References . . . . . . . . . . . . . . . . . 13 112 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 16 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 115 1. Introduction 117 The Path Computation Element (PCE) [RFC4655] was developed to offload 118 path computation function from routers in an MPLS traffic-engineered 119 network. Since then, the role and function of the PCE has grown to 120 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 121 delegated control [RFC8231] and PCE-initiated use of network 122 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 PCE-based central controller (PCECC) can simplify the processing of 154 a distributed control plane by blending it with elements of SDN and 155 without necessarily completely replacing it. Thus, the LSP can be 156 calculated/setup/initiated and the label forwarding entries can also 157 be downloaded through a centralized PCE server to each network 158 devices along the path while leveraging the existing PCE technologies 159 as much as possible. 161 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 162 procedures and PCEP protocol extensions for using the PCE as the 163 central controller for static P2P LSPs, where LSPs can be provisioned 164 as explicit label instructions at each hop on the end-to-end path. 165 Each router along the path must be told what label-forwarding 166 instructions to program and what resources to reserve. The PCE-based 167 controller keeps a view of the network and determines the paths of 168 the end-to-end LSPs, and the controller uses PCEP to communicate with 169 each router along the path of the end-to-end LSP. 171 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 172 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 173 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 174 PCE has been identified as a suitable application for the computation 175 of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to 176 request path computation for P2MP TE LSPs are described in [RFC8306]. 177 Further [RFC8623] specify the extensions that are necessary in order 178 for the deployment of stateful PCEs to support P2MP TE LSPs as well 179 as the setup, maintenance and teardown of PCE-initiated P2MP LSPs 180 under the stateful PCE model. 182 This document extends 183 [I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the 184 procedures and PCEP protocol extensions for using the PCE as the 185 central controller for static P2MP LSPs, where LSPs can be 186 provisioned as explicit label instructions at each hop on the end-to- 187 end path with an added functionality of a P2MP branch node. As per 188 [RFC4875], a branch node is an LSR that replicates the incoming data 189 on to one or more outgoing interfaces. 190 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for P2MP in 191 PCECC architecture. 193 1.1. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 2. Terminology 203 Terminologies used in this document is same as described in the draft 204 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 206 3. Basic PCECC Mode 208 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in 209 this mode LSPs are provisioned as explicit label instructions at each 210 hop on the end-to-end path. Each router along the path must be told 211 what label forwarding instructions to program and what resources to 212 reserve. The controller uses PCEP to communicate with each router 213 along the path of the end-to-end LSP. Note that the PCE-based 214 controller will take responsibility for managing some part of the 215 MPLS label space for each of the routers that it controls, and may 216 taker wider responsibility for partitioning the label space for each 217 router and allocating different parts for different uses. This is 218 also described in section 3.1.2. of [RFC8283]. For the purpose of 219 this document, it is assumed that label range to be used by a PCE is 220 known and set on both PCEP peers. A future extension could add this 221 capability to advertise the range via possible PCEP extensions as 222 well. 224 This document extends the functionality to include support for 225 central control instruction for replication at the branch nodes. 227 The rest of processing is similar to the existing stateful PCE 228 mechanism for P2MP. 230 4. Procedures for Using the PCE as the Central Controller (PCECC) for 231 P2MP 233 4.1. Stateful PCE Model 235 Active stateful PCE is described in [RFC8231] and extended for P2MP 236 [RFC8623]. PCE as a central controller (PCECC) reuses existing 237 Active stateful PCE mechanism as much as possible to control the LSP. 239 [I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP 240 messages - PCRpt, PCInitiate, PCUpd message for the Central 241 Controller's Instructions (CCI) (label forwarding instructions in the 242 context of this document). This documents specify the procedure for 243 additional instruction for branch node needed for P2MP. 245 4.2. PCECC Capability Advertisement 247 As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP 248 Initialization Phase, PCEP Speakers (PCE or PCC) advertise their 249 support of PCECC extensions by sending a PATH-SETUP-TYPE-CAPABILITY 250 TLV in the OPEN object with this PST=PCECC included in the PST list. 252 [I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the 253 PCECC Capability sub-TLV. A new M-bit is added in PCECC-CAPABILITY 254 TLV to indicate support for PCECC-P2MP. A PCC MUST set M-bit in 255 PCECC-CAPABILITY TLV and include STATEFUL-PCE-CAPABILITY TLV with 256 P2MP bits set ([RFC8623]) in OPEN Object to support the PCECC P2MP 257 extensions defined in this document. If M-bit is set in PCECC- 258 CAPABILITY TLV and N-bit in STATEFUL-PCE-CAPABILITY TLV is not set in 259 OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 260 (Invalid Operation) and Error-value=TBD (P2MP capability was not 261 advertised) and terminate the session. 263 4.3. LSP Operations 265 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 266 TLV [RFC8408] with PST=PCECC 267 [I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to 268 clearly identify the PCECC LSP is intended. 270 4.3.1. Basic PCECC LSP Setup 272 In order to setup a P2MP LSP based on PCECC mechanism, a PCC MUST 273 delegate the P2MP LSP by sending a PCRpt message with PST set for 274 PCECC and D (Delegate) flag (see [RFC8623]) set in the LSP object. 276 P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for PCECC LSP, the 277 tuple uniquely identifies the P2MP LSP in the network. As per 278 [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object is 279 included in central controller's instructions (label download) to 280 identify the PCECC LSP for this instruction. 282 When a PCE receives PCRpt message with D flags and PST Type set, it 283 calculates the P2MP tree and assigns labels along the path; and set 284 up the path by sending PCInitiate message to each node along the path 285 of the LSP, similar to 286 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension 287 required is the instructions on the branch nodes for replications to 288 more than one outgoing interfaces with respective labels. The rest 289 of the operations remains same as 290 [I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623]. 292 4.3.2. Central Control Instructions 294 The new central controller's instructions (CCI) for the label 295 operations in PCEP is done via the PCInitiate message as described in 296 [I-D.ietf-pce-pcep-extension-for-pce-controller], by defining a new 297 PCEP Objects for CCI operations. Local label range of each PCC is 298 assumed to be known at both the PCC and the PCE. 300 4.3.2.1. Label Download 302 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 303 message to each node along the path to download the Label instruction 304 as described in Section 4.3.1. 306 The CCI object MUST be included, along with the LSP object in the 307 PCInitiate message. As per 308 [I-D.ietf-pce-pcep-extension-for-pce-controller], there are at most 2 309 instances of CCI object in the PCInitiate message. For PCECC-P2MP 310 operations, multiple instances of CCI object for out-labels is 311 allowed. Similarly to acknowledge the central controller 312 instructions, the PCRpt message allows multiple instances of CCI 313 object for PCECC-P2MP operations. 315 The LSP-IDENTIFIER TLV MUST be included in LSP object. The SPEAKER- 316 ENTITY-ID TLV SHOULD be included in LSP object. 318 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if 319 a node (PCC) receives a PCInitiate message which includes a Label to 320 download as part of CCI, that is out of the range set aside for the 321 PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and 322 Error-value=TBD (Label out of range). If a PCC receives a PCInitiate 323 message but failed to download the Label entry, it sends a PCErr 324 message with Error-type=TBD (PCECC failure) and Error-value=TBD 325 (instruction failed). 327 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 328 +----------+ 329 | R1 | Root node of the P2MP TE LSP 330 +----------+ 331 |6000 332 +----------+ 333 Transit Node | R2 | 334 branch +----------+ 335 * | * * 336 9001* | * *9002 337 * | * * 338 +-----------+ | * +-----------+ 339 | R4 | | * | R5 | Transit Nodes 340 +-----------+ | * +-----------+ 341 * | * * + 342 9003* | * * +9004 343 * | * * + 344 +-----------+ +-----------+ 345 | R3 | | R6 | Leaf Node 346 +-----------+ +-----------+ 347 9005| 348 +-----------+ 349 | R8 | Leaf Node 350 +-----------+ 352 PCECC would provision each node along the path and assign incoming 353 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 354 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 355 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 356 R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The 357 branch node (R2) needs to be instructed to replicate two copies of 358 the incoming packet, and sent towards R4 and R5 with 9001 and 9002 359 labels respectively). This done via including 3 instances of CCI 360 objects in the PCEP messages, one for each label in the example, 6000 361 for incoming and 9001/9002 for outgoing (along with remote nexthop). 362 The message and procedure remains exactly as 363 [I-D.ietf-pce-pcep-extension-for-pce-controller] with only 364 distinction that more than one outgoing CCI MAY be present for the 365 P2MP LSP. 367 4.3.2.2. Label Cleanup 369 In order to delete an P2MP LSP based on PCECC, the PCE sends a 370 central controller instructions via a PCInitiate message to each node 371 along the path of the LSP to cleanup the Label forwarding instruction 372 as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. In case of 373 branch nodes all instances of CCIs needs to be present in the PCEP 374 message. 376 4.3.3. PCE Initiated PCECC LSP 378 The LSP Instantiation operation is same as defined in [RFC8281] and 379 [RFC8623]. 381 In order to setup a P2MP PCE Initiated LSP based on the PCECC 382 mechanism, a PCE sends PCInitiate message with Path Setup Type set 383 for PCECC (see Section 5.2) to the Ingress PCC (root). 385 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 386 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 387 PCC responds with first PCRpt message with the status as "GOING-UP" 388 and assigned PLSP-ID. 390 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the 391 label forwarding instructions from PCECC are send after the initial 392 PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and 393 other LSP identifiers can be obtained from the ingress and can be 394 included in the label forwarding instruction in the next PCInitiate 395 message. The rest of the PCECC LSP setup operations are same as 396 those described in Section 4.3.1. 398 4.3.4. PCECC LSP Update 400 In case of a modification of PCECC P2MP LSP with a new path, the 401 procedure and instructions as described in 402 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 404 4.3.5. Re Delegation and Cleanup 406 In case of a redelegation and cleanup of PCECC P2MP LSP, the 407 procedure and instructions as described in 408 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 410 4.3.6. Synchronization of Central Controllers Instructions 412 The procedure and instructions are as per 413 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 415 4.3.7. PCECC LSP State Report 417 An Ingress PCC MAY choose to apply any OAM mechanism to check the 418 status of LSP in the Data plane and MAY further send its status in 419 PCRpt message (as per [RFC8623]) to the PCE. 421 5. PCEP Objects 423 5.1. OPEN Object 425 5.1.1. PCECC Capability sub-TLV 427 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 428 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 429 CAPABILITY TLV as specified in 430 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 432 This document adds a new flag (M-bit) in PCECC-CAPABILITY sub-TLV to 433 indicate the support for P2MP in PCECC. A PCC MUST set M-bit in 434 PCECC-CAPABILITY sub-TLV and set the N (P2MP-CAPABILITY), M (P2MP- 435 LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) (as 436 per [RFC8623]) in STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support 437 the PCECC P2MP extensions defined in this document. If M-bit is set 438 in PCECC-CAPABILITY sub-TLV and the P2MP bits in STATEFUL-PCE- 439 CAPABILITY TLV are not set in OPEN Object, PCE SHOULD send a PCErr 440 message with Error-Type=19 (Invalid Operation) and Error- 441 value=TBD(P2MP capability was not advertised) and terminate the 442 session. 444 5.2. PATH-SETUP-TYPE TLV 446 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; 447 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value 448 for PCECC, which is also used for P2MP. 450 5.3. CCI Object 452 The Central Control Instructions (CCI) Object 453 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE 454 to specify the forwarding instructions (Label information in the 455 context of this document) to the PCC, and MAY be carried within 456 PCInitiate or PCRpt message for label download which defined Object 457 Type 1 for MPLS Label, which is also used for P2MP. The address TLVs 458 [I-D.ietf-pce-pcep-extension-for-pce-controller] associates the next- 459 hop information in case of an outgoing label. 461 If a node (PCC) receives a PCInitiate/PCUpd message with more than 462 one CCI with O-bit set for outgoing label and the node does not 463 support the P2MP branch/replication capability, it MUST respond with 464 PCErr message with Error-Type=2(Capability not supported). 466 6. Security Considerations 468 The security considerations described in [RFC8231], [RFC8281], 469 [RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] apply 470 to the extensions described in this document. 472 7. Manageability Considerations 474 7.1. Control of Function and Policy 476 A PCE or PCC implementation SHOULD allow to configure to enable/ 477 disable PCECC P2MP capability as a global configuration. 479 7.2. Information and Data Models 481 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 482 PCECC capability status. 484 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 485 enable/disable PCECC P2MP capability. 487 7.3. Liveness Detection and Monitoring 489 Mechanisms defined in this document do not imply any new liveness 490 detection and monitoring requirements in addition to those already 491 listed in [RFC5440]. 493 7.4. Verify Correct Operations 495 Mechanisms defined in this document do not imply any new operation 496 verification requirements in addition to those already listed in 497 [RFC5440] and [RFC8231]. 499 7.5. Requirements On Other Protocols 501 PCEP extensions defined in this document do not put new requirements 502 on other protocols. 504 7.6. Impact On Network Operations 506 PCEP extensions defined in this document do not put new requirements 507 on network operations. 509 8. IANA Considerations 510 8.1. PCECC-CAPABILITY TLV 512 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 513 CAPABILITY TLV and requests that IANA creates a registry to manage 514 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 515 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 516 Field registry, as follows: 518 Bit Description Reference 519 TBD M((PCECC-P2MP-CAPABILITY)) This document 521 8.2. PCEP-Error Object 523 IANA is requested to allocate new error types and error values within 524 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 525 PCEP Numbers registry for the following errors: 527 Error-Type Meaning 528 ---------- ------- 529 19 Invalid operation. 531 Error-value = TBD : P2MP capability was 532 not advertised 534 9. Acknowledgments 536 10. References 538 10.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 546 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 547 DOI 10.17487/RFC5440, March 2009, 548 . 550 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 551 Hardwick, "Path Computation Element Communication Protocol 552 (PCEP) Management Information Base (MIB) Module", 553 RFC 7420, DOI 10.17487/RFC7420, December 2014, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 561 Computation Element Communication Protocol (PCEP) 562 Extensions for Stateful PCE", RFC 8231, 563 DOI 10.17487/RFC8231, September 2017, 564 . 566 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 567 Computation Element Communication Protocol (PCEP) 568 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 569 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 570 . 572 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 573 Path Computation Element (PCE) Protocol Extensions for 574 Usage with Point-to-Multipoint TE Label Switched Paths 575 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 576 . 578 [I-D.ietf-pce-pcep-extension-for-pce-controller] 579 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 580 Procedures and Protocol Extensions for Using PCE as a 581 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 582 extension-for-pce-controller-04 (work in progress), March 583 2020. 585 10.2. Informative References 587 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 588 Element (PCE)-Based Architecture", RFC 4655, 589 DOI 10.17487/RFC4655, August 2006, 590 . 592 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 593 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 594 June 2007, . 596 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 597 Yasukawa, Ed., "Extensions to Resource Reservation 598 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 599 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 600 DOI 10.17487/RFC4875, May 2007, 601 . 603 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 604 Path Computation Element (PCE) to Point-to-Multipoint 605 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 606 DOI 10.17487/RFC5671, October 2009, 607 . 609 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 610 Margaria, "Requirements for GMPLS Applications of PCE", 611 RFC 7025, DOI 10.17487/RFC7025, September 2013, 612 . 614 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 615 Computation Element Architecture", RFC 7399, 616 DOI 10.17487/RFC7399, October 2014, 617 . 619 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 620 Application-Based Network Operations", RFC 7491, 621 DOI 10.17487/RFC7491, March 2015, 622 . 624 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 625 Architecture for Use of PCE and the PCE Communication 626 Protocol (PCEP) in a Network with Central Control", 627 RFC 8283, DOI 10.17487/RFC8283, December 2017, 628 . 630 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 631 "Extensions to the Path Computation Element Communication 632 Protocol (PCEP) for Point-to-Multipoint Traffic 633 Engineering Label Switched Paths", RFC 8306, 634 DOI 10.17487/RFC8306, November 2017, 635 . 637 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 638 Hardwick, "Conveying Path Setup Type in PCE Communication 639 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 640 July 2018, . 642 [I-D.ietf-teas-pcecc-use-cases] 643 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 644 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 645 Gulida, "The Use Cases for Path Computation Element (PCE) 646 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 647 use-cases-05 (work in progress), March 2020. 649 [I-D.ietf-pce-pcep-yang] 650 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 651 YANG Data Model for Path Computation Element 652 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 653 yang-13 (work in progress), October 2019. 655 Appendix A. Contributor Addresses 657 Dhruv Dhody 658 Huawei Technologies 659 Divyashree Techno Park, Whitefield 660 Bangalore, Karnataka 560066 661 India 663 EMail: dhruv.ietf@gmail.com 665 Udayasree Palle 667 EMail: udayasreereddy@gmail.com 669 Authors' Addresses 671 Mahendra Singh Negi 672 Huawei Technologies 673 Divyashree Techno Park, Whitefield 674 Bangalore, Karnataka 560066 675 India 677 EMail: mahend.ietf@gmail.com 679 Zhenbin Li 680 Huawei Technologies 681 Huawei Bld., No.156 Beiqing Rd. 682 Beijing 100095 683 China 685 EMail: lizhenbin@huawei.com 687 Xuesong Geng 688 Huawei Technologies 689 China 691 EMail: gengxuesong@huawei.com 692 Shuping Peng 693 Huawei Technologies 694 Huawei Bld., No.156 Beiqing Rd. 695 Beijing 100095 696 China 698 EMail: pengshuping@huawei.com