idnits 2.17.00 (12 Aug 2021) /tmp/idnits65042/draft-ietf-pce-stateful-pce-p2mp-13.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 (April 12, 2019) is 1128 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 (-18) exists of draft-ietf-pce-pcep-yang-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: October 14, 2019 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 April 12, 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-13 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 October 14, 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.1.1. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . 19 93 7.2. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22 94 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23 95 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23 96 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 24 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 . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . 27 109 11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27 110 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 28 111 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 29 112 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 29 113 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 115 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 117 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 118 14.2. Informative References . . . . . . . . . . . . . . . . . 33 119 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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. 133 [RFC5671] examines the applicability of PCE for the path computation 134 for P2MP TE LSPs. 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 the 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 needed for stateful 173 operation of P2P TE LSPs. This document complements the previous 174 work by focusing on extensions that are necessary in order for the 175 deployment of stateful PCEs to support 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 contains the actual P2MP TE LSP path 250 attributes, the LSP status, etc. An LSP State Report carried in a 251 PCRpt message is also used in delegation or revocation of control 252 of a P2MP TE LSP to/from a PCE. The extension of PCRpt message is 253 described in 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 the same as defined in 412 section 5.3 of [RFC8281], including handling of PLSP-ID, SYMBOLIC- 413 PATH-NAME TLV, etc. The rules for processing and use of error codes 414 remains unchanged. The N (P2MP) flag (Section 7.1) MUST be set in 415 the LSP object in PCInitiate message by the PCE to specify that the 416 instantiation is for P2MP TE LSPs. Like the PLSP-ID (as per 417 [RFC8281]), the P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be included in 418 the LSP object in PCIntiitate messages and MUST be ignored on 419 receipt. These identifiers are generated by the PCC on receipt of 420 PCIntiitate message and reported via PCRpt message to the PCE. 422 5.6.3.2. P2MP TE LSPs Deletion 424 The deletion operation of P2MP TE LSPs is the same as defined in 425 section 5.4 of [RFC8281] by sending an LSP Initiate Message with an 426 LSP object carrying the PLSP-ID of the LSP to be removed and an SRP 427 object with the R flag set (LSP-REMOVE as per section 5.2 of 428 [RFC8281]). Rules of processing and error codes remains unchanged. 430 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 432 Adding of new leaves and Pruning of old Leaves for the PCE initiated 433 P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for 434 P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for 435 adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP 436 END-POINTS Object are used in PCUpd message. 438 PCC MAY use the Incremental State Update mechanism as described in 439 [RFC4875] to signal adding and pruning of leaves. 441 Section 3.10 of [RFC8306] defines the error-handling procedures when 442 adding new leaves to or removing old leaves from the existing P2MP 443 tree for PCReq message. The same error handling and error-codes are 444 also applicable to the stateful PCE messages as described in this 445 document. 447 5.6.3.4. P2MP TE LSPs Delegation and Cleanup 449 P2MP TE LSPs delegation and cleanup operations are same as defined in 450 section 6 of [RFC8281]. Rules of processing and error codes remains 451 unchanged. 453 6. PCEP Message Extensions 455 Message formats in this section, as those in [RFC8231], [RFC8281], 456 and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) 457 as specified in [RFC5511]. 459 6.1. The PCRpt Message 461 As per Section 6.1 of [RFC8231], PCRpt message is used to report the 462 current state of a P2P TE LSP. This document extends the PCRpt 463 message in reporting the status of P2MP TE LSPs. 465 The format of PCRpt message is as follows: 467 ::= 468 469 Where: 471 ::= 472 [] 474 ::= [] 475 476 478 Where: 479 ::= 480 [ 481 ] 482 [] 484 ::= 485 [] 486 [] 487 488 [] 490 ::= 491 [] 492 [] 493 494 [] 496 ::= (|) 497 [] 499 ::= (|) 500 [] 502 is defined in [RFC5440] and 503 extended by PCEP extensions. 504 consists of the actual computed and 505 signaled values of the and 506 objects defined in [RFC5440]. 508 The P2MP END-POINTS object defined in [RFC8306] is mandatory for 509 specifying address of P2MP leaves, grouped by leaf types. 511 o New leaves to add (leaf type = 1) 513 o Old leaves to remove (leaf type = 2) 514 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 516 o Old leaves whose path must be left unchanged (leaf type = 4) 518 When reporting the status of a P2MP TE LSP, the destinations MUST be 519 grouped in END-POINTS object based on the operational status (O field 520 in S2LS object) and leaf type (in END-POINTS). This way, leaves of 521 the same type that share the same operational status can be grouped 522 together. For reporting the status of delegated P2MP TE LSPs leaf 523 type = 3 is used, whereas for non-delegated P2MP TE LSPs, leaf type = 524 4 is used. 526 For a delegated P2MP TE LSP configuration changes are reported via 527 PCRpt message. For example, adding of new leaves END-POINTS (leaf 528 type = 1) is used, and removing of old leaves (leaf type = 2) is 529 used. 531 Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be 533 present in this message for P2MP LSP. 535 Note that the ordering of , 536 , , and 537 is done to retain compatibility with state 538 reports for the P2P LSPs as per [RFC8231]. 540 During state synchronization, the PCRpt message reports the status of 541 the full P2MP tree. 543 The S2LS object MUST be carried in PCRpt message along with END- 544 POINTS object when N (P2MP) flag is set in LSP object for P2MP TE 545 LSPs. If the S2LS object is missing, the receiving PCE MUST send a 546 PCErr message with Error-type=6 ("Mandatory Object missing") and 547 Error-value=13 (early allocated by IANA) ("S2LS object missing"). If 548 the END-POINTS object is missing, the receiving PCE MUST send a PCErr 549 message with Error-type=6 ("Mandatory Object missing") and Error- 550 value=3 ("END-POINTS object missing") (defined in [RFC5440]. 552 The S2LS object could be used in conjunction with the intended-path 553 (ERO) as well as the actual-path (RRO); for the same leaf, the state 554 encoded in the S2LS object associated with the actual-path MUST be 555 used over the intended-path. 557 If the E-bit (ERO-Compress bit) was set to 1 in the report, then the 558 path will be formed by an ERO followed by a list of SEROs or RRO 559 followed by a list of SRROs. 561 6.2. The PCUpd Message 563 As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P 564 TE LSP attributes. This document extends the PCUpd message in 565 updating the attributes of a P2MP TE LSP. 567 The format of a PCUpd message is as follows: 569 ::= 570 572 Where: 574 ::= 575 [] 577 ::= 578 579 581 Where: 582 ::= 583 585 ::= 586 [] 587 588 [] 590 ::= (|) 591 [] 593 is the attribute-list 594 defined in [RFC5440] and extended by PCEP extensions. 596 Note that the compatibility with the [RFC8231] definition of is preserved. 599 The PCC SHOULD use the make-before-break or sub-group-based 600 procedures described in [RFC4875] based on a local policy decision. 602 The END-POINTS object MUST be carried in PCUpd message when N flag is 603 set in LSP object for a P2MP TE LSP. If the END-POINTS object is 604 missing, the receiving PCC MUST send a PCErr message with Error- 605 type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS 606 object missing") (defined in [RFC5440]). 608 6.3. The PCReq Message 610 As per Section 3.4 of [RFC8306], PCReq message is used for a P2MP 611 Path Computation Request. This document extends the PCReq message 612 such that a PCC MAY include the LSP object in the PCReq message if 613 the stateful PCE P2MP capability has been negotiated on a PCEP 614 session between the PCC and a PCE. 616 The format of PCReq message is as follows: 618 ::= 619 [] 620 622 where: 624 ::= 625 [] 626 [] 627 [] 629 ::=[] 631 ::= 632 633 [] 634 [] 635 [] 636 [] 637 [] 638 [|] 639 [] 641 ::= 642 [[]] 643 [] 645 ::=(|)[] 646 ::=[] 648 6.4. The PCRep Message 650 As per Section 3.5 of [RFC8306], PCRep message is used for a P2MP 651 Path Computation Reply. This document extends the PCRep message such 652 that a PCE MAY include the LSP object in the PCRep message if the 653 stateful PCE P2MP capability has been negotiated on a PCEP session 654 between the PCC and a PCE. 656 The format of PCRep message is as follows: 658 ::= 659 661 where: 663 ::=[] 665 ::= 666 [] 667 [] 668 [] 669 [] 670 [] 672 ::= [] 673 674 [] 676 ::= (|) [] 678 ::=[] 679 [] 680 [] 681 [] 682 [] 684 6.5. The PCInitiate message 686 As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate 687 message to a PCC to recommend instantiation of a P2P TE LSP. This 688 document extends the format of PCInitiate message for the creation of 689 P2MP TE LSPs but the creation and deletion operations of P2MP TE LSPs 690 are same to the P2P TE LSPs. 692 The format of PCInitiate message is as follows: 694 ::= 695 696 Where: 698 ::= 699 [] 701 ::= 702 (|) 704 ::= 705 706 707 [] 709 ::= 710 712 Where: 714 ::= 715 [] 716 717 [] 719 ::= (|) 720 [] 722 is defined in [RFC5440] and extended 723 by PCEP extensions. 725 The PCInitiate message with an LSP object with N flag (P2MP) set is 726 used to convey operation on a P2MP TE LSP. The SRP object is used to 727 correlate between initiation requests sent by the PCE and the error 728 reports and state reports sent by the PCC as described in [RFC8231]. 730 The END-POINTS object MUST be carried in PCInitiate message when N 731 flag is set in LSP object for a P2MP TE LSP. If the END-POINTS 732 object is missing, the receiving PCC MUST send a PCErr message with 733 Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END- 734 POINTS object missing") (defined in [RFC5440]). 736 6.6. Example 737 6.6.1. P2MP TE LSPs Update Request 739 An LSP Update Request message is sent by an active stateful PCE to 740 update the P2MP TE LSPs parameters or attributes. An example of a 741 PCUpd message for P2MP TE LSPs is described below: 743 Common Header 744 SRP 745 LSP with P2MP flag set 746 END-POINTS for leaf type 3 747 ERO list 749 In this example, a stateful PCE requests an update of the path taken 750 to some of the leaves in a P2MP tree. The update request uses the 751 END-POINT type 3 (modified/reoptimized). The ERO list represents the 752 source to leaves path after modification. The update message does 753 not need to encode the full P2MP tree in this case. 755 6.6.2. P2MP TE LSP Report 757 The LSP State Report message is sent by a PCC to report or delegate 758 the P2MP TE LSP. The leaves of the P2MP TE LSP are grouped in the 759 END-POINTS object based on the operational status and the leaf type. 760 An example of a PCRpt message for a delegated P2MP TE LSPs is 761 described below to add new leaves to an existing P2MP TE LSP: 763 Common Header 764 LSP with P2MP flag set 765 END-POINTS for leaf type 1 (add) 766 S2LS (O=DOWN) 767 ERO list (empty) 769 An example of a PCRpt message for a P2MP TE LSP is described below to 770 prune leaves from an existing P2MP TE LSP: 772 Common Header 773 LSP with P2MP flag set 774 END-POINTS for leaf type 2 (remove) 775 S2LS (O=UP) 776 ERO list (empty) 778 An example of a PCRpt message for a delegated P2MP TE LSP is 779 described below to report status of leaves in an existing P2MP TE 780 LSP: 782 Common Header 783 SRP 784 LSP with P2MP flag set 785 END-POINTS for leaf type 3 (modify) 786 S2LS (O=UP) 787 RRO list 788 END-POINTS for leaf type 3 (modify) 789 S2LS (O=DOWN) 790 ERO list (empty) 792 In this example, the PCRpt message is in response to a PCUpd message 793 (with corresponding SRP) object indicating some leaves that are up 794 (with the actual path) and some are down. 796 An example of a PCRpt message for a non-delegated P2MP TE LSP is 797 described below to report status of leaves: 799 Common Header 800 LSP with P2MP flag set 801 END-POINTS for leaf type 4 (unchanged) 802 S2LS (O=ACTIVE) 803 RRO list 804 END-POINTS for leaf type 4 (unchanged) 805 S2LS (O=DOWN) 806 ERO list (empty) 808 6.6.3. P2MP TE LSPs Initiation Request 810 An LSP Initiation Request message is sent by an stateful PCE to 811 create a P2MP TE LSP. An example of a PCInitiate message for a P2MP 812 TE LSP is described below: 814 Common Header 815 SRP 816 LSP with P2MP flag set 817 END-POINTS for leaf type 1 (add) 818 ERO list 820 In this example, a stateful PCE request creation of a P2MP TE LSP. 821 The initiation request uses the END-POINT type 1 (new leaves). The 822 ERO list represents the source to leaves path. The initiate message 823 encodes the full P2MP tree in this case. 825 7. PCEP Object Extensions 827 The new PCEP TLVs defined in this document are in compliance with the 828 PCEP TLV format defined in [RFC5440]. 830 7.1. Extension of LSP Object 832 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 833 the PLSP-ID to uniquely identify an LSP that is constant for the life 834 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 835 identify a P2MP TE LSP uniquely. This document adds the following 836 flags to the LSP Object: 838 N (P2MP flag - 1 bit): If the N flag is set to 1, it indicates that 839 the message is for a P2MP TE LSP. 841 F (Fragmentation flag - 1 bit): If the F flag is unset (0), it 842 indicates that the LSP is not fragmented or it is the last piece 843 of the fragmented LSP. If the F flag is set to 1, it indicates 844 that the LSP is fragmented and this is not the last piece of the 845 fragmented LSP. The receiver needs to wait for additional 846 fragments until it receives an LSP with the same PLSP-ID and with 847 the F-bit set to 0. See Section 8 for further details. 849 E (ERO-compression flag - 1 bit): If the E flag is set to 1, it 850 indicates the route is in compressed format (that is, Secondary 851 Explicit Route Object (SERO) and Secondary Record Route Object 852 (SRRO) objects [RFC8306] are in use). 854 The flags defined in this section (N, F, E flags) are used in PCRpt, 855 PCUpd, or PCInitiate message. In case of PCReq and PCRep message, 856 these flags have no meaning and thus MUST be ignored. The 857 corresponding flags in the RP (Request Parameters) object are used as 858 described in [RFC8306]. 860 7.1.1. P2MP-LSP-IDENTIFIERS TLV 862 [RFC8231] specify the LSP-IDENTIFIERS TLVs to be included in the LSP 863 object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS 864 TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, 865 one for IPv4 and one for IPv6. The P2MP-LSP-IDENTIFIERS TLV MUST be 866 included in the LSP object in PCRpt message for P2MP TE LSPs. If the 867 N bit is set in the LSP object in the PCRpt message but the P2MP-LSP- 868 IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message 869 carrying error-type 6 ("mandatory object missing") and error-value 14 870 (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and 871 close the PCEP session. 873 The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the 874 PCUpd message for P2MP TE LSPs. The special value of all zeros for 875 all the fields in the value portion of the TLV is used to refer to 876 all paths pertaining to a particular PLSP-ID. The length of the TLV 877 remains fixed based on the IP version. 879 The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in PCInitiate (see 880 Section 5.6.3.1) and MAY optionally be included in the LSP object in 881 the PCReq and the PCRep message for P2MP TE LSP. 883 The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in the 884 Figure 6: 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Type=32 | Length=16 | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | IPv4 Tunnel Sender Address | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | LSP ID | Tunnel ID | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Extended Tunnel ID | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | P2MP ID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Figure 6: IPV4-P2MP-LSP-IDENTIFIERS TLV format 902 The type (16-bits) of the TLV is 32 (early allocated by IANA). The 903 length (16-bits) has a fixed value of 16 octets. The value contains 904 the following fields: 906 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 907 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 908 Sender Template Object. 910 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 911 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 912 Object. 914 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 915 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 917 Extended Tunnel ID: contains the 32-bits 'Extended Tunnel ID' 918 identifier defined in [RFC3209], Section 4.6.1.1 for the 919 LSP_TUNNEL_IPv4 Session Object. 921 P2MP ID: contains the 32-bits 'P2MP ID' identifier defined in 922 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 923 Object. 925 The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in the 926 Figure 7: 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Type=33 | Length=40 | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 + + 935 | IPv6 tunnel sender address | 936 + (16 octets) + 937 | | 938 + + 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | LSP ID | Tunnel ID | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | | 944 + + 945 | Extended Tunnel ID | 946 + (16 octets) + 947 | | 948 + + 949 | | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | P2MP ID | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Figure 7: IPV6-P2MP-LSP-IDENTIFIERS TLV format 956 The type (16-bits) of the TLV is 33 (early allocated by IANA). The 957 length (16-bits) has a fixed length of 40 octets. The value contains 958 the following fields: 960 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 961 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 962 Sender Template Object. 964 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 965 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 966 Object. 968 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 969 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 971 Extended Tunnel ID: contains the 128-bits 'Extended Tunnel ID' 972 identifier defined in [RFC3209], Section 4.6.1.2 for the 973 LSP_TUNNEL_IPv6 Session Object. 975 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 977 Tunnel ID remains constant over the life time of a tunnel. 979 7.2. S2LS Object 981 The S2LS (Source-to-Leaves) Object is used to report state of one or 982 more destinations (leaves) encoded within the END-POINTS object for a 983 P2MP TE LSP. It MUST be carried in PCRpt message along with END- 984 POINTS object when N flag is set in LSP object. 986 S2LS Object-Class is 41 (Early allocated by IANA). 988 S2LS Object-Types is 1. 990 The format of the S2LS object is shown in the following figure: 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Flags | O| 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | | 998 // Optional TLVs // 999 | | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Figure 8: S2LS object format 1004 Flags(32-bits): the following flags are currently defined - 1006 O(Operational - 3 bits) the O Field represents the operational 1007 status of the group of destinations. The values are as per 1008 Operational field in LSP object defined in Section 7.3 of 1009 [RFC8231]. 1011 Unassigned bits are reserved for future uses. They MUST be set to 0 1012 on transmission and MUST be ignored on receipt. 1014 When N flag is set in LSP object then the O field in LSP object 1015 represents the operational status of the full P2MP TE LSP and the O 1016 field in S2LS object represents the operational status of a group of 1017 destinations encoded within the END-POINTS object. If there is a 1018 conflict between the O field in the LSP and the S2LS object (for 1019 example, O field in LSP corresponds to down whereas the O field in 1020 S2LS is up), the PCEP speaker MUST generate an error with error-type 1021 10 ("Reception of an invalid object") and error-value TBD1 (to be 1022 allocated by IANA) ("Mis-match of O field in S2LS and LSP object"). 1024 Future documents might define optional TLVs that could be included in 1025 the S2LS Object. 1027 8. Message Fragmentation 1029 The total PCEP message length, including the common header, is 1030 (2^16)-1 bytes. In certain scenarios the P2MP report and update 1031 request may not fit into a single PCEP message (e.g. initial report 1032 or update). The F flag is used in the LSP object to signal that the 1033 initial report, update, or initiate message was too large to fit into 1034 a single message and will be fragmented into multiple messages. In 1035 order to identify the single report or update each message will use 1036 the same PLSP-ID. In order to identify that a series of PCInitiate 1037 messages represents a single Initiate, each message will use the same 1038 PLSP-ID (in this case 0) and SRP-ID-number. 1040 The fragmentation procedure described below for report or update 1041 message is similar to [RFC8306] which describes request and response 1042 message fragmentation. 1044 8.1. Report Fragmentation Procedure 1046 If the initial report is too large to fit into a single report 1047 message, the PCC will split the report over multiple messages. Each 1048 message sent to the PCE, except the last one, will have the F flag 1049 set in the LSP object to signify that the report has been fragmented 1050 into multiple messages. In order to identify that a series of report 1051 messages represents a single report, each message will use the same 1052 PLSP-ID. 1054 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1055 report any error associated with the fragmentation of a P2MP PCEP 1056 message. A new error-value 2 (early allocated by IANA) indicates 1057 "Fragmented report failure" and is used if a PCE does not receive the 1058 last part of the fragmented message. 1060 8.2. Update Fragmentation Procedure 1062 Once the PCE computes and updates a path for some or all leaves in a 1063 P2MP TE LSP, an update message is sent to the PCC. If the update is 1064 too large to fit into a single update message, the PCE will split the 1065 update over multiple messages. Each update message sent by the PCE, 1066 except the last one, will have the F flag set in the LSP object to 1067 signify that the update has been fragmented into multiple messages. 1068 In order to identify that a series of update messages represents a 1069 single update, each message will use the same PLSP-ID and SRP-ID- 1070 number. 1072 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1073 report any error associated with the fragmentation of a P2MP PCEP 1074 message. A new error-value 3 (early allocated by IANA) indicates 1075 "Fragmented update failure" and is used if a PCC does not receive the 1076 last part of the fragmented message. 1078 8.3. PCIntiate Fragmentation Procedure 1080 Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message 1081 is sent to the PCC. If the PCInitiate is too large to fit into a 1082 single PCInitiate message, the PCE will split the PCInitiate over 1083 multiple messages. Each PCInitiate message sent by the PCE, except 1084 the last one, will have the F flag set in the LSP object to signify 1085 that the PCInitiate has been fragmented into multiple messages. In 1086 order to identify that a series of PCInitiate messages represents a 1087 single Initiate, each message will use the same PLSP-ID (in this case 1088 0) and SRP-ID-number. 1090 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1091 report any error associated with the fragmentation of a P2MP PCEP 1092 message. A new error-value 4 (early allocated by IANA) indicates 1093 "Fragmented instantiation failure" and is used if a PCC does not 1094 receive the last part of the fragmented message. 1096 9. Non-Support of P2MP TE LSPs for Stateful PCE 1098 The PCEP extensions described in this document for stateful PCEs with 1099 P2MP capability MUST NOT be used if PCE has not advertised its 1100 stateful capability with P2MP as per Section 5.2. If the PCC 1101 supports the extensions as per this document (understands the N 1102 (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) flags in the LSP 1103 object) but did not advertise this capability, then upon receipt of 1104 PCUpd message from the PCE, it SHOULD generate a PCErr with error- 1105 type 19 ("Invalid Operation"), error-value 12 (early allocated by 1106 IANA) ("Attempted LSP Update Request for P2MP if active stateful PCE 1107 capability for P2MP was not advertised") and terminate the PCEP 1108 session. If the PCE supports the extensions as per this document 1109 (understands the N (P2MP-CAPABILITY) flag in the LSP object) but did 1110 not advertise this capability, then upon receipt of a PCRpt message 1111 from the PCC, it SHOULD generate a PCErr with error-type 19 ("Invalid 1112 Operation"), error-value 11 (early allocated by IANA) ("Attempted LSP 1113 State Report for P2MP if stateful PCE capability for P2MP was not 1114 advertised") and it SHOULD terminate the PCEP session. 1116 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1117 does not understand the N (P2MP-CAPABILITY) flag in the LSP object, 1118 and therefore the PCEP extensions described in this document, then 1119 the Stateful PCE would act as per Section 6.1 of [RFC8231] (and 1120 consider the PCRpt message as invalid). 1122 The PCEP extensions described in this document for PCC or PCE with 1123 instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or 1124 PCE has not advertised its stateful capability with Instantiation and 1125 P2MP capability as per Section 5.2. If the PCC supports the 1126 extensions as per this document (understands the P (P2MP-LSP- 1127 INSTANTIATION-CAPABILITY) flag) but did not advertise this 1128 capability, then upon receipt of PCInitiate message from the PCE, it 1129 SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), 1130 error-value 13 (early allocated by IANA) ("Attempted LSP 1131 Instantiation Request for P2MP if stateful PCE instantiation 1132 capability for P2MP was not advertised") and terminate the PCEP 1133 session.. 1135 10. Manageability Considerations 1137 All manageability requirements and considerations listed in 1138 [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP 1139 extensions defined in this document. In addition, requirements and 1140 considerations listed in this section apply. 1142 10.1. Control of Function and Policy 1144 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1145 capability, the LSP Update capability, and the LSP Initiation 1146 capability for P2MP LSPs. 1148 10.2. Information and Data Models 1150 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1151 include advertised P2MP stateful capabilities, P2MP synchronization 1152 status, and delegation status of P2MP LSP etc. The statistics module 1153 should also count P2MP LSP related data. 1155 10.3. Liveness Detection and Monitoring 1157 Mechanisms defined in this document do not imply any new liveness 1158 detection and monitoring requirements in addition to those already 1159 listed in [RFC5440]. 1161 10.4. Verify Correct Operations 1163 Mechanisms defined in this document do not imply any new operation 1164 verification requirements in addition to those already listed in 1165 [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. 1167 10.5. Requirements On Other Protocols 1169 Mechanisms defined in this document do not imply any new requirements 1170 on other protocols. 1172 10.6. Impact On Network Operations 1174 Mechanisms defined in this document do not have any impact on network 1175 operations in addition to those already listed in [RFC5440], 1176 [RFC8306], [RFC8231], and [RFC8281]. 1178 Stateful PCE feature for P2MP LSP would help with network operations. 1180 11. IANA Considerations 1182 This document requests IANA to confirm the early allocation of the 1183 code-points for the protocol elements defined in this document. 1185 11.1. PCE Capabilities in IGP Advertisements 1187 IANA is requested to confirm the early allocation for the new bits in 1188 the OSPF Parameters "PCE Capability Flags" registry, as follows: 1190 Bit Meaning Reference 1191 13 Active Stateful [This.I-D] 1192 PCE with P2MP 1193 14 Passive Stateful [This.I-D] 1194 PCE with P2MP 1195 15 Stateful PCE [This.I-D] 1196 Initiation with P2MP 1198 11.2. STATEFUL-PCE-CAPABILITY TLV 1200 The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and the 1201 'STATEFUL-PCE-CAPABILITY TLV Flag Field' subregistry was created to 1202 manage the flags in the TLV. IANA is requested to confirm the early 1203 allocation of the following code-points in the aforementioned 1204 registry. 1206 Bit Description Reference 1208 25 P2MP-CAPABILITY [This.I-D] 1209 24 P2MP-LSP-UPDATE- [This.I-D] 1210 CAPABILITY 1211 23 P2MP-LSP- [This.I-D] 1212 INSTANTIATION- 1213 CAPABILITY 1215 11.3. LSP Object 1217 The LSP object is defined in [RFC8231] and the 'LSP Object Flag 1218 Field' subregistry was created to manage the Flags field of the LSP 1219 object. 1221 IANA is requested to confirm the early allocation of the following 1222 code-points in the aforementioned registry. 1224 Bit Description Reference 1226 3 P2MP [This.I-D] 1227 2 Fragmentation [This.I-D] 1229 Additionally, IANA is requested to allocate an additional code-point 1230 in this registry. 1232 Bit Description Reference 1234 TBD ERO-compression [This.I-D] 1236 11.4. PCEP-Error Object 1238 IANA is requested to confirm the early allocation of the new error 1239 values within the "PCEP-ERROR Object Error Types and Values" sub- 1240 registry of the PCEP Numbers registry, as follows: 1242 Error-Type Meaning 1243 6 Mandatory Object missing [RFC5440] 1244 Error-value=13: S2LS object missing 1245 Error-value=14: P2MP-LSP-IDENTIFIERS TLV missing 1246 18 P2MP Fragmentation Error [RFC8306] 1247 Error-value= 2. Fragmented Report 1248 failure 1249 Error-value= 3. Fragmented Update 1250 failure 1251 Error-value= 4. Fragmented Instantiation 1252 failure 1253 19 Invalid Operation [RFC8231] 1254 Error-value= 11. Attempted LSP State Report 1255 for P2MP if stateful PCE capability 1256 for P2MP was not advertised 1257 Error-value= 12. Attempted LSP Update Request 1258 for P2MP if active stateful PCE capability 1259 for P2MP was not advertised 1260 Error-value= 13. Attempted LSP Instantiation 1261 Request for P2MP if stateful PCE 1262 instantiation capability for P2MP was not 1263 advertised 1265 Reference for all new Error-Value above is [This.I-D]. 1267 Additionally, IANA is requested to allocate an additional code-point 1268 in this registry. 1270 Error-Type Meaning 1271 10 Reception of an invalid object [RFC5440] 1272 Error-value=TBD1: Mis-match of O field in S2LS 1273 and LSP object 1275 Reference for all new Error-Value above is [This.I-D]. 1277 11.5. PCEP TLV Type Indicators 1279 IANA is requested to confirm the early allocation of the following 1280 code-points in the existing "PCEP TLV Type Indicators" registry as 1281 follows: 1283 Value Meaning Reference 1284 32 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D] 1285 33 P2MP-IPV6-LSP-IDENTIFIERS [This.I-D] 1287 11.6. PCEP object 1289 IANA is requested to confirm the early allocation for the new object- 1290 class values and object types within the "PCEP Objects" sub-registry 1291 of the PCEP Numbers registry, as follows. 1293 Object-Class Value Name Reference 1295 41 S2LS [This.I-D] 1296 Object-Type 1297 0: Reserved 1298 1: S2LS 1300 11.7. S2LS object 1302 This document requests that a new sub-registry, named "S2LS Object 1303 Flag Field", is created within the "Path Computation Element Protocol 1304 (PCEP) Numbers" registry to manage the 32-bits Flag field of the S2LS 1305 object. New values are to be assigned by Standards Action [RFC8126]. 1306 Each bit should be tracked with the following qualities: 1308 o Bit number (counting from bit 0 as the most significant bit) 1310 o Capability description 1312 o Defining RFC 1314 The following values are defined in this document: 1316 Bit Description Reference 1318 29-31 Operational (3-bits) [This.I-D] 1319 0-28 Unassigned 1321 12. Security Considerations 1323 The stateful operations on P2MP TE LSPs are more CPU-intensive and 1324 also utilize more bandwidth on wire (in comparison to P2P TE LSPs). 1325 If a rogue PCC were able to request unauthorized stateful PCE 1326 operations then it may be able to mount a DoS attack against a PCE, 1327 which would disrupt the network and deny service to other PCCs. 1328 Similarly an attacker may flood the PCC with PCUpd messages at a rate 1329 that exceeds either the PCC's ability to process them or the 1330 network's ability to signal the changes, by either spoofing messages 1331 or compromising the PCE itself. 1333 Consequently, it is important that implementations conform to the 1334 relevant security requirements as listed below - 1336 o As per [RFC8231], it is RECOMMENDED that these PCEP extensions 1337 only be activated on authenticated and encrypted sessions across 1338 PCEs and PCCs belonging to the same administrative authority, 1339 using Transport Layer Security (TLS) [RFC8253], as per the 1340 recommendations and best current practices in [RFC7525] (unless 1341 explicitly set aside in [RFC8253]). 1343 o Security considerations for path computation requests and 1344 responses are as per [RFC8306]. 1346 o Security considerations for stateful operations (such as state 1347 report, synchronization, delegation, update, etc.) are as per 1348 [RFC8231]. 1350 o Security considerations for LSP instantiation mechanism are as per 1351 [RFC8231]. 1353 o Security considerations as stated in Section 10.1, Section 10.6, 1354 and Section 10.7 of [RFC5440] continue to apply. 1356 13. Acknowledgments 1358 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for the review 1359 comments. 1361 Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as 1362 document shepherds. 1364 Thanks to Andy Malis for the RTGDIR review. Thanks to Donald 1365 Eastlake for the SECDIR review. Thanks to David Schinazi for the 1366 GENART review. 1368 Thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and 1369 Benjamin Kaduk for the IESG reviews. 1371 14. References 1373 14.1. Normative References 1375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1376 Requirement Levels", BCP 14, RFC 2119, 1377 DOI 10.17487/RFC2119, March 1997, 1378 . 1380 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1381 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1382 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1383 . 1385 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1386 Yasukawa, Ed., "Extensions to Resource Reservation 1387 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1388 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1389 DOI 10.17487/RFC4875, May 2007, 1390 . 1392 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1393 Zhang, "OSPF Protocol Extensions for Path Computation 1394 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1395 January 2008, . 1397 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1398 Zhang, "IS-IS Protocol Extensions for Path Computation 1399 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1400 January 2008, . 1402 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1403 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1404 DOI 10.17487/RFC5440, March 2009, 1405 . 1407 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1408 Used to Form Encoding Rules in Various Routing Protocol 1409 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1410 2009, . 1412 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1413 "Recommendations for Secure Use of Transport Layer 1414 Security (TLS) and Datagram Transport Layer Security 1415 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1416 2015, . 1418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1420 May 2017, . 1422 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1423 Computation Element Communication Protocol (PCEP) 1424 Extensions for Stateful PCE", RFC 8231, 1425 DOI 10.17487/RFC8231, September 2017, 1426 . 1428 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1429 and D. Dhody, "Optimizations of Label Switched Path State 1430 Synchronization Procedures for a Stateful PCE", RFC 8232, 1431 DOI 10.17487/RFC8232, September 2017, 1432 . 1434 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1435 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1436 Path Computation Element Communication Protocol (PCEP)", 1437 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1438 . 1440 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1441 Computation Element Communication Protocol (PCEP) 1442 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1443 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1444 . 1446 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1447 "Extensions to the Path Computation Element Communication 1448 Protocol (PCEP) for Point-to-Multipoint Traffic 1449 Engineering Label Switched Paths", RFC 8306, 1450 DOI 10.17487/RFC8306, November 2017, 1451 . 1453 14.2. Informative References 1455 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1456 Element (PCE)-Based Architecture", RFC 4655, 1457 DOI 10.17487/RFC4655, August 2006, 1458 . 1460 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1461 Path Computation Element (PCE) to Point-to-Multipoint 1462 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1463 DOI 10.17487/RFC5671, October 2009, 1464 . 1466 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1467 Stateful Path Computation Element (PCE)", RFC 8051, 1468 DOI 10.17487/RFC8051, January 2017, 1469 . 1471 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1472 Writing an IANA Considerations Section in RFCs", BCP 26, 1473 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1474 . 1476 [I-D.ietf-pce-pcep-yang] 1477 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1478 YANG Data Model for Path Computation Element 1479 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1480 yang-11 (work in progress), March 2019. 1482 Appendix A. Contributor Addresses 1484 Yuji Kamite 1485 NTT Communications Corporation 1486 Granpark Tower 1487 3-4-1 Shibaura, Minato-ku 1488 Tokyo 108-8118 1489 Japan 1491 EMail: y.kamite@ntt.com 1493 Authors' Addresses 1495 Udayasree Palle 1496 Huawei Technologies 1498 EMail: udayasreereddy@gmail.com 1500 Dhruv Dhody 1501 Huawei Technologies 1502 Divyashree Techno Park, Whitefield 1503 Bangalore, Karnataka 560066 1504 India 1506 EMail: dhruv.ietf@gmail.com 1508 Yosuke Tanaka 1509 NTT Communications Corporation 1510 Granpark Tower 1511 3-4-1 Shibaura, Minato-ku 1512 Tokyo 108-8118 1513 Japan 1515 EMail: yosuke.tanaka@ntt.com 1517 Vishnu Pavan Beeram 1518 Juniper Networks 1520 EMail: vbeeram@juniper.net