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