idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-12.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 20, 2019) is 1892 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group U. Palle 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 24, 2019 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 February 20, 2019 11 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 12 usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 13 draft-ietf-pce-stateful-pce-p2mp-12 15 Abstract 17 The Path Computation Element (PCE) has been identified as an 18 appropriate technology for the determination of the paths of point- 19 to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document 20 provides extensions required for Path Computation Element 21 Communication Protocol (PCEP) so as to enable the usage of a stateful 22 PCE capability in supporting P2MP TE LSPs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 24, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . 4 62 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 65 5. Architectural Overview of Protocol Extensions . . . . . . . . 6 66 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 67 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 68 5.3. IGP Extensions for Stateful PCE P2MP Capabilities 69 Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 70 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 71 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 72 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 73 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8 74 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 75 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 76 5.6.3.1. P2MP TE LSPs Instantiation . . . . . . . . . . . 9 77 5.6.3.2. P2MP TE LSPs Deletion . . . . . . . . . . . . . . 9 78 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10 79 5.6.3.4. P2MP TE LSPs Delegation and Cleanup . . . . . . . 10 80 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10 81 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 10 82 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 83 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14 84 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 14 85 6.5. The PCInitiate message . . . . . . . . . . . . . . . . . 15 86 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17 88 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 89 6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18 90 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19 91 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 19 92 7.2. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . . . 19 93 7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22 94 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23 95 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23 96 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23 97 8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 24 98 9. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 24 99 10. Manageability Considerations . . . . . . . . . . . . . . . . 25 100 10.1. Control of Function and Policy . . . . . . . . . . . . . 25 101 10.2. Information and Data Models . . . . . . . . . . . . . . 25 102 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 103 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26 104 10.5. Requirements On Other Protocols . . . . . . . . . . . . 26 105 10.6. Impact On Network Operations . . . . . . . . . . . . . . 26 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 107 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26 108 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26 109 11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27 110 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27 111 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 112 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 29 113 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 115 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 117 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 118 14.2. Informative References . . . . . . . . . . . . . . . . . 31 119 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 33 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 122 1. Introduction 124 As per [RFC4655], the Path Computation Element (PCE) is an entity 125 that is capable of computing a network path or route based on a 126 network graph and applying computational constraints. A Path 127 Computation Client (PCC) may make requests to a PCE for paths to be 128 computed. 130 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 131 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 132 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 133 PCE has been identified as a suitable application for the computation 134 of paths for P2MP TE LSPs ([RFC5671]). 136 The PCEP is designed as a communication protocol between PCCs and 137 PCEs for point-to-point (P2P) path computations and is defined in 138 [RFC5440]. The extensions of PCEP to request path computation for 139 P2MP TE LSPs are described in [RFC8306]. 141 Stateful PCEs are shown to be helpful in many application scenarios, 142 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These 143 scenarios apply equally to P2P and P2MP TE LSPs. [RFC8231] provides 144 the fundamental extensions to PCEP needed for stateful PCE to support 145 general functionality for P2P TE LSP. [RFC8281] provides extensions 146 to PCEP needed for stateful PCE-initiated P2P TE LSP. This document 147 complements that work by focusing on PCEP extensions that are 148 necessary in order for the deployment of stateful PCEs to support 149 P2MP TE LSPs. This document describes the setup, maintenance, and 150 teardown of PCE-initiated P2MP LSPs under the stateful PCE model. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2. Terminology 162 Terminology used in this document is same as terminology used in 163 [RFC8231], [RFC8281], and [RFC8306]. 165 3. Supporting P2MP TE LSPs for Stateful PCE 167 3.1. Motivation 169 [RFC8051] presents several use cases, demonstrating scenarios that 170 benefit from the deployment of a stateful PCE including optimization, 171 recovery, etc., which are equally applicable to P2MP TE LSPs. 172 [RFC8231] defines the extensions to PCEP for P2P TE LSPs. This 173 document complements the previous work by focusing on extensions that 174 are necessary in order for the deployment of stateful PCEs to support 175 P2MP TE LSPs. 177 In addition to that, the stateful nature of a PCE simplifies the 178 information conveyed in PCEP messages since it is possible to refer 179 to the LSPs via a PCEP-specific LSP identifier (PLSP-ID) ([RFC8231]). 180 For P2MP, where the size of message is much larger, this is an added 181 advantage. When using a stateless PCE, a request to modify an 182 existing P2MP tree requires that all the leaves are presented in the 183 PCEP messages along with all the path information. But when using a 184 stateful PCE, the PCEP messages can use a PLSP-ID to represent all 185 information about the LSP that has previously been exchanged in PCEP 186 messages, and it is only necessary to encode the modifications (such 187 as new or removed leaf nodes). The PLSP-ID provides an index into 188 the LSP-DB at the PCE, and identifies the LSP at the PCC. 190 In environments where the P2MP TE LSPs placement needs to change in 191 response to application demands, it is useful to support dynamic 192 creation and tear down of P2MP TE LSPs. The ability for a PCE to 193 trigger the creation of P2MP TE LSPs on demand can be seamlessly 194 integrated into a controller-based network architecture, where 195 intelligence in the controller can determine when and where to set up 196 paths. Section 3 of [RFC8281] further describes the motivation 197 behind the PCE-Initiation capability, which is equally applicable to 198 P2MP TE LSPs. 200 3.2. Objectives 202 The objectives for the protocol extensions to support P2MP TE LSPs 203 for stateful PCE are same as the objectives described in section 3.2 204 of [RFC8231]. 206 4. Functions to Support P2MP TE LSPs for Stateful PCEs 208 [RFC8231] specifies new functions to support a stateful PCE. It also 209 specifies that a function can be initiated either from a PCC towards 210 a PCE (C-E) or from a PCE towards a PCC (E-C). 212 This document extends these functions to support P2MP TE LSPs. 214 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 215 announce during PCEP session establishment that they support 216 Stateful PCE extensions for P2MP using mechanisms defined in 217 Section 5.2. 219 LSP State Synchronization (C-E): after the session between the PCC 220 and a stateful PCE with P2MP capability is initialized, the PCE 221 must learn the state of a PCC's P2MP TE LSPs before it can perform 222 path computations or update LSP attributes in a PCC. 224 LSP Update Request (E-C): a stateful PCE with P2MP capability 225 requests modification of attributes on a PCC's P2MP TE LSPs. 227 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 228 whenever the state of a P2MP TE LSP changes. 230 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 231 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 232 the authoritative source of the LSP's attributes as long as the 233 delegation is in effect (See Section 5.7 of [RFC8231]); the PCC 234 may withdraw the delegation or the PCE may give up the delegation 235 at any time. 237 PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate 238 Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281]. 240 5. Architectural Overview of Protocol Extensions 242 5.1. Extension of PCEP Messages 244 New PCEP messages are defined in [RFC8231] to support stateful PCE 245 for P2P TE LSPs. In this document these messages are extended to 246 support P2MP TE LSPs. 248 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 249 in a PCRpt message can contain actual P2MP TE LSP path attributes, 250 LSP status, etc. An LSP State Report carried in a PCRpt message 251 is also used in delegation or revocation of control of a P2MP TE 252 LSP to/from a PCE. The extension of PCRpt message is described in 253 Section 6.1. 255 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 256 Request in a PCUpd message MUST contain all LSP parameters that a 257 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 258 carried in a PCUpd message is also used to return LSP delegations 259 if at any point PCE no longer desires control of a P2MP TE LSP. 260 The PCUpd message is described in Section 6.2. 262 A PCEP message is defined in [RFC8281] to support stateful PCE 263 instantiation of P2P TE LSPs. In this document this message is 264 extended to support P2MP TE LSPs. 266 Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a 267 PCEP message sent by a PCE to a PCC to trigger P2MP TE LSPs 268 instantiation or deletion. The PCInitiate message is described in 269 Section 6.5. 271 The Path Computation Request (PCReq) and Path Computation Reply 272 (PCRep) messages are also extended to support passive stateful PCE 273 for P2P TE LSP in [RFC8231]. In this document these messages are 274 extended to support P2MP TE LSPs as well. 276 5.2. Capability Advertisement 278 During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231], 279 PCEP speakers advertise Stateful capability via the STATEFUL-PCE- 280 CAPABILITY TLV in the OPEN object. Various flags are defined for the 281 STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in 282 [RFC8281] and [RFC8232]. 284 Three new flags N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), 285 and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: 287 N (P2MP-CAPABILITY flag - 1 bit): if set to 1 by a PCC, the N Flag 288 indicates that the PCC is willing to send P2MP LSP State Reports 289 whenever any parameters or operational status change of the P2MP 290 LSP; if set to 1 by a PCE, the N Flag indicates that the PCE is 291 interested in receiving LSP State Reports whenever there is any 292 parameters or operational status change of the P2MP LSP. The 293 P2MP-CAPABILITY Flag MUST be advertised by both a PCC and a PCE 294 for PCRpt messages P2MP extension to be allowed on a PCEP session. 296 M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit): if set to 1 by a PCC, 297 the M Flag indicates that the PCC allows modification of P2MP LSP 298 parameters; if set to 1 by a PCE, the M Flag indicates that the 299 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 300 UPDATE-CAPABILITY Flag MUST be advertised by both a PCC and a PCE 301 for PCUpd messages P2MP extension to be allowed on a PCEP session. 303 P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit): If set to 1 by a 304 PCC, the P Flag indicates that the PCC allows instantiation of a 305 P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates 306 that the PCE supports P2MP LSP instantiation. The P2MP-LSP- 307 INSTANTIATION-CAPABILITY flag MUST be set by both PCC and PCE in 308 order to support PCE-initiated P2MP LSP instantiation. 310 A PCEP speaker should continue to advertise the basic P2MP capability 311 via mechanisms as described in [RFC8306]. 313 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 315 When PCC is a Label Switching Router (LSR), participating in the IGP 316 (OSPF or IS-IS), and PCEs are either LSRs or servers also 317 participating in the IGP, an effective mechanism for PCE discovery 318 within an IGP routing domain consists of utilizing IGP 319 advertisements. Extensions for the advertisement of PCE Discovery 320 Information are defined for OSPF and for IS-IS in [RFC5088] and 321 [RFC5089] respectively. 323 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 324 TLV used to advertise PCE capabilities. It MAY be present within the 325 PCE Discovery (PCED) TLV carried by OSPF or IS-IS. [RFC5088] and 326 [RFC5089] provide the description and processing rules for this sub- 327 TLV when carried within OSPF and IS-IS, respectively. 329 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 330 reference: 332 Type: 5 334 Length: Multiple of 4. 336 Value: This contains an array of units of 32 bit flags with the most 337 significant bit as 0. Each bit represents one PCE capability. 339 PCE capability bit flags are defined in [RFC5088]. This document 340 defines new capability bits (early allocated by IANA) for the 341 stateful PCE with P2MP as follows: 343 Bit Capability 344 13 Active Stateful PCE with P2MP 345 14 Passive Stateful PCE with P2MP 346 15 PCE-Initiation with P2MP 348 Note that while active, passive or initiation stateful PCE with P2MP 349 capabilities may be advertised during discovery, PCEP Speakers that 350 wish to use stateful PCEP MUST advertise stateful PCEP capabilities 351 during PCEP session setup, as specified in the current document. A 352 PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP 353 session setup even if it did not receive any IGP PCE capability 354 advertisements. 356 5.4. State Synchronization 358 State Synchronization operations (described in Section 5.6 of 359 [RFC8231]) are applicable for the P2MP TE LSPs as well. The 360 optimizations described in [RFC8232] can also be applied for P2MP TE 361 LSPs. 363 5.5. LSP Delegation 365 LSP delegation operations (described in Section 5.7 of [RFC8231]) are 366 applicable for P2MP TE LSPs as well. 368 5.6. LSP Operations 370 5.6.1. Passive Stateful PCE 372 LSP operations for passive stateful PCE (described in Section 5.8.1 373 of [RFC8231]) are applicable for P2MP TE LSPs as well. 375 The PCReq and PCRep message format for P2MP TE LSPs is described in 376 Section 3.4 and Section 3.5 of [RFC8306] respectively. 378 The PCReq and PCRep message for P2MP TE LSPs are extended to support 379 encoding of LSP object, so that it is possible to refer to an LSP 380 with a unique identifier and simplify the PCEP message exchange. For 381 example, in case of modification of one leaf in a P2MP tree, there 382 should be no need to carry the full P2MP tree in PCReq message. 384 The extension for the Request and Response message for passive 385 stateful operations on P2MP TE LSPs are described in Section 6.3 and 386 Section 6.4. The extension for the Path Computation LSP State Report 387 (PCRpt) message is described in Section 6.1. 389 5.6.2. Active Stateful PCE 391 LSP operations for active stateful PCE (described in Section 5.8.2 of 392 [RFC8231]) are applicable for P2MP TE LSPs as well. 394 The extension for the Path Computation LSP Update (PCUpd) message for 395 active stateful operations on P2MP TE LSPs are described in 396 Section 6.2. 398 5.6.3. PCE-Initiated LSP 400 As per section 5.1 of [RFC8281], the PCE sends a Path Computation LSP 401 Initiate Request (PCInitiate) message to the PCC to suggest 402 instantiation or deletion of a P2P TE LSP. This document extends the 403 PCInitiate message to support P2MP TE LSPs (see details in 404 Section 6.5). 406 The P2MP TE LSPs suggested instantiation and deletion operations are 407 same as for P2P LSP as described in section 5.3 and 5.4 of [RFC8281]. 409 5.6.3.1. P2MP TE LSPs Instantiation 411 The Instantiation operation of P2MP TE LSPs is same as defined in 412 section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC- 413 PATH-NAME TLV etc. Rules of processing and error codes remains 414 unchanged. The N (P2MP) flag (Section 7.1) MUST be set in LSP object 415 in PCInitiate message by PCE to specify the instantiation is for P2MP 416 TE LSPs. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIERS 417 TLV SHOULD NOT be included in the LSP object in PCIntiitate message 418 (as it is generated by PCC and carried in PCRpt message instead) and 419 MUST be ignored on receipt. 421 5.6.3.2. P2MP TE LSPs Deletion 423 The deletion operation of P2MP TE LSPs is same as defined in section 424 5.4 of [RFC8281] by sending an LSP Initiate Message with an LSP 425 object carrying the PLSP-ID of the LSP to be removed and an SRP 426 object with the R flag set (LSP-REMOVE as per section 5.2 of 427 [RFC8281]). Rules of processing and error codes remains unchanged. 429 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 431 Adding of new leaves and Pruning of old Leaves for the PCE initiated 432 P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for 433 P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for 434 adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP 435 END-POINTS Object are used in PCUpd message. 437 PCC MAY use the Incremental State Update mechanism as described in 438 [RFC4875] to signal adding and pruning of leaves. 440 Section 3.10 of [RFC8306] defines the error-handling procedures when 441 adding new leaves to or removing old leaves from the existing P2MP 442 tree for PCReq message. The same error handling and error-codes are 443 also applicable to the stateful PCE messages as described in this 444 document. 446 5.6.3.4. P2MP TE LSPs Delegation and Cleanup 448 P2MP TE LSPs delegation and cleanup operations are same as defined in 449 section 6 of [RFC8281]. Rules of processing and error codes remains 450 unchanged. 452 6. PCEP Message Extensions 454 Message formats in this section, as those in [RFC8231], [RFC8281], 455 and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) 456 as specified in [RFC5511]. 458 6.1. The PCRpt Message 460 As per Section 6.1 of [RFC8231], PCRpt message is used to report the 461 current state of a P2P TE LSP. This document extends the PCRpt 462 message in reporting the status of P2MP TE LSPs. 464 The format of PCRpt message is as follows: 466 ::= 467 468 Where: 470 ::= 471 [] 473 ::= [] 474 475 476 [ 477 ] 478 [] 480 Where: 482 ::= 483 [] 484 [] 485 486 [] 488 ::= 489 [] 490 [] 491 492 [] 494 ::= (|) 495 [] 497 ::= (|) 498 [] 500 is defined in [RFC5440] and 501 extended by PCEP extensions. 502 consists of the actual computed and 503 signaled values of the and 504 objects defined in [RFC5440]. 506 The P2MP END-POINTS object defined in [RFC8306] is mandatory for 507 specifying address of P2MP leaves grouped based on leaf types. 509 o New leaves to add (leaf type = 1) 511 o Old leaves to remove (leaf type = 2) 512 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 514 o Old leaves whose path must be left unchanged (leaf type = 4) 516 When reporting the status of a P2MP TE LSP, the destinations MUST be 517 grouped in END-POINTS object based on the operational status (O field 518 in S2LS object) and leaf type (in END-POINTS). This way, leaves of 519 the same type that share the same operational status are grouped 520 together. For reporting the status of delegated P2MP TE LSPs leaf- 521 type = 3 is used, whereas for non-delegated P2MP TE LSPs, leaf-type = 522 4 is used. 524 For a delegated P2MP TE LSP configuration changes are reported via 525 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 526 type = 1) is used where as removing of old leaves (leaf-type = 2) is 527 used. 529 Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be 531 present in this message for P2MP LSP. 533 Note that the ordering of , 534 , , and 535 is done to retain compatibility with state 536 reports for the P2P LSPs as per [RFC8231]. 538 During state synchronization, the PCRpt message reports the status of 539 the full P2MP tree. 541 The S2LS object MUST be carried in PCRpt message along with END- 542 POINTS object when N (P2MP) flag is set in LSP object for P2MP TE 543 LSPs. If the S2LS object is missing, the receiving PCE MUST send a 544 PCErr message with Error-type=6 ("Mandatory Object missing") and 545 Error-value=13 (early allocated by IANA) ("S2LS object missing"). If 546 the END-POINTS object is missing, the receiving PCE MUST send a PCErr 547 message with Error-type=6 ("Mandatory Object missing") and Error- 548 value=3 ("END-POINTS object missing") (defined in [RFC5440]. 550 The S2LS object could be used in conjunction with the intended-path 551 (ERO) as well as the actual-path (RRO); for the same leaf, the state 552 encoded in the S2LS object associated with the actual-path MUST be 553 used over the intended-path. 555 If the E-bit (ERO-Compress bit) was set to 1 in the report, then the 556 path will be formed by an ERO followed by a list of SEROs or RRO 557 followed by a list of SRROs. 559 6.2. The PCUpd Message 561 As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P 562 TE LSP attributes. This document extends the PCUpd message in 563 updating the attributes of a P2MP TE LSP. 565 The format of a PCUpd message is as follows: 567 ::= 568 570 Where: 572 ::= 573 [] 575 ::= 576 577 578 580 Where: 582 ::= 583 [] 584 585 [] 587 ::= (|) 588 [] 590 is defined in [RFC5440] and 591 extended by PCEP extensions. 593 Note that the compatibility with the [RFC8231] definition of is preserved. 596 The PCC SHOULD use the make-before-break or sub-group-based 597 procedures described in [RFC4875] based on a local policy decision. 599 The END-POINTS object MUST be carried in PCUpd message when N flag is 600 set in LSP object for a P2MP TE LSP. If the END-POINTS object is 601 missing, the receiving PCC MUST send a PCErr message with Error- 602 type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS 603 object missing") (defined in [RFC5440]). 605 6.3. The PCReq Message 607 As per Section 3.4 of [RFC8306], PCReq message is used for a P2MP 608 Path Computation Request. This document extends the PCReq message 609 such that a PCC MAY include the LSP object in the PCReq message if 610 the stateful PCE P2MP capability has been negotiated on a PCEP 611 session between the PCC and a PCE. 613 The format of PCReq message is as follows: 615 ::= 616 [] 617 619 where: 621 ::= 622 [] 623 [] 624 [] 626 ::=[] 628 ::= 629 630 [] 631 [] 632 [] 633 [] 634 [] 635 [|] 636 [] 638 ::= 639 [[]] 640 [] 642 ::=(|)[] 643 ::=[] 645 6.4. The PCRep Message 647 As per Section 3.5 of [RFC8306], PCRep message is used for a P2MP 648 Path Computation Reply. This document extends the PCRep message such 649 that a PCE MAY include the LSP object in the PCRep message if the 650 stateful PCE P2MP capability has been negotiated on a PCEP session 651 between the PCC and a PCE. 653 The format of PCRep message is as follows: 655 ::= 656 658 where: 660 ::=[] 662 ::= 663 [] 664 [] 665 [] 666 [] 667 [] 669 ::= [] 670 671 [] 673 ::= (|) [] 675 ::=[] 676 [] 677 [] 678 [] 679 [] 681 6.5. The PCInitiate message 683 As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate 684 message to a PCC to recommend instantiation of a P2P TE LSP. This 685 document extends the format of PCInitiate message for the creation of 686 P2MP TE LSPs but the creation and deletion operations of P2MP TE LSPs 687 are same to the P2P TE LSPs. 689 The format of PCInitiate message is as follows: 691 ::= 692 693 Where: 695 ::= 696 [] 698 ::= 699 (|) 701 ::= 702 703 704 [] 706 ::= 707 709 Where: 711 ::= 712 [] 713 714 [] 716 ::= (|) 717 [] 719 is defined in [RFC5440] and extended 720 by PCEP extensions. 722 The PCInitiate message with an LSP object with N flag (P2MP) set is 723 used to convey operation on a P2MP TE LSP. The SRP object is used to 724 correlate between initiation requests sent by the PCE and the error 725 reports and state reports sent by the PCC as described in [RFC8231]. 727 The END-POINTS object MUST be carried in PCInitiate message when N 728 flag is set in LSP object for a P2MP TE LSP. If the END-POINTS 729 object is missing, the receiving PCC MUST send a PCErr message with 730 Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END- 731 POINTS object missing") (defined in [RFC5440]). 733 6.6. Example 734 6.6.1. P2MP TE LSPs Update Request 736 An LSP Update Request message is sent by an active stateful PCE to 737 update the P2MP TE LSPs parameters or attributes. An example of a 738 PCUpd message for P2MP TE LSPs is described below: 740 Common Header 741 SRP 742 LSP with P2MP flag set 743 END-POINTS for leaf type 3 744 ERO list 746 In this example, a stateful PCE requests an update of the path taken 747 to some of the leaves in a P2MP tree. The update request uses the 748 END-POINT type 3 (modified/reoptimized). The ERO list represents the 749 source to leaves path after modification. The update message does 750 not need to encode the full P2MP tree in this case. 752 6.6.2. P2MP TE LSP Report 754 The LSP State Report message is sent by a PCC to report or delegate 755 the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP 756 TE LSPs is described below to add new leaves to an existing P2MP TE 757 LSP: 759 Common Header 760 LSP with P2MP flag set 761 END-POINTS for leaf type 1 762 S2LS (O=DOWN) 763 ERO list (empty) 765 An example of a PCRpt message for a P2MP TE LSP is described below to 766 prune leaves from an existing P2MP TE LSP: 768 Common Header 769 LSP with P2MP flag set 770 END-POINTS for leaf type 2 771 S2LS (O=UP) 772 ERO list (empty) 774 An example of a PCRpt message for a delegated P2MP TE LSP is 775 described below to report status of leaves in an existing P2MP TE 776 LSP: 778 Common Header 779 SRP 780 LSP with P2MP flag set 781 END-POINTS for leaf type 3 782 S2LS (O=UP) 783 RRO list 784 END-POINTS for leaf type 3 785 S2LS (O=DOWN) 786 ERO list (empty) 788 In this example, the PCRpt message is in response to a PCUpd message 789 (with corresponding SRP) object indicating some leaves that are up 790 (with the actual path) and some are down. 792 An example of a PCRpt message for a non-delegated P2MP TE LSP is 793 described below to report status of leaves: 795 Common Header 796 LSP with P2MP flag set 797 END-POINTS for leaf type 4 798 S2LS (O=ACTIVE) 799 RRO list 800 END-POINTS for leaf type 4 801 S2LS (O=DOWN) 802 ERO list (empty) 804 6.6.3. P2MP TE LSPs Initiation Request 806 An LSP Initiation Request message is sent by an stateful PCE to 807 create a P2MP TE LSP. An example of a PCInitiate message for a P2MP 808 TE LSP is described below: 810 Common Header 811 SRP 812 LSP with P2MP flag set 813 END-POINTS for leaf type 1 814 ERO list 816 In this example, a stateful PCE request creation of a P2MP TE LSP. 817 The initiation request uses the END-POINT type 1 (new leaves). The 818 ERO list represents the source to leaves path. The initiate message 819 encodes the full P2MP tree in this case. 821 7. PCEP Object Extensions 823 The new PCEP TLVs defined in this document are in compliance with the 824 PCEP TLV format defined in [RFC5440]. 826 7.1. Extension of LSP Object 828 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 829 the PLSP-ID to uniquely identify an LSP that is constant for the life 830 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 831 identify a P2MP TE LSP uniquely. This document adds the following 832 flags to the LSP Object: 834 N (P2MP flag - 1 bit): If the N flag is set to 1, it indicates that 835 the message is for a P2MP TE LSP. 837 F (Fragmentation flag - 1 bit): If the F flag is unset (0), it 838 indicates that the LSP is not fragmented or it is the last piece 839 of the fragmented LSP. If the F flag is set to 1, it indicates 840 that the LSP is fragmented and this is not the last piece of the 841 fragmented LSP. The receiver needs to wait for additional 842 fragments until it receives an LSP with the same PLSP-ID and with 843 the F-bit set to 0. See Section 8 for further details. 845 E (ERO-compression flag - 1 bit): If the E flag is set to 1, it 846 indicates the route is in compressed format (that is, Secondary 847 Explicit Route Object (SERO) and Secondary Record Route Object 848 (SRRO) objects [RFC8306] are in use). 850 The flags defined in this section (N, F, E flags) are used in PCRpt, 851 PCUpd, or PCInitiate message. In case of PCReq and PCRep message, 852 these flags have no meaning and thus MUST be ignored. The 853 corresponding flags in the RP (Request Parameters) object are used as 854 described in [RFC8231]. 856 7.2. P2MP-LSP-IDENTIFIERS TLV 858 If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is 859 absent, the PCE MUST respond with a PCErr message carrying error-type 860 6 ("mandatory object missing") and error-value 14 (early allocated by 861 IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session. 863 The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the 864 PCUpd message for P2MP TE LSPs. The special value of all zeros for 865 this TLV is used to refer to all paths pertaining to a particular 866 PLSP-ID. 868 There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for 869 IPv6. 871 The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in the 872 Figure 6: 874 0 1 2 3 875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type=32 | Length=16 | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | IPv4 Tunnel Sender Address | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | LSP ID | Tunnel ID | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Extended Tunnel ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | P2MP ID | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Figure 6: IPV4-P2MP-LSP-IDENTIFIERS TLV format 890 The type (16-bits) of the TLV is 32 (early allocated by IANA). The 891 length (16-bits) has a fixed value of 16 octets. The value contains 892 the following fields: 894 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 895 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 896 Sender Template Object. 898 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 899 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 900 Object. 902 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 903 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 905 Extended Tunnel ID: contains the 32-bits 'Extended Tunnel ID' 906 identifier defined in [RFC3209], Section 4.6.1.1 for the 907 LSP_TUNNEL_IPv4 Session Object. 909 P2MP ID: contains the 32-bits 'P2MP ID' identifier defined in 910 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 911 Object. 913 The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in the 914 Figure 7: 916 0 1 2 3 917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type=33 | Length=40 | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | | 922 + + 923 | IPv6 tunnel sender address | 924 + (16 octets) + 925 | | 926 + + 927 | | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | LSP ID | Tunnel ID | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | | 932 + + 933 | Extended Tunnel ID | 934 + (16 octets) + 935 | | 936 + + 937 | | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | P2MP ID | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Figure 7: IPV6-P2MP-LSP-IDENTIFIERS TLV format 944 The type (16-bits) of the TLV is 33 (early allocated by IANA). The 945 length (16-bits) has a fixed length of 40 octets. The value contains 946 the following fields: 948 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 949 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 950 Sender Template Object. 952 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 953 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 954 Object. 956 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 957 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 959 Extended Tunnel ID: contains the 128-bits 'Extended Tunnel ID' 960 identifier defined in [RFC3209], Section 4.6.1.2 for the 961 LSP_TUNNEL_IPv6 Session Object. 963 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 965 Tunnel ID remains constant over the life time of a tunnel. 967 7.3. S2LS Object 969 The S2LS (Source-to-Leaves) Object is used to report state of one or 970 more destinations (leaves) encoded within the END-POINTS object for a 971 P2MP TE LSP. It MUST be carried in PCRpt message along with END- 972 POINTS object when N flag is set in LSP object. 974 S2LS Object-Class is 41 (Early allocated by IANA). 976 S2LS Object-Types is 1. 978 The format of the S2LS object is shown in the following figure: 980 0 1 2 3 981 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Flags | O| 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | | 986 // Optional TLVs // 987 | | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 Figure 8: S2LS object format 992 Flags(32-bits): the following flags are currently defined - 994 O(Operational - 3 bits) the O Field represents the operational 995 status of the group of destinations. The values are as per 996 Operational field in LSP object defined in Section 7.3 of 997 [RFC8231]. 999 Unassigned bits are reserved for future uses. They MUST be set to 0 1000 on transmission and MUST be ignored on receipt. 1002 When N flag is set in LSP object then the O field in LSP object 1003 represents the operational status of the full P2MP TE LSP and the O 1004 field in S2LS object represents the operational status of a group of 1005 destinations encoded within the END-POINTS object. If there is a 1006 conflict between the O field in the LSP and the S2LS object (for 1007 example, O field in LSP corresponds to down whereas the O field in 1008 S2LS is up), the PCEP speaker MUST generate an error with error-type 1009 10 ("Reception of an invalid object") and error-value TBD1 (to be 1010 allocated by IANA) ("Mis-match of O field in S2LS and LSP object"). 1012 Future documents might define optional TLVs that could be included in 1013 the S2LS Object. 1015 8. Message Fragmentation 1017 The total PCEP message length, including the common header, is 1018 (2^16)-1 bytes. In certain scenarios the P2MP report and update 1019 request may not fit into a single PCEP message (e.g. initial report 1020 or update). The F flag is used in the LSP object to signal that the 1021 initial report, update, or initiate message was too large to fit into 1022 a single message and will be fragmented into multiple messages. In 1023 order to identify the single report or update each message will use 1024 the same PLSP-ID. In order to identify that a series of PCInitiate 1025 messages represents a single Initiate, each message will use the same 1026 PLSP-ID (in this case 0) and SRP-ID-number. 1028 The fragmentation procedure described below for report or update 1029 message is similar to [RFC8306] which describes request and response 1030 message fragmentation. 1032 8.1. Report Fragmentation Procedure 1034 If the initial report is too large to fit into a single report 1035 message, the PCC will split the report over multiple messages. Each 1036 message sent to the PCE, except the last one, will have the F flag 1037 set in the LSP object to signify that the report has been fragmented 1038 into multiple messages. In order to identify that a series of report 1039 messages represents a single report, each message will use the same 1040 PLSP-ID. 1042 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1043 report any error associated with the fragmentation of a P2MP PCEP 1044 message. A new error-value 2 (early allocated by IANA) indicates 1045 "Fragmented report failure" and is used if a PCE does not receive the 1046 last part of the fragmented message. 1048 8.2. Update Fragmentation Procedure 1050 Once the PCE computes and updates a path for some or all leaves in a 1051 P2MP TE LSP, an update message is sent to the PCC. If the update is 1052 too large to fit into a single update message, the PCE will split the 1053 update over multiple messages. Each update message sent by the PCE, 1054 except the last one, will have the F flag set in the LSP object to 1055 signify that the update has been fragmented into multiple messages. 1056 In order to identify that a series of update messages represents a 1057 single update, each message will use the same PLSP-ID and SRP-ID- 1058 number. 1060 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1061 report any error associated with the fragmentation of a P2MP PCEP 1062 message. A new error-value 3 (early allocated by IANA) indicates 1063 "Fragmented update failure" and is used if a PCC does not receive the 1064 last part of the fragmented message. 1066 8.3. PCIntiate Fragmentation Procedure 1068 Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message 1069 is sent to the PCC. If the PCInitiate is too large to fit into a 1070 single PCInitiate message, the PCE will split the PCInitiate over 1071 multiple messages. Each PCInitiate message sent by the PCE, except 1072 the last one, will have the F flag set in the LSP object to signify 1073 that the PCInitiate has been fragmented into multiple messages. In 1074 order to identify that a series of PCInitiate messages represents a 1075 single Initiate, each message will use the same PLSP-ID (in this case 1076 0) and SRP-ID-number. 1078 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1079 report any error associated with the fragmentation of a P2MP PCEP 1080 message. A new error-value 4 (early allocated by IANA) indicates 1081 "Fragmented instantiation failure" and is used if a PCC does not 1082 receive the last part of the fragmented message. 1084 9. Non-Support of P2MP TE LSPs for Stateful PCE 1086 The PCEP extensions described in this document for stateful PCEs with 1087 P2MP capability MUST NOT be used if PCE has not advertised its 1088 stateful capability with P2MP as per Section 5.2. If the PCEP 1089 Speaker on the PCC supports the extensions of this draft (understands 1090 the P2MP flag in the LSP object) but did not advertise this 1091 capability, then upon receipt of PCUpd message from the PCE, it 1092 SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), 1093 error-value 12 (early allocated by IANA) ("Attempted LSP Update 1094 Request for P2MP if active stateful PCE capability for P2MP was not 1095 advertised") and terminate the PCEP session. If the PCEP Speaker on 1096 the PCE supports the extensions of this draft (understands the P2MP 1097 flag in the LSP object) but did not advertise this capability, then 1098 upon receipt of a PCRpt message from the PCC, it SHOULD generate a 1099 PCErr with error-type 19 ("Invalid Operation"), error-value 11 (early 1100 allocated by IANA) ("Attempted LSP State Report for P2MP if stateful 1101 PCE capability for P2MP was not advertised") and it SHOULD terminate 1102 the PCEP session. 1104 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1105 does not understand the P2MP flag in the LSP object, and therefore 1106 the PCEP extensions described in this document, then the Stateful PCE 1107 would act as per [RFC8231]. 1109 The PCEP extensions described in this document for PCC or PCE with 1110 instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or 1111 PCE has not advertised its stateful capability with Instantiation and 1112 P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC 1113 supports the extensions of this draft (understands the P (P2MP-LSP- 1114 INSTANTIATION-CAPABILITY) flag) but did not advertise this 1115 capability, then upon receipt of PCInitiate message from the PCE, it 1116 SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), 1117 error-value 13 (early allocated by IANA) ("Attempted LSP 1118 Instantiation Request for P2MP if stateful PCE instantiation 1119 capability for P2MP was not advertised") and terminate the PCEP 1120 session.. 1122 10. Manageability Considerations 1124 All manageability requirements and considerations listed in 1125 [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP 1126 extensions defined in this document. In addition, requirements and 1127 considerations listed in this section apply. 1129 10.1. Control of Function and Policy 1131 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1132 capability, the LSP Update capability, and the LSP Initiation 1133 capability for P2MP LSPs. 1135 10.2. Information and Data Models 1137 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1138 include advertised P2MP stateful capabilities, P2MP synchronization 1139 status, and delegation status of P2MP LSP etc. The statistics module 1140 should also count P2MP LSP related data. 1142 10.3. Liveness Detection and Monitoring 1144 Mechanisms defined in this document do not imply any new liveness 1145 detection and monitoring requirements in addition to those already 1146 listed in [RFC5440]. 1148 10.4. Verify Correct Operations 1150 Mechanisms defined in this document do not imply any new operation 1151 verification requirements in addition to those already listed in 1152 [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. 1154 10.5. Requirements On Other Protocols 1156 Mechanisms defined in this document do not imply any new requirements 1157 on other protocols. 1159 10.6. Impact On Network Operations 1161 Mechanisms defined in this document do not have any impact on network 1162 operations in addition to those already listed in [RFC5440], 1163 [RFC8306], [RFC8231], and [RFC8281]. 1165 Stateful PCE feature for P2MP LSP would help with network operations. 1167 11. IANA Considerations 1169 This document requests IANA to confirm the early allocation of the 1170 code-points for the protocol elements defined in this document. 1172 11.1. PCE Capabilities in IGP Advertisements 1174 IANA is requested to confirm the early allocation for the new bits in 1175 the OSPF Parameters "PCE Capability Flags" registry, as follows: 1177 Bit Meaning Reference 1178 13 Active Stateful [This.I-D] 1179 PCE with P2MP 1180 14 Passive Stateful [This.I-D] 1181 PCE with P2MP 1182 15 Stateful PCE [This.I-D] 1183 Initiation with P2MP 1185 11.2. STATEFUL-PCE-CAPABILITY TLV 1187 The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and the 1188 'STATEFUL-PCE-CAPABILITY TLV Flag Field' subregistry was created to 1189 manage the flags in the TLV. IANA is requested to confirm the early 1190 allocation of the following code-points in the aforementioned 1191 registry. 1193 Bit Description Reference 1195 25 P2MP-CAPABILITY [This.I-D] 1196 24 P2MP-LSP-UPDATE- [This.I-D] 1197 CAPABILITY 1198 23 P2MP-LSP- [This.I-D] 1199 INSTANTIATION- 1200 CAPABILITY 1202 11.3. LSP Object 1204 The LSP object is defined in [RFC8231] and the 'LSP Object Flag 1205 Field' subregistry was created to manage the Flags field of the LSP 1206 object. 1208 IANA is requested to confirm the early allocation of the following 1209 code-points in the aforementioned registry. 1211 Bit Description Reference 1213 3 P2MP [This.I-D] 1214 2 Fragmentation [This.I-D] 1216 Additionally, IANA is requested to allocate an additional code-point 1217 in this registry. 1219 Bit Description Reference 1221 TBD ERO-compression [This.I-D] 1223 11.4. PCEP-Error Object 1225 IANA is requested to confirm the early allocation of the new error 1226 values within the "PCEP-ERROR Object Error Types and Values" sub- 1227 registry of the PCEP Numbers registry, as follows: 1229 Error-Type Meaning 1230 6 Mandatory Object missing [RFC5440] 1231 Error-value=13: S2LS object missing 1232 Error-value=14: P2MP-LSP-IDENTIFIERS TLV missing 1233 18 P2MP Fragmentation Error [RFC8306] 1234 Error-value= 2. Fragmented Report 1235 failure 1236 Error-value= 3. Fragmented Update 1237 failure 1238 Error-value= 4. Fragmented Instantiation 1239 failure 1240 19 Invalid Operation [RFC8231] 1241 Error-value= 11. Attempted LSP State Report 1242 for P2MP if stateful PCE capability 1243 for P2MP was not advertised 1244 Error-value= 12. Attempted LSP Update Request 1245 for P2MP if active stateful PCE capability 1246 for P2MP was not advertised 1247 Error-value= 13. Attempted LSP Instantiation 1248 Request for P2MP if stateful PCE 1249 instantiation capability for P2MP was not 1250 advertised 1252 Reference for all new Error-Value above is [This.I-D]. 1254 Additionally, IANA is requested to allocate an additional code-point 1255 in this registry. 1257 Error-Type Meaning 1258 10 Reception of an invalid object [RFC5440] 1259 Error-value=TBD1: Mis-match of O field in S2LS 1260 and LSP object 1262 Reference for all new Error-Value above is [This.I-D]. 1264 11.5. PCEP TLV Type Indicators 1266 IANA is requested to confirm the early allocation of the following 1267 code-points in the existing "PCEP TLV Type Indicators" registry as 1268 follows: 1270 Value Meaning Reference 1271 32 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D] 1272 33 P2MP-IPV6-LSP-IDENTIFIERS [This.I-D] 1274 11.6. PCEP object 1276 IANA is requested to confirm the early allocation for the new object- 1277 class values and object types within the "PCEP Objects" sub-registry 1278 of the PCEP Numbers registry, as follows. 1280 Object-Class Value Name Reference 1282 41 S2LS [This.I-D] 1283 Object-Type 1284 0: Reserved 1285 1: S2LS 1287 11.7. S2LS object 1289 This document requests that a new sub-registry, named "S2LS Object 1290 Flag Field", is created within the "Path Computation Element Protocol 1291 (PCEP) Numbers" registry to manage the 32-bits Flag field of the S2LS 1292 object. New values are to be assigned by Standards Action [RFC8126]. 1293 Each bit should be tracked with the following qualities: 1295 o Bit number (counting from bit 0 as the most significant bit) 1297 o Capability description 1299 o Defining RFC 1301 The following values are defined in this document: 1303 Bit Description Reference 1305 29-31 Operational (3-bits) [This.I-D] 1306 0-28 Unassigned 1308 12. Security Considerations 1310 The stateful operations on P2MP TE LSPs are more CPU-intensive and 1311 also utilize more bandwidth on wire (in comparison to P2P TE LSPs). 1312 If a rogue PCC were able to request unauthorized stateful PCE 1313 operations then it may be able to mount a DoS attack against a PCE, 1314 which would disrupt the network and deny service to other PCCs. 1315 Consequently, it is important that implementations conform to the 1316 relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], 1317 and [RFC8281]. Securing the PCEP session using Transport Layer 1318 Security (TLS) [RFC8253], as per the recommendations and best current 1319 practices in [RFC7525], is RECOMMENDED. 1321 13. Acknowledgments 1323 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for the review 1324 comments. 1326 Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as 1327 document shepherds. 1329 Thanks to Andy Malis for the RTGDIR review. 1331 14. References 1333 14.1. Normative References 1335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1336 Requirement Levels", BCP 14, RFC 2119, 1337 DOI 10.17487/RFC2119, March 1997, 1338 . 1340 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1341 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1342 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1343 . 1345 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1346 Zhang, "OSPF Protocol Extensions for Path Computation 1347 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1348 January 2008, . 1350 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1351 Zhang, "IS-IS Protocol Extensions for Path Computation 1352 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1353 January 2008, . 1355 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1356 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1357 DOI 10.17487/RFC5440, March 2009, 1358 . 1360 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1361 Used to Form Encoding Rules in Various Routing Protocol 1362 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1363 2009, . 1365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1367 May 2017, . 1369 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1370 Computation Element Communication Protocol (PCEP) 1371 Extensions for Stateful PCE", RFC 8231, 1372 DOI 10.17487/RFC8231, September 2017, 1373 . 1375 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1376 and D. Dhody, "Optimizations of Label Switched Path State 1377 Synchronization Procedures for a Stateful PCE", RFC 8232, 1378 DOI 10.17487/RFC8232, September 2017, 1379 . 1381 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1382 Computation Element Communication Protocol (PCEP) 1383 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1384 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1385 . 1387 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1388 "Extensions to the Path Computation Element Communication 1389 Protocol (PCEP) for Point-to-Multipoint Traffic 1390 Engineering Label Switched Paths", RFC 8306, 1391 DOI 10.17487/RFC8306, November 2017, 1392 . 1394 14.2. Informative References 1396 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1397 Element (PCE)-Based Architecture", RFC 4655, 1398 DOI 10.17487/RFC4655, August 2006, 1399 . 1401 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1402 Yasukawa, Ed., "Extensions to Resource Reservation 1403 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1404 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1405 DOI 10.17487/RFC4875, May 2007, 1406 . 1408 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1409 Path Computation Element (PCE) to Point-to-Multipoint 1410 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1411 DOI 10.17487/RFC5671, October 2009, 1412 . 1414 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1415 "Recommendations for Secure Use of Transport Layer 1416 Security (TLS) and Datagram Transport Layer Security 1417 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1418 2015, . 1420 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1421 Stateful Path Computation Element (PCE)", RFC 8051, 1422 DOI 10.17487/RFC8051, January 2017, 1423 . 1425 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1426 Writing an IANA Considerations Section in RFCs", BCP 26, 1427 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1428 . 1430 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1431 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1432 Path Computation Element Communication Protocol (PCEP)", 1433 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1434 . 1436 [I-D.ietf-pce-pcep-yang] 1437 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1438 YANG Data Model for Path Computation Element 1439 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1440 yang-09 (work in progress), October 2018. 1442 Appendix A. Contributor Addresses 1444 Yuji Kamite 1445 NTT Communications Corporation 1446 Granpark Tower 1447 3-4-1 Shibaura, Minato-ku 1448 Tokyo 108-8118 1449 Japan 1451 EMail: y.kamite@ntt.com 1453 Authors' Addresses 1455 Udayasree Palle 1456 Huawei Technologies 1457 Divyashree Techno Park, Whitefield 1458 Bangalore, Karnataka 560066 1459 India 1461 EMail: udayasreereddy@gmail.com 1463 Dhruv Dhody 1464 Huawei Technologies 1465 Divyashree Techno Park, Whitefield 1466 Bangalore, Karnataka 560066 1467 India 1469 EMail: dhruv.ietf@gmail.com 1471 Yosuke Tanaka 1472 NTT Communications Corporation 1473 Granpark Tower 1474 3-4-1 Shibaura, Minato-ku 1475 Tokyo 108-8118 1476 Japan 1478 EMail: yosuke.tanaka@ntt.com 1480 Vishnu Pavan Beeram 1481 Juniper Networks 1483 EMail: vbeeram@juniper.net