idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-10.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 11, 2019) is 1893 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 15, 2019 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 February 11, 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-10 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 15, 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 this is an added advantage, where the size of message is 181 much larger. 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): is a PCEP 267 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 STATEFUL-PCE- 280 CAPABILITY TLV in open message. 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 P2MP LSP parameters or operational status changes; if set 290 to 1 by a PCE, the N Flag indicates that the PCE is interested in 291 receiving LSP State Reports whenever LSP parameters or operational 292 status changes. The P2MP-CAPABILITY Flag must be advertised by 293 both a PCC and a PCE for PCRpt messages P2MP extension to be 294 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 PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 316 are either LSRs or servers also participating in the IGP, an 317 effective mechanism for PCE discovery within an IGP routing domain 318 consists of utilizing IGP advertisements. Extensions for the 319 advertisement of PCE Discovery Information are defined for OSPF and 320 for IS-IS in [RFC5088] and [RFC5089] respectively. 322 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 323 TLV used to advertise PCE capabilities. It MAY be present within the 324 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 325 provide the description and processing rules for this sub-TLV when 326 carried within OSPF and IS-IS, respectively. 328 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 329 reference: 331 Type: 5 333 Length: Multiple of 4. 335 Value: This contains an array of units of 32 bit flags with the most 336 significant bit as 0. Each bit represents one PCE capability. 338 PCE capability bit flags are defined in [RFC5088]. This document 339 defines new capability bits (early allocated by IANA) for the 340 stateful PCE with P2MP as follows: 342 Bit Capability 343 13 Active Stateful PCE with P2MP 344 14 Passive Stateful PCE with P2MP 345 15 PCE-Initiation with P2MP 347 Note that while active, passive or initiation stateful PCE with P2MP 348 capabilities may be advertised during discovery, PCEP Speakers that 349 wish to use stateful PCEP MUST advertise stateful PCEP capabilities 350 during PCEP session setup, as specified in the current document. A 351 PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP 352 session setup even if it did not receive any IGP PCE capability 353 advertisements. 355 5.4. State Synchronization 357 State Synchronization operations (described in Section 5.6 of 358 [RFC8231]) are applicable for the P2MP TE LSPs as well. The 359 optimizations described in [RFC8232] can also be applied for P2MP TE 360 LSPs. 362 5.5. LSP Delegation 364 LSP delegation operations (described in Section 5.7 of [RFC8231]) are 365 applicable for P2MP TE LSPs as well. 367 5.6. LSP Operations 369 5.6.1. Passive Stateful PCE 371 LSP operations for passive stateful PCE (described in Section 5.8.1 372 of [RFC8231]) are applicable for P2MP TE LSPs as well. 374 The PCReq and PCRep message format for P2MP TE LSPs is described in 375 Section 3.4 and Section 3.5 of [RFC8306] respectively. 377 The PCReq and PCRep message for P2MP TE LSPs are extended to support 378 encoding of LSP object, so that it is possible to refer to an LSP 379 with a unique identifier and simplify the PCEP message exchange. For 380 example, in case of modification of one leaf in a P2MP tree, there 381 should be no need to carry the full P2MP tree in PCReq message. 383 The extension for the Request and Response message for passive 384 stateful operations on P2MP TE LSPs are described in Section 6.3 and 385 Section 6.4. The extension for the Path Computation LSP State Report 386 (PCRpt) message is described in Section 6.1. 388 5.6.2. Active Stateful PCE 390 LSP operations for active stateful PCE (described in Section 5.8.2 of 391 [RFC8231]) are applicable for P2MP TE LSPs as well. 393 The extension for the Path Computation LSP Update (PCUpd) message for 394 active stateful operations on P2MP TE LSPs are described in 395 Section 6.2. 397 5.6.3. PCE-Initiated LSP 399 As per section 5.1 of [RFC8281], the PCE sends a Path Computation LSP 400 Initiate Request (PCInitiate) message to the PCC to suggest 401 instantiation or deletion of a P2P TE LSP. This document extends the 402 PCInitiate message to support P2MP TE LSPs (see details in 403 Section 6.5). 405 The P2MP TE LSPs suggested instantiation and deletion operations are 406 same as for P2P LSP as described in section 5.3 and 5.4 of [RFC8281]. 408 5.6.3.1. P2MP TE LSPs Instantiation 410 The Instantiation operation of P2MP TE LSPs is same as defined in 411 section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC- 412 PATH-NAME TLV etc. Rules of processing and error codes remains 413 unchanged. The N (P2MP) flag (Section 7.1) MUST be set in LSP object 414 in PCInitiate message by PCE to specify the instantiation is for P2MP 415 TE LSPs. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIERS 416 TLV SHOULD NOT be included in the LSP object in PCIntiitate message 417 (as it is generated by PCC and carried in PCRpt message instead) and 418 MUST be ignored on receipt. 420 5.6.3.2. P2MP TE LSPs Deletion 422 The deletion operation of P2MP TE LSPs is same as defined in section 423 5.4 of [RFC8281] by sending an LSP Initiate Message with an LSP 424 object carrying the PLSP-ID of the LSP to be removed and an SRP 425 object with the R flag set (LSP-REMOVE as per section 5.2 of 426 [RFC8281]). Rules of processing and error codes remains unchanged. 428 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 430 Adding of new leaves and Pruning of old Leaves for the PCE initiated 431 P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for 432 P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for 433 adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP 434 END-POINTS Object are used in PCUpd message. 436 PCC MAY use the Incremental State Update mechanism as described in 437 [RFC4875] to signal adding and pruning of leaves. 439 Section 3.10 of [RFC8306] defines the error-handling procedures when 440 adding new leaves to or removing old leaves from the existing P2MP 441 tree for PCReq message. The same error handling and error-codes are 442 also applicable to the stateful PCE messages as described in this 443 document. 445 5.6.3.4. P2MP TE LSPs Delegation and Cleanup 447 P2MP TE LSPs delegation and cleanup operations are same as defined in 448 section 6 of [RFC8281]. Rules of processing and error codes remains 449 unchanged. 451 6. PCEP Message Extensions 453 Message formats in this section, as those in [RFC8231], [RFC8281], 454 and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) 455 as specified in [RFC5511]. 457 6.1. The PCRpt Message 459 As per Section 6.1 of [RFC8231], PCRpt message is used to report the 460 current state of a P2P TE LSP. This document extends the PCRpt 461 message in reporting the status of P2MP TE LSPs. 463 The format of PCRpt message is as follows: 465 ::= 466 467 Where: 469 ::= 470 [] 472 ::= [] 473 474 475 [ 476 ] 477 [] 479 Where: 481 ::= 482 [] 483 [] 484 485 [] 487 ::= 488 [] 489 [] 490 491 [] 493 ::= (|) 494 [] 496 ::= (|) 497 [] 499 is defined in [RFC5440] and 500 extended by PCEP extensions. 501 consists of the actual computed and 502 signaled values of the and 503 objects defined in [RFC5440]. 505 The P2MP END-POINTS object defined in [RFC8306] is mandatory for 506 specifying address of P2MP leaves grouped based on leaf types. 508 o New leaves to add (leaf type = 1) 510 o Old leaves to remove (leaf type = 2) 511 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 513 o Old leaves whose path must be left unchanged (leaf type = 4) 515 When reporting the status of a P2MP TE LSP, the destinations MUST be 516 grouped in END-POINTS object based on the operational status (O field 517 in S2LS object) and leaf type (in END-POINTS). This way, leaves of 518 the same type that share the same operational status are grouped 519 together. For reporting the status of delegated P2MP TE LSPs leaf- 520 type = 3 is used, whereas for non-delegated P2MP TE LSPs, leaf-type = 521 4 is used. 523 For a delegated P2MP TE LSP configuration changes are reported via 524 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 525 type = 1) is used where as removing of old leaves (leaf-type = 2) is 526 used. 528 Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be 530 present in this message for P2MP LSP. 532 Note that the ordering of , 533 , , and 534 is done to retain compatibility with state 535 reports for the P2P LSPs as per [RFC8231]. 537 During state synchronization, the PCRpt message reports the status of 538 the full P2MP tree. 540 The S2LS object MUST be carried in PCRpt message along with END- 541 POINTS object when N (P2MP) flag is set in LSP object for P2MP TE 542 LSPs. If the S2LS object is missing, the receiving PCE MUST send a 543 PCErr message with Error-type=6 ("Mandatory Object missing") and 544 Error-value=13 (early allocated by IANA) ("S2LS object missing"). If 545 the END-POINTS object is missing, the receiving PCE MUST send a PCErr 546 message with Error-type=6 ("Mandatory Object missing") and Error- 547 value=3 ("END-POINTS object missing") (defined in [RFC5440]. 549 The S2LS object could be used in conjunction with the intended-path 550 (ERO) as well as the actual-path (RRO); for the same leaf, the state 551 encoded in the S2LS object associated with the actual-path MUST be 552 used over the intended-path. 554 If the E-bit (ERO-Compress bit) was set to 1 in the report, then the 555 path will be formed by an ERO followed by a list of SEROs or RRO 556 followed by a list of SRROs. 558 6.2. The PCUpd Message 560 As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P 561 TE LSP attributes. This document extends the PCUpd message in 562 updating the attributes of a P2MP TE LSP. 564 The format of a PCUpd message is as follows: 566 ::= 567 569 Where: 571 ::= 572 [] 574 ::= 575 576 577 579 Where: 581 ::= 582 [] 583 584 [] 586 ::= (|) 587 [] 589 is defined in [RFC5440] and 590 extended by PCEP extensions. 592 Note that the compatibility with the [RFC8231] definition of is preserved. 595 The PCC SHOULD use the make-before-break or sub-group-based 596 procedures described in [RFC4875] based on a local policy decision. 598 The END-POINTS object MUST be carried in PCUpd message when N flag is 599 set in LSP object for a P2MP TE LSP. If the END-POINTS object is 600 missing, the receiving PCC MUST send a PCErr message with Error- 601 type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS 602 object missing") (defined in [RFC5440]. 604 6.3. The PCReq Message 606 As per Section 3.4 of [RFC8306], PCReq message is used for a P2MP 607 Path Computation Request. This document extends the PCReq message 608 such that a PCC MAY include the LSP object in the PCReq message if 609 the stateful PCE P2MP capability has been negotiated on a PCEP 610 session between the PCC and a PCE. 612 The format of PCReq message is as follows: 614 ::= 615 [] 616 618 where: 620 ::= 621 [] 622 [] 623 [] 625 ::=[] 627 ::= 628 629 [] 630 [] 631 [] 632 [] 633 [] 634 [|] 635 [] 637 ::= 638 [[]] 639 [] 641 ::=(|)[] 642 ::=[] 644 6.4. The PCRep Message 646 As per Section 3.5 of [RFC8306], PCRep message is used for a P2MP 647 Path Computation Reply. This document extends the PCRep message such 648 that a PCE MAY include the LSP object in the PCRep message if the 649 stateful PCE P2MP capability has been negotiated on a PCEP session 650 between the PCC and a PCE. 652 The format of PCRep message is as follows: 654 ::= 655 657 where: 659 ::=[] 661 ::= 662 [] 663 [] 664 [] 665 [] 666 [] 668 ::= [] 669 670 [] 672 ::= (|) [] 674 ::=[] 675 [] 676 [] 677 [] 678 [] 680 6.5. The PCInitiate message 682 As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate 683 message to a PCC to recommend instantiation of a P2P TE LSP, this 684 document extends the format of PCInitiate message for the creation of 685 P2MP TE LSPs but the creation and deletion operations of P2MP TE LSPs 686 are same to the P2P TE LSPs. 688 The format of PCInitiate message is as follows: 690 ::= 691 692 Where: 694 ::= 695 [] 697 ::= 698 (|) 700 ::= 701 702 703 [] 705 ::= 706 708 Where: 710 ::= 711 [] 712 713 [] 715 ::= (|) 716 [] 718 is defined in [RFC5440] and extended 719 by PCEP extensions. 721 The PCInitiate message with an LSP object with N flag (P2MP) set is 722 used to convey operation on a P2MP TE LSP. The SRP object is used to 723 correlate between initiation requests sent by the PCE and the error 724 reports and state reports sent by the PCC as described in [RFC8231]. 726 The END-POINTS object MUST be carried in PCInitiate message when N 727 flag is set in LSP object for a P2MP TE LSP. If the END-POINTS 728 object is missing, the receiving PCC MUST send a PCErr message with 729 Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END- 730 POINTS object missing") (defined in [RFC5440]. 732 6.6. Example 733 6.6.1. P2MP TE LSPs Update Request 735 An LSP Update Request message is sent by an active stateful PCE to 736 update the P2MP TE LSPs parameters or attributes. An example of a 737 PCUpd message for P2MP TE LSPs is described below: 739 Common Header 740 SRP 741 LSP with P2MP flag set 742 END-POINTS for leaf type 3 743 ERO list 745 In this example, a stateful PCE requests an update of the path taken 746 to some of the leaves in a P2MP tree. The update request uses the 747 END-POINT type 3 (modified/reoptimized). The ERO list represents the 748 source to leaves path after modification. The update message does 749 not need to encode the full P2MP tree in this case. 751 6.6.2. P2MP TE LSP Report 753 The LSP State Report message is sent by a PCC to report or delegate 754 the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP 755 TE LSPs is described below to add new leaves to an existing P2MP TE 756 LSP: 758 Common Header 759 LSP with P2MP flag set 760 END-POINTS for leaf type 1 761 S2LS (O=DOWN) 762 ERO list (empty) 764 An example of a PCRpt message for a P2MP TE LSP is described below to 765 prune leaves from an existing P2MP TE LSP: 767 Common Header 768 LSP with P2MP flag set 769 END-POINTS for leaf type 2 770 S2LS (O=UP) 771 ERO list (empty) 773 An example of a PCRpt message for a delegated P2MP TE LSP is 774 described below to report status of leaves in an existing P2MP TE 775 LSP: 777 Common Header 778 SRP 779 LSP with P2MP flag set 780 END-POINTS for leaf type 3 781 S2LS (O=UP) 782 RRO list 783 END-POINTS for leaf type 3 784 S2LS (O=DOWN) 785 ERO list (empty) 787 In this example, the PCRpt message is in response to a PCUpd message 788 (with corresponding SRP) object indicating some leaves that are up 789 (with the actual path) and some are down. 791 An example of a PCRpt message for a non-delegated P2MP TE LSP is 792 described below to report status of leaves: 794 Common Header 795 LSP with P2MP flag set 796 END-POINTS for leaf type 4 797 S2LS (O=ACTIVE) 798 RRO list 799 END-POINTS for leaf type 4 800 S2LS (O=DOWN) 801 ERO list (empty) 803 6.6.3. P2MP TE LSPs Initiation Request 805 An LSP Initiation Request message is sent by an stateful PCE to 806 create a P2MP TE LSP. An example of a PCInitiate message for a P2MP 807 TE LSP is described below: 809 Common Header 810 SRP 811 LSP with P2MP flag set 812 END-POINTS for leaf type 1 813 ERO list 815 In this example, a stateful PCE request creation of a P2MP TE LSP. 816 The initiation request uses the END-POINT type 1 (new leaves). The 817 ERO list represents the source to leaves path. The initiate message 818 encodes the full P2MP tree in this case. 820 7. PCEP Object Extensions 822 The new PCEP TLVs defined in this document are in compliance with the 823 PCEP TLV format defined in [RFC5440]. 825 7.1. Extension of LSP Object 827 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 828 the PLSP-ID to uniquely identify an LSP that is constant for the life 829 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 830 identify a P2MP TE LSP uniquely. This document adds the following 831 flags to the LSP Object: 833 N (P2MP flag - 1 bit): If the N flag is set to 1, it indicates that 834 the message is for a P2MP TE LSP. 836 F (Fragmentation flag - 1 bit): If the F flag is unset (0), it 837 indicates that the LSP is not fragmented or it is the last piece 838 of the fragmented LSP. If the F flag is set to 1, it indicates 839 that the LSP is fragmented and this is not the last piece of the 840 fragmented LSP. The receiver needs to wait for additional 841 fragments until it receives an LSP with the same PLSP-ID and with 842 the F-bit set to 0. See Section 8 for further details. 844 E (ERO-compression flag - 1 bit): If the E flag is set to 1, it 845 indicates the route is in compressed format (that is, Secondary 846 Explicit Route Object (SERO) and Secondary Record Route Object 847 (SRRO) objects [RFC8306] are in use). 849 The flags defined in this section (N, F, E flags) are used in PCRpt, 850 PCUpd, or PCInitiate message. In case of PCReq and PCRep message, 851 these flags have no meaning and thus MUST be ignored. The 852 corresponding flags in the RP (Request Parameters) object are used as 853 described in [RFC8231]. 855 7.2. P2MP-LSP-IDENTIFIERS TLV 857 If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is 858 absent, the PCE MUST respond with a PCErr message carrying error-type 859 6 ("mandatory object missing") and error-value 14 (early allocated by 860 IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session. 862 The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the 863 PCUpd message for P2MP TE LSPs. The special value of all zeros for 864 this TLV is used to refer to all paths pertaining to a particular 865 PLSP-ID. 867 There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for 868 IPv6. 870 The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in the 871 Figure 6: 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Type=32 | Length=16 | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | IPv4 Tunnel Sender Address | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | LSP ID | Tunnel ID | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Extended Tunnel ID | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | P2MP ID | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 6: IPV4-P2MP-LSP-IDENTIFIERS TLV format 889 The type (16-bits) of the TLV is 32 (early allocated by IANA). The 890 length (16-bits) has a fixed value of 16 octets. The value contains 891 the following fields: 893 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 894 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 895 Sender Template Object. 897 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 898 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 899 Object. 901 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 902 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 904 Extended Tunnel ID: contains the 32-bits 'Extended Tunnel ID' 905 identifier defined in [RFC3209], Section 4.6.1.1 for the 906 LSP_TUNNEL_IPv4 Session Object. 908 P2MP ID: contains the 32-bits 'P2MP ID' identifier defined in 909 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 910 Object. 912 The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in the 913 Figure 7: 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Type=33 | Length=40 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | | 921 + + 922 | IPv6 tunnel sender address | 923 + (16 octets) + 924 | | 925 + + 926 | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | LSP ID | Tunnel ID | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | 931 + + 932 | Extended Tunnel ID | 933 + (16 octets) + 934 | | 935 + + 936 | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | P2MP ID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 7: IPV6-P2MP-LSP-IDENTIFIERS TLV format 943 The type (16-bits) of the TLV is 33 (early allocated by IANA). The 944 length (16-bits) has a fixed length of 40 octets. The value contains 945 the following fields: 947 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 948 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 949 Sender Template Object. 951 LSP ID: contains the 16-bits 'LSP ID' identifier defined in 952 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 953 Object. 955 Tunnel ID: contains the 16-bits 'Tunnel ID' identifier defined in 956 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 958 Extended Tunnel ID: contains the 128-bits 'Extended Tunnel ID' 959 identifier defined in [RFC3209], Section 4.6.1.2 for the 960 LSP_TUNNEL_IPv6 Session Object. 962 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 964 Tunnel ID remains constant over the life time of a tunnel. 966 7.3. S2LS Object 968 The S2LS (Source-to-Leaves) Object is used to report state of one or 969 more destinations (leaves) encoded within the END-POINTS object for a 970 P2MP TE LSP. It MUST be carried in PCRpt message along with END- 971 POINTS object when N flag is set in LSP object. 973 S2LS Object-Class is 41 (Early allocated by IANA). 975 S2LS Object-Types is 1. 977 The format of the S2LS object is shown in the following figure: 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Flags | O| 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 // Optional TLVs // 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Figure 8: S2LS object format 991 Flags(32-bits): the following flags are currently defined - 993 O(Operational - 3 bits) the O Field represents the operational 994 status of the group of destinations. The values are as per 995 Operational field in LSP object defined in Section 7.3 of 996 [RFC8231]. 998 Unassigned bits are reserved for future uses. They MUST be set to 0 999 on transmission and MUST be ignored on receipt. 1001 When N flag is set in LSP object then the O field in LSP object 1002 represents the operational status of the full P2MP TE LSP and the O 1003 field in S2LS object represents the operational status of a group of 1004 destinations encoded within the END-POINTS object. If there is a 1005 conflict between the O field in the LSP and the S2LS object (for 1006 example, O field in LSP corresponds to down whereas the O field in 1007 S2LS is up), the PCEP speaker MUST generate an error with error-type 1008 10 ("Reception of an invalid object") and error-value TBD1 (to be 1009 allocated by IANA) ("Mis-match of O field in S2LS and LSP object"). 1011 Future documents might define optional TLVs that could be included in 1012 the S2LS Object. 1014 8. Message Fragmentation 1016 The total PCEP message length, including the common header, is 1017 (2^16)-1 bytes. In certain scenarios the P2MP report and update 1018 request may not fit into a single PCEP message (e.g. initial report 1019 or update). The F flag is used in the LSP object to signal that the 1020 initial report, update, or initiate message was too large to fit into 1021 a single message and will be fragmented into multiple messages. In 1022 order to identify the single report or update each message will use 1023 the same PLSP-ID. In order to identify that a series of PCInitiate 1024 messages represents a single Initiate, each message will use the same 1025 PLSP-ID (in this case 0) and SRP-ID-number. 1027 Fragmentation procedure described below for report or update message 1028 is similar to [RFC8306] which describes request and response message 1029 fragmentation. 1031 8.1. Report Fragmentation Procedure 1033 If the initial report is too large to fit into a single report 1034 message, the PCC will split the report over multiple messages. Each 1035 message sent to the PCE, except the last one, will have the F flag 1036 set in the LSP object to signify that the report has been fragmented 1037 into multiple messages. In order to identify that a series of report 1038 messages represents a single report, each message will use the same 1039 PLSP-ID. 1041 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1042 report any error associated with the fragmentation of a P2MP PCEP 1043 message. A new error-value 2 (early allocated by IANA) indicates 1044 "Fragmented report failure" and is used if a PCE does not receive the 1045 last part of the fragmented message. 1047 8.2. Update Fragmentation Procedure 1049 Once the PCE computes and updates a path for some or all leaves in a 1050 P2MP TE LSP, an update message is sent to the PCC. If the update is 1051 too large to fit into a single update message, the PCE will split the 1052 update over multiple messages. Each update message sent by the PCE, 1053 except the last one, will have the F flag set in the LSP object to 1054 signify that the update has been fragmented into multiple messages. 1055 In order to identify that a series of update messages represents a 1056 single update, each message will use the same PLSP-ID and SRP-ID- 1057 number. 1059 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1060 report any error associated with the fragmentation of a P2MP PCEP 1061 message. A new error-value 3 (early allocated by IANA) indicates 1062 "Fragmented update failure" and is used if a PCC does not receive the 1063 last part of the fragmented message. 1065 8.3. PCIntiate Fragmentation Procedure 1067 Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message 1068 is sent to the PCC. If the PCInitiate is too large to fit into a 1069 single PCInitiate message, the PCE will split the PCInitiate over 1070 multiple messages. Each PCInitiate message sent by the PCE, except 1071 the last one, will have the F flag set in the LSP object to signify 1072 that the PCInitiate has been fragmented into multiple messages. In 1073 order to identify that a series of PCInitiate messages represents a 1074 single Initiate, each message will use the same PLSP-ID (in this case 1075 0) and SRP-ID-number. 1077 The Error-Type value 18 ("P2MP Fragmentation Error") is used to 1078 report any error associated with the fragmentation of a P2MP PCEP 1079 message. A new error-value 4 (early allocated by IANA) indicates 1080 "Fragmented instantiation failure" and is used if a PCC does not 1081 receive the last part of the fragmented message. 1083 9. Non-Support of P2MP TE LSPs for Stateful PCE 1085 The PCEP extensions described in this document for stateful PCEs with 1086 P2MP capability MUST NOT be used if PCE has not advertised its 1087 stateful capability with P2MP as per Section 5.2. If the PCEP 1088 Speaker on the PCC supports the extensions of this draft (understands 1089 the P2MP flag in the LSP object) but did not advertise this 1090 capability, then upon receipt of PCUpd message from the PCE, it 1091 SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), 1092 error-value 12 (early allocated by IANA) ("Attempted LSP Update 1093 Request for P2MP if active stateful PCE capability for P2MP was not 1094 advertised") and terminate the PCEP session. If the PCEP Speaker on 1095 the PCE supports the extensions of this draft (understands the P2MP 1096 flag in the LSP object) but did not advertise this capability, then 1097 upon receipt of a PCRpt message from the PCC, it SHOULD generate a 1098 PCErr with error-type 19 ("Invalid Operation"), error-value 11 (early 1099 allocated by IANA) ("Attempted LSP State Report for P2MP if stateful 1100 PCE capability for P2MP was not advertised") and it SHOULD terminate 1101 the PCEP session. 1103 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1104 does not understand the P2MP flag in the LSP object, and therefore 1105 the PCEP extensions described in this document, then the Stateful PCE 1106 would act as per [RFC8231]. 1108 The PCEP extensions described in this document for PCC or PCE with 1109 instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or 1110 PCE has not advertised its stateful capability with Instantiation and 1111 P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC 1112 supports the extensions of this draft (understands the P (P2MP-LSP- 1113 INSTANTIATION-CAPABILITY) flag) but did not advertise this 1114 capability, then upon receipt of PCInitiate message from the PCE, it 1115 SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), 1116 error-value 13 (early allocated by IANA) ("Attempted LSP 1117 Instantiation Request for P2MP if stateful PCE instantiation 1118 capability for P2MP was not advertised") and terminate the PCEP 1119 session.. 1121 10. Manageability Considerations 1123 All manageability requirements and considerations listed in 1124 [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP 1125 extensions defined in this document. In addition, requirements and 1126 considerations listed in this section apply. 1128 10.1. Control of Function and Policy 1130 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1131 capability, the LSP Update capability, and the LSP Initiation 1132 capability for P2MP LSPs. 1134 10.2. Information and Data Models 1136 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1137 include advertised P2MP stateful capabilities, P2MP synchronization 1138 status, and delegation status of P2MP LSP etc. The statistics module 1139 should also count P2MP LSP related data. 1141 10.3. Liveness Detection and Monitoring 1143 Mechanisms defined in this document do not imply any new liveness 1144 detection and monitoring requirements in addition to those already 1145 listed in [RFC5440]. 1147 10.4. Verify Correct Operations 1149 Mechanisms defined in this document do not imply any new operation 1150 verification requirements in addition to those already listed in 1151 [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. 1153 10.5. Requirements On Other Protocols 1155 Mechanisms defined in this document do not imply any new requirements 1156 on other protocols. 1158 10.6. Impact On Network Operations 1160 Mechanisms defined in this document do not have any impact on network 1161 operations in addition to those already listed in [RFC5440], 1162 [RFC8306], [RFC8231], and [RFC8281]. 1164 Stateful PCE feature for P2MP LSP would help with network operations. 1166 11. IANA Considerations 1168 This document requests IANA to confirm the early allocation of the 1169 code-points for the protocol elements defined in this document. 1171 11.1. PCE Capabilities in IGP Advertisements 1173 IANA is requested to confirm the early allocation for the new bits in 1174 the OSPF Parameters "PCE Capability Flags" registry, as follows: 1176 Bit Meaning Reference 1177 13 Active Stateful [This.I-D] 1178 PCE with P2MP 1179 14 Passive Stateful [This.I-D] 1180 PCE with P2MP 1181 15 Stateful PCE [This.I-D] 1182 Initiation with P2MP 1184 11.2. STATEFUL-PCE-CAPABILITY TLV 1186 The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and a 1187 registry was created to manage the flags in the TLV. IANA is 1188 requested to confirm the early allocation of the following code- 1189 points in the aforementioned registry. 1191 Bit Description Reference 1193 25 P2MP-CAPABILITY [This.I-D] 1194 24 P2MP-LSP-UPDATE- [This.I-D] 1195 CAPABILITY 1196 23 P2MP-LSP- [This.I-D] 1197 INSTANTIATION- 1198 CAPABILITY 1200 11.3. LSP Object 1202 The LSP object is defined in [RFC8231] and a registry was created to 1203 manage the Flags field of the LSP object. 1205 IANA is requested to confirm the early allocation of the following 1206 code-points in the aforementioned registry. 1208 Bit Description Reference 1210 3 P2MP [This.I-D] 1211 2 Fragmentation [This.I-D] 1213 Additionally, IANA is requested to allocate an additional code-point 1214 in this registry. 1216 Bit Description Reference 1218 TBD ERO-compression [This.I-D] 1220 11.4. PCEP-Error Object 1222 IANA is requested to confirm the early allocation of the new error 1223 values within the "PCEP-ERROR Object Error Types and Values" sub- 1224 registry of the PCEP Numbers registry, as follows: 1226 Error-Type Meaning 1227 6 Mandatory Object missing [RFC5440] 1228 Error-value=13: S2LS object missing 1229 Error-value=14: P2MP-LSP-IDENTIFIERS TLV missing 1230 18 P2MP Fragmentation Error [RFC8306] 1231 Error-value= 2. Fragmented Report 1232 failure 1233 Error-value= 3. Fragmented Update 1234 failure 1235 Error-value= 4. Fragmented Instantiation 1236 failure 1237 19 Invalid Operation [RFC8231] 1238 Error-value= 11. Attempted LSP State Report 1239 for P2MP if stateful PCE capability 1240 for P2MP was not advertised 1241 Error-value= 12. Attempted LSP Update Request 1242 for P2MP if active stateful PCE capability 1243 for P2MP was not advertised 1244 Error-value= 13. Attempted LSP Instantiation 1245 Request for P2MP if stateful PCE 1246 instantiation capability for P2MP was not 1247 advertised 1249 Reference for all new Error-Value above is [This.I-D]. 1251 Additionally, IANA is requested to allocate an additional code-point 1252 in this registry. 1254 Error-Type Meaning 1255 10 Reception of an invalid object [RFC5440] 1256 Error-value=TBD1: Mis-match of O field in S2LS 1257 and LSP object 1259 Reference for all new Error-Value above is [This.I-D]. 1261 11.5. PCEP TLV Type Indicators 1263 IANA is requested to confirm the early allocation of the following 1264 code-points in the existing "PCEP TLV Type Indicators" registry as 1265 follows: 1267 Value Meaning Reference 1268 32 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D] 1269 33 P2MP-IPV6-LSP-IDENTIFIERS [This.I-D] 1271 11.6. PCEP object 1273 IANA is requested to confirm the early allocation for the new object- 1274 class values and object types within the "PCEP Objects" sub-registry 1275 of the PCEP Numbers registry, as follows. 1277 Object-Class Value Name Reference 1279 41 S2LS [This.I-D] 1280 Object-Type 1281 0: Reserved 1282 1: S2LS 1284 11.7. S2LS object 1286 This document requests that a new sub-registry, named "S2LS Object 1287 Flag Field", is created within the "Path Computation Element Protocol 1288 (PCEP) Numbers" registry to manage the 32-bits Flag field of the S2LS 1289 object. New values are to be assigned by Standards Action [RFC8126]. 1290 Each bit should be tracked with the following qualities: 1292 o Bit number (counting from bit 0 as the most significant bit) 1294 o Capability description 1296 o Defining RFC 1298 The following values are defined in this document: 1300 Bit Description Reference 1302 29-31 Operational (3-bits) [This.I-D] 1303 0-28 Unassigned 1305 12. Security Considerations 1307 The stateful operations on P2MP TE LSPs are more CPU-intensive and 1308 also utilize more bandwidth on wire (in comparison to P2P TE LSPs). 1309 If a rogue PCC were able to request unauthorized stateful PCE 1310 operations then it may be able to mount a DoS attack against a PCE, 1311 which would disrupt the network and deny service to other PCCs. 1312 Consequently, it is important that implementations conform to the 1313 relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], 1314 and [RFC8281]. Securing the PCEP session using Transport Layer 1315 Security (TLS) [RFC8253], as per the recommendations and best current 1316 practices in [RFC7525], is RECOMMENDED. 1318 13. Acknowledgments 1320 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for the review 1321 comments. 1323 Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as 1324 document shepherds. 1326 14. References 1328 14.1. Normative References 1330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1331 Requirement Levels", BCP 14, RFC 2119, 1332 DOI 10.17487/RFC2119, March 1997, 1333 . 1335 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1336 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1337 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1338 . 1340 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1341 Zhang, "OSPF Protocol Extensions for Path Computation 1342 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1343 January 2008, . 1345 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1346 Zhang, "IS-IS Protocol Extensions for Path Computation 1347 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1348 January 2008, . 1350 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1351 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1352 DOI 10.17487/RFC5440, March 2009, 1353 . 1355 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1356 Used to Form Encoding Rules in Various Routing Protocol 1357 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1358 2009, . 1360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1362 May 2017, . 1364 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1365 Computation Element Communication Protocol (PCEP) 1366 Extensions for Stateful PCE", RFC 8231, 1367 DOI 10.17487/RFC8231, September 2017, 1368 . 1370 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1371 and D. Dhody, "Optimizations of Label Switched Path State 1372 Synchronization Procedures for a Stateful PCE", RFC 8232, 1373 DOI 10.17487/RFC8232, September 2017, 1374 . 1376 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1377 Computation Element Communication Protocol (PCEP) 1378 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1379 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1380 . 1382 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1383 "Extensions to the Path Computation Element Communication 1384 Protocol (PCEP) for Point-to-Multipoint Traffic 1385 Engineering Label Switched Paths", RFC 8306, 1386 DOI 10.17487/RFC8306, November 2017, 1387 . 1389 14.2. Informative References 1391 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1392 Element (PCE)-Based Architecture", RFC 4655, 1393 DOI 10.17487/RFC4655, August 2006, 1394 . 1396 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1397 Yasukawa, Ed., "Extensions to Resource Reservation 1398 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1399 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1400 DOI 10.17487/RFC4875, May 2007, 1401 . 1403 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1404 Path Computation Element (PCE) to Point-to-Multipoint 1405 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1406 DOI 10.17487/RFC5671, October 2009, 1407 . 1409 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1410 "Recommendations for Secure Use of Transport Layer 1411 Security (TLS) and Datagram Transport Layer Security 1412 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1413 2015, . 1415 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1416 Stateful Path Computation Element (PCE)", RFC 8051, 1417 DOI 10.17487/RFC8051, January 2017, 1418 . 1420 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1421 Writing an IANA Considerations Section in RFCs", BCP 26, 1422 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1423 . 1425 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1426 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1427 Path Computation Element Communication Protocol (PCEP)", 1428 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1429 . 1431 [I-D.ietf-pce-pcep-yang] 1432 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1433 YANG Data Model for Path Computation Element 1434 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1435 yang-09 (work in progress), October 2018. 1437 Appendix A. Contributor Addresses 1439 Yuji Kamite 1440 NTT Communications Corporation 1441 Granpark Tower 1442 3-4-1 Shibaura, Minato-ku 1443 Tokyo 108-8118 1444 Japan 1446 EMail: y.kamite@ntt.com 1448 Authors' Addresses 1450 Udayasree Palle 1451 Huawei Technologies 1452 Divyashree Techno Park, Whitefield 1453 Bangalore, Karnataka 560066 1454 India 1456 EMail: udayasreereddy@gmail.com 1458 Dhruv Dhody 1459 Huawei Technologies 1460 Divyashree Techno Park, Whitefield 1461 Bangalore, Karnataka 560066 1462 India 1464 EMail: dhruv.ietf@gmail.com 1466 Yosuke Tanaka 1467 NTT Communications Corporation 1468 Granpark Tower 1469 3-4-1 Shibaura, Minato-ku 1470 Tokyo 108-8118 1471 Japan 1473 EMail: yosuke.tanaka@ntt.com 1475 Vishnu Pavan Beeram 1476 Juniper Networks 1478 EMail: vbeeram@juniper.net