idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-p2mp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2019) is 1894 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 (-13) exists of draft-ietf-pce-stateful-pce-p2mp-10 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-01 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-02 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 Summary: 0 errors (**), 0 flaws (~~), 5 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: August 22, 2019 Huawei Technologies 6 February 18, 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-01 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 August 22, 2019. 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 . . . . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-pce-stateful-pce-p2mp] specify the extensions that 177 are necessary in order for the deployment of stateful PCEs to support 178 P2MP TE LSPs as well as the setup, maintenance and teardown of PCE- 179 initiated P2MP LSPs 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 [I-D.ietf-pce-stateful-pce-p2mp]. PCE as a central controller 236 (PCECC) reuses existing Active stateful PCE mechanism as much as 237 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 ([I-D.ietf-pce-stateful-pce-p2mp]) in OPEN Object to 257 support the PCECC P2MP extensions defined in this document. If M-bit 258 is set in PCECC-CAPABILITY TLV and N-bit in STATEFUL-PCE-CAPABILITY 259 TLV is not set in OPEN Object, PCE SHOULD send a PCErr message with 260 Error-Type=19 (Invalid Operation) and Error-value=TBD (P2MP 261 capability was not 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 [I-D.ietf-pce-stateful-pce-p2mp]) 275 set in the LSP object. 277 P2MP-LSP-IDENTIFIER TLV [I-D.ietf-pce-stateful-pce-p2mp] MUST be 278 included for PCECC LSP, the tuple uniquely identifies the P2MP LSP in 279 the network. As per 280 [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object is 281 included in central controller's instructions (label download) to 282 identify the PCECC LSP for this instruction. 284 When a PCE receives PCRpt message with D flags and PST Type set, it 285 calculates the P2MP tree and assigns labels along the path; and set 286 up the path by sending PCInitiate message to each node along the path 287 of the LSP, similar to 288 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension 289 required is the instructions on the branch nodes for replications to 290 more than one outgoing interfaces with respective labels. The rest 291 of the operations remains same as 292 [I-D.ietf-pce-pcep-extension-for-pce-controller] and 293 [I-D.ietf-pce-stateful-pce-p2mp]. 295 4.3.2. Central Control Instructions 297 The new central controller's instructions (CCI) for the label 298 operations in PCEP is done via the PCInitiate message, by defining a 299 new PCEP Objects for CCI operations. Local label range of each PCC 300 is assumed to be known at both the PCC and the PCE. 302 4.3.2.1. Label Download 304 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 305 message to each node along the path to download the Label instruction 306 as described in Section 4.3.1. 308 The CCI object MUST be included, along with the LSP object in the 309 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 310 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 312 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if 313 a node (PCC) receives a PCInitiate message which includes a Label to 314 download as part of CCI, that is out of the range set aside for the 315 PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and 316 Error-value=TBD (Label out of range). If a PCC receives a PCInitiate 317 message but failed to download the Label entry, it sends a PCErr 318 message with Error-type=TBD (PCECC failure) and Error-value=TBD 319 (instruction failed). 321 Consider the example in the [I-D.ietf-teas-pcecc-use-cases] - 322 +----------+ 323 | R1 | Root node of the P2MP TE LSP 324 +----------+ 325 |6000 326 +----------+ 327 Transit Node | R2 | 328 branch +----------+ 329 * | * * 330 9001* | * *9002 331 * | * * 332 +-----------+ | * +-----------+ 333 | R4 | | * | R5 | Transit Nodes 334 +-----------+ | * +-----------+ 335 * | * * + 336 9003* | * * +9004 337 * | * * + 338 +-----------+ +-----------+ 339 | R3 | | R6 | Leaf Node 340 +-----------+ +-----------+ 341 9005| 342 +-----------+ 343 | R8 | Leaf Node 344 +-----------+ 346 PCECC would provision each node along the path and assign incoming 347 and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, 348 {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, 349 R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except 350 R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The 351 branch node (R2) needs to be instructed to replicate two copies of 352 the incoming packet, and sent towards R4 and R5 with 9001 and 9002 353 labels respectively). This done via including 3 instances of CCI 354 objects in the PCEP messages, one for each label in the example, 6000 355 for incoming and 9001/9002 for outgoing (along with remote nexthop). 356 The message and procedure remains exactly as 357 [I-D.ietf-pce-pcep-extension-for-pce-controller] with only 358 distinction that more than one outgoing CCI MAY be present for the 359 P2MP LSP. 361 4.3.2.2. Label Cleanup 363 In order to delete an P2MP LSP based on PCECC, the PCE sends a 364 central controller instructions via a PCInitiate message to each node 365 along the path of the LSP to cleanup the Label forwarding instruction 366 as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. In case of 367 branch nodes all instances of CCIs needs to be present in the PCEP 368 message. 370 4.3.3. PCE Initiated PCECC LSP 372 The LSP Instantiation operation is same as defined in [RFC8281] and 373 [I-D.ietf-pce-stateful-pce-p2mp]. 375 In order to setup a P2MP PCE Initiated LSP based on the PCECC 376 mechanism, a PCE sends PCInitiate message with Path Setup Type set 377 for PCECC (see Section 5.2) to the Ingress PCC (root). 379 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 380 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 381 PCC responds with first PCRpt message with the status as "GOING-UP" 382 and assigned PLSP-ID. 384 As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the 385 label forwarding instructions from PCECC are send after the initial 386 PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and 387 other LSP identifiers can be obtained from the ingress and can be 388 included in the label forwarding instruction in the next PCInitiate 389 message. The rest of the PCECC LSP setup operations are same as 390 those described in Section 4.3.1. 392 4.3.4. PCECC LSP Update 394 In case of a modification of PCECC P2MP LSP with a new path, the 395 procedure and instructions as described in 396 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 398 4.3.5. Re Delegation and Cleanup 400 In case of a redelgation and cleanup of PCECC P2MP LSP, the procedure 401 and instructions as described in 402 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply. 404 4.3.6. Synchronization of Central Controllers Instructions 406 The procedure and instructions are as per 407 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 409 4.3.7. PCECC LSP State Report 411 An Ingress PCC MAY choose to apply any OAM mechanism to check the 412 status of LSP in the Data plane and MAY further send its status in 413 PCRpt message (as per [I-D.ietf-pce-stateful-pce-p2mp]) to the PCE. 415 5. PCEP Objects 417 5.1. OPEN Object 419 5.1.1. PCECC Capability sub-TLV 421 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 422 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 423 CAPABILITY TLV as specified in 424 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 426 This document adds a new flag (M-bit) in PCECC-CAPABILITY sub-TLV to 427 indicate the support for P2MP in PCECC. A PCC MUST set M-bit in 428 PCECC-CAPABILITY sub-TLV and set the N (P2MP-CAPABILITY), M (P2MP- 429 LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) (as 430 per [I-D.ietf-pce-stateful-pce-p2mp]) in STATEFUL-PCE-CAPABILITY TLV 431 [RFC8231] to support the PCECC P2MP extensions defined in this 432 document. If M-bit is set in PCECC-CAPABILITY sub-TLV and the P2MP 433 bits in STATEFUL-PCE-CAPABILITY TLV are not set in OPEN Object, PCE 434 SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) 435 and Error-value=TBD(P2MP capability was not advertised) and terminate 436 the session. 438 5.2. PATH-SETUP-TYPE TLV 440 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; 441 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value 442 for PCECC, which is also used for P2MP. 444 5.3. CCI Object 446 The Central Control Instructions (CCI) Object 447 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE 448 to specify the forwarding instructions (Label information in the 449 context of this document) to the PCC, and MAY be carried within 450 PCInitiate or PCRpt message for label download which defined Object 451 Type 1 for MPLS Label, which is also used for P2MP. The address TLVs 452 [I-D.ietf-pce-pcep-extension-for-pce-controller] associates the next- 453 hop information in case of an outgoing label. 455 If a node (PCC) receives a PCInitiate/PCUpd message with more than 456 one CCI with O-bit set for outgoiing label and the node does not 457 support the P2MP branch/replication capability, it MUST respond with 458 PCErr message with Error-Type=2(Capability not supported). 460 6. Security Considerations 462 The security considerations described in [RFC8231], [RFC8281], 463 [I-D.ietf-pce-stateful-pce-p2mp], and 464 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 465 extensions described in this document. 467 7. Manageability Considerations 469 7.1. Control of Function and Policy 471 A PCE or PCC implementation SHOULD allow to configure to enable/ 472 disable PCECC P2MP capability as a global configuration. 474 7.2. Information and Data Models 476 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 477 PCECC capability status. 479 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 480 enable/disable PCECC P2MP capability. 482 7.3. Liveness Detection and Monitoring 484 Mechanisms defined in this document do not imply any new liveness 485 detection and monitoring requirements in addition to those already 486 listed in [RFC5440]. 488 7.4. Verify Correct Operations 490 Mechanisms defined in this document do not imply any new operation 491 verification requirements in addition to those already listed in 492 [RFC5440] and [RFC8231]. 494 7.5. Requirements On Other Protocols 496 PCEP extensions defined in this document do not put new requirements 497 on other protocols. 499 7.6. Impact On Network Operations 501 PCEP extensions defined in this document do not put new requirements 502 on network operations. 504 8. IANA Considerations 506 8.1. PCECC-CAPABILITY TLV 508 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 509 CAPABILITY TLV and requests that IANA creates a registry to manage 510 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 511 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 512 Field registry, as follows: 514 Bit Description Reference 515 TBD M((PCECC-P2MP-CAPABILITY)) This document 517 8.2. PCEP-Error Object 519 IANA is requested to allocate new error types and error values within 520 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 521 PCEP Numbers registry for the following errors: 523 Error-Type Meaning 524 ---------- ------- 525 19 Invalid operation. 527 Error-value = TBD : P2MP capability was 528 not advertised 530 9. Acknowledgments 532 10. References 534 10.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 542 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 543 DOI 10.17487/RFC5440, March 2009, 544 . 546 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 547 Hardwick, "Path Computation Element Communication Protocol 548 (PCEP) Management Information Base (MIB) Module", 549 RFC 7420, DOI 10.17487/RFC7420, December 2014, 550 . 552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 554 May 2017, . 556 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 557 Computation Element Communication Protocol (PCEP) 558 Extensions for Stateful PCE", RFC 8231, 559 DOI 10.17487/RFC8231, September 2017, 560 . 562 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 563 Computation Element Communication Protocol (PCEP) 564 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 565 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 566 . 568 [I-D.ietf-pce-stateful-pce-p2mp] 569 Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Path 570 Computation Element (PCE) Protocol Extensions for Stateful 571 PCE usage for Point-to-Multipoint Traffic Engineering 572 Label Switched Paths", draft-ietf-pce-stateful-pce-p2mp-10 573 (work in progress), February 2019. 575 [I-D.ietf-pce-pcep-extension-for-pce-controller] 576 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 577 and Protocol Extensions for Using PCE as a Central 578 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 579 extension-for-pce-controller-01 (work in progress), 580 February 2019. 582 10.2. Informative References 584 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 585 Element (PCE)-Based Architecture", RFC 4655, 586 DOI 10.17487/RFC4655, August 2006, 587 . 589 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 590 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 591 June 2007, . 593 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 594 Yasukawa, Ed., "Extensions to Resource Reservation 595 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 596 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 597 DOI 10.17487/RFC4875, May 2007, 598 . 600 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 601 Path Computation Element (PCE) to Point-to-Multipoint 602 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 603 DOI 10.17487/RFC5671, October 2009, 604 . 606 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 607 Margaria, "Requirements for GMPLS Applications of PCE", 608 RFC 7025, DOI 10.17487/RFC7025, September 2013, 609 . 611 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 612 Computation Element Architecture", RFC 7399, 613 DOI 10.17487/RFC7399, October 2014, 614 . 616 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 617 Application-Based Network Operations", RFC 7491, 618 DOI 10.17487/RFC7491, March 2015, 619 . 621 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 622 Architecture for Use of PCE and the PCE Communication 623 Protocol (PCEP) in a Network with Central Control", 624 RFC 8283, DOI 10.17487/RFC8283, December 2017, 625 . 627 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 628 "Extensions to the Path Computation Element Communication 629 Protocol (PCEP) for Point-to-Multipoint Traffic 630 Engineering Label Switched Paths", RFC 8306, 631 DOI 10.17487/RFC8306, November 2017, 632 . 634 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 635 Hardwick, "Conveying Path Setup Type in PCE Communication 636 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 637 July 2018, . 639 [I-D.ietf-teas-pcecc-use-cases] 640 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 641 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 642 Gulida, "The Use Cases for Path Computation Element (PCE) 643 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 644 use-cases-02 (work in progress), October 2018. 646 [I-D.ietf-pce-pcep-yang] 647 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 648 YANG Data Model for Path Computation Element 649 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 650 yang-09 (work in progress), October 2018. 652 Appendix A. Contributor Addresses 654 Dhruv Dhody 655 Huawei Technologies 656 Divyashree Techno Park, Whitefield 657 Bangalore, Karnataka 560066 658 India 660 EMail: dhruv.ietf@gmail.com 662 Udayasree Palle 664 EMail: udayasreereddy@gmail.com 666 Authors' Addresses 668 Mahendra Singh Negi 669 Huawei Technologies 670 Divyashree Techno Park, Whitefield 671 Bangalore, Karnataka 560066 672 India 674 EMail: mahendrasingh@huawei.com 676 Zhenbin Li 677 Huawei Technologies 678 Huawei Bld., No.156 Beiqing Rd. 679 Beijing 100095 680 China 682 EMail: lizhenbin@huawei.com 684 Xuesong Geng 685 Huawei Technologies 686 China 688 EMail: gengxuesong@huawei.com