idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-05.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 (October 30, 2017) is 2363 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) == Missing Reference: 'This I-D' is mentioned on line 1188, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 3, 2018 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 October 30, 2017 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-05 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 LSPs. This document provides extensions 20 required for Path Computation Element communication Protocol (PCEP) 21 so as to enable the usage of a stateful PCE capability in supporting 22 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 May 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 LSP 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 LSP Instantiation . . . . . . . . . . . . 9 77 5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9 78 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10 79 5.6.3.4. P2MP TE LSP Delegation and Cleanup . . . . . . . 10 80 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10 81 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 10 82 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 12 83 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 13 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 LSP Update Request . . . . . . . . . . . . . 17 88 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 89 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 18 90 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 18 91 7.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 19 92 7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 21 93 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 22 94 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 22 95 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23 96 8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 23 98 9. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 23 99 10. Manageability Considerations . . . . . . . . . . . . . . . . 24 100 10.1. Control of Function and Policy . . . . . . . . . . . . . 24 101 10.2. Information and Data Models . . . . . . . . . . . . . . 24 102 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 103 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 25 104 10.5. Requirements On Other Protocols . . . . . . . . . . . . 25 105 10.6. Impact On Network Operations . . . . . . . . . . . . . . 25 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 107 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 25 108 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26 109 11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 26 110 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 111 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 112 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 27 113 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 28 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 115 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 118 14.2. Informative References . . . . . . . . . . . . . . . . . 30 119 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 [RFC4857] 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 [I-D.ietf-pce-rfc6006bis]. 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 needed for stateful PCE to support general 145 functionality for P2P TE LSP. [I-D.ietf-pce-pce-initiated-lsp] 146 provides the an extensions needed for stateful PCE-initiated P2P TE 147 LSP. Complementarily, this document focuses on the extensions that 148 are 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], [I-D.ietf-pce-pce-initiated-lsp], and 164 [I-D.ietf-pce-rfc6006bis]. 166 3. Supporting P2MP TE LSP for Stateful PCE 168 3.1. Motivation 170 [RFC8051] presents several use cases, demonstrating scenarios that 171 benefit from the deployment of a stateful PCE including optimization, 172 recovery, etc which are equally applicable to P2MP TE LSPs. 173 [RFC8231] defines the extensions to PCEP for P2P TE LSPs. 174 Complementarily, this document focuses on the extensions that are 175 necessary in order for the deployment of stateful PCEs to support 176 P2MP TE LSPs. 178 In addition to that, the stateful nature of a PCE simplifies the 179 information conveyed in PCEP messages since it is possible to refer 180 to the LSPs via PLSP-ID ([RFC8231]). For P2MP this is an added 181 advantage, where the size of message is much larger. In case of 182 stateless PCE, a modification of P2MP tree requires encoding of all 183 leaves along with the paths in PCReq message, but using a stateful 184 PCE with P2MP capability, the PCEP message can be used to convey only 185 the modifications (the other information can be retrieved from the 186 P2MP LSP identifier in the LSP database (LSPDB)). 188 In environments where the P2MP TE LSP placement needs to change in 189 response to application demands, it is useful to support dynamic 190 creation and tear down of P2MP TE LSPs. The ability for a PCE to 191 trigger the creation of P2MP TE LSPs on demand can be seamlessly 192 integrated into a controller-based network architecture, where 193 intelligence in the controller can determine when and where to set up 194 paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further 195 describes the motivation behind the PCE-Initiation capability, which 196 are equally applicable for P2MP TE LSPs. 198 3.2. Objectives 200 The objectives for the protocol extensions to support P2MP TE LSP for 201 stateful PCE are same as the objectives described in section 3.2 of 202 [RFC8231]. 204 4. Functions to Support P2MP TE LSPs for Stateful PCEs 206 [RFC8231] specifies new functions to support a stateful PCE. It also 207 specifies that a function can be initiated either from a PCC towards 208 a PCE (C-E) or from a PCE towards a PCC (E-C). 210 This document extends these functions to support P2MP TE LSPs. 212 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 213 announce during PCEP session establishment that they support PCEP 214 Stateful PCE extensions for P2MP using mechanisms defined in 215 Section 5.2. 217 LSP State Synchronization (C-E): after the session between the PCC 218 and a stateful PCE with P2MP capability is initialized, the PCE 219 must learn the state of a PCC's P2MP TE LSPs before it can perform 220 path computations or update LSP attributes in a PCC. 222 LSP Update Request (E-C): a stateful PCE with P2MP capability 223 requests modification of attributes on a PCC's P2MP TE LSP. 225 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 226 whenever the state of a P2MP TE LSP changes. 228 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 229 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 230 the authoritative source of the LSP's attributes as long as the 231 delegation is in effect (See Section 5.7 of [RFC8231]); the PCC 232 may withdraw the delegation or the PCE may give up the delegation 233 at any time. 235 PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate 236 Message to a PCC to instantiate or delete a P2MP TE LSP. 238 5. Architectural Overview of Protocol Extensions 240 5.1. Extension of PCEP Messages 242 New PCEP messages are defined in [RFC8231] to support stateful PCE 243 for P2P TE LSPs. In this document these messages are extended to 244 support P2MP TE LSPs. 246 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 247 in a PCRpt message can contain actual P2MP TE LSP path attributes, 248 LSP status, etc. An LSP State Report carried on a PCRpt message 249 is also used in delegation or revocation of control of a P2MP TE 250 LSP to/from a PCE. The extension of PCRpt message is described in 251 Section 6.1. 253 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 254 Request in a PCUpd message MUST contain all LSP parameters that a 255 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 256 carried on a PCUpd message is also used to return LSP delegations 257 if at any point PCE no longer desires control of a P2MP TE LSP. 258 The PCUpd message is described in Section 6.2. 260 A new PCEP message is defined in [I-D.ietf-pce-pce-initiated-lsp] to 261 support stateful PCE instantiation of P2P TE LSPs. In this document 262 this message is extended to support P2MP TE LSPs. 264 Path Computation LSP Initiate Message (PCInitiate): is a PCEP 265 message sent by a PCE to a PCC to trigger P2MP TE LSP 266 instantiation or deletion. The PCInitiate message is described in 267 Section 6.5. 269 The path computation request (PCReq) and path computation reply 270 (PCRep) messages are also extended to support stateful PCE for P2P TE 271 LSP in [RFC8231]. In this document these messages are extended to 272 support P2MP TE LSPs as well. 274 5.2. Capability Advertisement 276 During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231], 277 PCEP speakers advertises Stateful capability via Stateful PCE 278 Capability TLV in open message. Two new flags are defined for the 279 STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in 280 [I-D.ietf-pce-pce-initiated-lsp] and [RFC8232]. 282 Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), 283 and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: 285 N (P2MP-CAPABILITY bit - TBD4): if set to 1 by a PCC, the N Flag 286 indicates that the PCC is willing to send P2MP LSP State Reports 287 whenever P2MP LSP parameters or operational status changes.; if 288 set to 1 by a PCE, the N Flag indicates that the PCE is interested 289 in receiving LSP State Reports whenever LSP parameters or 290 operational status changes. The P2MP-CAPABILITY Flag must be 291 advertised by both a PCC and a PCE for PCRpt messages P2MP 292 extension to be allowed on a PCEP session. 294 M (P2MP-LSP-UPDATE-CAPABILITY bit - TBD5): if set to 1 by a PCC, the 295 M Flag indicates that the PCC allows modification of P2MP LSP 296 parameters; if set to 1 by a PCE, the M Flag indicates that the 297 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 298 UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE 299 for PCUpd messages P2MP extension to be allowed on a PCEP session. 301 P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a 302 PCC, the P Flag indicates that the PCC allows instantiation of an 303 P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates 304 that the PCE supports P2MP LSP instantiation. The P2MP-LSP- 305 INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in 306 order to support PCE-initiated P2MP LSP instantiation. 308 A PCEP speaker should continue to advertise the basic P2MP capability 309 via mechanisms as described in [I-D.ietf-pce-rfc6006bis]. 311 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 313 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 314 are either LSRs or servers also participating in the IGP, an 315 effective mechanism for PCE discovery within an IGP routing domain 316 consists of utilizing IGP advertisements. Extensions for the 317 advertisement of PCE Discovery Information are defined for OSPF and 318 for IS-IS in [RFC5088] and [RFC5089] respectively. 320 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 321 TLV used to advertise PCE capabilities. It MAY be present within the 322 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 323 provide the description and processing rules for this sub-TLV when 324 carried within OSPF and IS-IS, respectively. 326 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 327 reference: 329 Type: 5 331 Length: Multiple of 4. 333 Value: This contains an array of units of 32 bit flags with the most 334 significant bit as 0. Each bit represents one PCE capability. 336 PCE capability bits are defined in [RFC5088]. This document defines 337 new capability bits for the stateful PCE with P2MP as follows: 339 Bit Capability 340 TBD1 Active Stateful PCE with P2MP 341 TBD2 Passive Stateful PCE with P2MP 342 TBD3 PCE-Initiation with P2MP 344 Note that while active, passive or initiation stateful PCE with P2MP 345 capabilities may be advertised during discovery, PCEP Speakers that 346 wish to use stateful PCEP MUST advertise stateful PCEP capabilities 347 during PCEP session setup, as specified in the current document. A 348 PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP 349 session setup even if it did not receive any IGP PCE capability 350 advertisements. 352 5.4. State Synchronization 354 State Synchronization operations described in Section 5.6 of 355 [RFC8231] are applicable for P2MP TE LSPs as well. The optimizations 356 described in [RFC8232] can also be applied for P2MP. 358 5.5. LSP Delegation 360 LSP delegation operations described in Section 5.7 of [RFC8231] are 361 applicable for P2MP TE LSPs as well. 363 5.6. LSP Operations 365 5.6.1. Passive Stateful PCE 367 LSP operations for passive stateful PCE described in Section 5.8.1 of 368 [RFC8231] are applicable for P2MP TE LSPs as well. 370 The Path Computation Request and Response message format for P2MP TE 371 LSPs is described in Section 3.4 and Section 3.5 of 372 [I-D.ietf-pce-rfc6006bis] respectively. 374 The Request and Response message for P2MP TE LSPs are extended to 375 support encoding of LSP object, so that it is possible to refer to a 376 LSP with a unique identifier and simplify the PCEP message exchange. 377 For example, in case of modification of one leaf in a P2MP tree, 378 there should be no need to carry the full P2MP tree in PCReq message. 380 The extension for the Request and Response message for passive 381 stateful operations on P2MP TE LSPs are described in Section 6.3 and 382 Section 6.4. The extension for the Path Computation LSP State Report 383 (PCRpt) message is described in Section 6.1. 385 5.6.2. Active Stateful PCE 387 LSP operations for active stateful PCE described in Section 5.8.2 of 388 [RFC8231] are applicable for P2MP TE LSPs as well. 390 The extension for the Path Computation LSP Update (PCUpd) message for 391 active stateful operations on P2MP TE LSPs are described in 392 Section 6.2. 394 5.6.3. PCE-Initiated LSP 396 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 397 a Path Computation LSP Initiate Request (PCInitiate) message to the 398 PCC to suggest instantiation or deletion of a P2P TE LSP. This 399 document extends the PCInitiate message to support P2MP TE LSP (see 400 details in Section 6.5). 402 P2MP TE LSP suggested instantiation and deletion operations are same 403 as P2P LSP as described in section 5.3 and 5.4 of 404 [I-D.ietf-pce-pce-initiated-lsp]. 406 5.6.3.1. P2MP TE LSP Instantiation 408 The Instantiation operation of P2MP TE LSP is same as defined in 409 section 5.3 of [I-D.ietf-pce-pce-initiated-lsp] including handling of 410 PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error 411 codes remains unchanged. The N bit MUST be set in LSP object in 412 PCInitiate message by PCE to specify the instantiation is for P2MP TE 413 LSP. 415 Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV MUST 416 NOT be included in the LSP object in PCIntiitate message as it SHOULD 417 be generated by PCC and carried in PCRpt message. 419 5.6.3.2. P2MP TE LSP Deletion 421 The deletion operation of P2MP TE LSP is same as defined in section 422 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 423 Message with an LSP object carrying the PLSP-ID of the LSP to be 424 removed and an SRP object with the R flag set (LSP-REMOVE as per 425 section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of 426 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 [I-D.ietf-pce-rfc6006bis], 433 leaf type = 1 for adding of new leaves, leaf type = 2 for pruning of 434 old leaves of P2MP 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 5.6.3.4. P2MP TE LSP Delegation and Cleanup 441 P2MP TE LSP delegation and cleanup operations are same as defined in 442 section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing 443 and error codes remains unchanged. 445 6. PCEP Message Extensions 447 6.1. The PCRpt Message 449 As per Section 6.1 of [RFC8231], PCRpt message is used to report the 450 current state of a P2P TE LSP. This document extends the PCRpt 451 message in reporting the status of P2MP TE LSP. 453 The format of PCRpt message is as follows: 455 ::= 456 457 Where: 459 ::= 460 [] 462 ::= [] 463 464 465 [ 466 ] 467 469 Where: 471 ::= 472 [] 473 [] 474 475 [] 477 ::= 478 [] 479 480 [] 482 ::= (|) 483 [] 485 ::= (|) 486 [] 488 is defined in [RFC5440] and 489 extended by PCEP extensions. 490 consists of the actual computed and 491 signaled values of the and 492 objects defined in [RFC5440]. 494 The P2MP END-POINTS object defined in [I-D.ietf-pce-rfc6006bis] is 495 mandatory for specifying address of P2MP leaves grouped based on leaf 496 types. 498 o New leaves to add (leaf type = 1) 500 o Old leaves to remove (leaf type = 2) 501 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 503 o Old leaves whose path must be left unchanged (leaf type = 4) 505 When reporting the status of a P2MP TE LSP, the destinations are 506 grouped in END-POINTS object based on the operational status (O field 507 in S2LS object) and leaf type (in END-POINTS). This way the leaves 508 that share the same operational status are grouped together. For 509 reporting the status of delegated P2MP TE LSP, leaf-type = 3, where 510 as for non-delegated P2MP TE LSP, leaf-type = 4 is used. 512 For delegated P2MP TE LSP configuration changes are reported via 513 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 514 type = 1) is used where as removing of old leaves (leaf-type = 2) is 515 used. 517 Note that we preserve compatibility with the [RFC8231] definition of 518 . At least one instance of MUST be 519 present in this message for P2MP LSP. 521 During state synchronization, the PCRpt message must report the 522 status of the full P2MP TE LSP. 524 The S2LS object MUST be carried in PCRpt message along with END- 525 POINTS object when N bit is set in LSP object for P2MP TE LSP. If 526 the S2LS object is missing, the receiving PCE MUST send a PCErr 527 message with Error-type=6 (Mandatory Object missing) and Error- 528 value=TBD11 (S2LS object missing). If the END-POINTS object is 529 missing, the receiving PCE MUST send a PCErr message with Error- 530 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 531 object missing) (defined in [RFC5440]. 533 6.2. The PCUpd Message 535 As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P 536 TE LSP attributes. This document extends the PCUpd message in 537 updating the attributes of P2MP TE LSP. 539 The format of a PCUpd message is as follows: 541 ::= 542 544 Where: 546 ::= 547 [] 549 ::= 550 551 552 554 Where: 556 ::= 557 [] 558 559 [] 561 ::= (|) 562 [] 564 is defined in [RFC5440] and 565 extended by PCEP extensions. 567 Note that we preserve compatibility with the [RFC8231] definition of 568 . 570 The PCC MAY use the make-before-break or sub-group-based procedures 571 described in [RFC4875] based on a local policy decision. 573 The END-POINTS object MUST be carried in PCUpd message when N bit is 574 set in LSP object for P2MP TE LSP. If the END-POINTS object is 575 missing, the receiving PCC MUST send a PCErr message with Error- 576 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 577 object missing) (defined in [RFC5440]. 579 6.3. The PCReq Message 581 As per Section 3.4 of [I-D.ietf-pce-rfc6006bis], PCReq message is 582 used for a P2MP path computation request. This document extends the 583 PCReq message such that a PCC MAY include the LSP object in the PCReq 584 message if the stateful PCE P2MP capability has been negotiated on a 585 PCEP session between the PCC and a PCE. 587 The format of PCReq message is as follows: 589 ::= 590 [] 591 593 where: 595 ::= 596 [] 597 [] 598 [] 600 ::=[] 602 ::= 603 604 [] 605 [] 606 [] 607 [] 608 [] 609 [|] 610 [] 612 ::= 613 [[]] 614 [] 616 ::=(|)[] 617 ::=[] 619 6.4. The PCRep Message 621 As per Section 3.5 of [I-D.ietf-pce-rfc6006bis], PCRep message is 622 used for a P2MP path computation reply. This document extends the 623 PCRep message such that a PCE MAY include the LSP object in the PCRep 624 message if the stateful PCE P2MP capability has been negotiated on a 625 PCEP session between the PCC and a PCE. 627 The format of PCRep message is as follows: 629 ::= 630 632 where: 634 ::=[] 636 ::= 637 [] 638 [] 639 [] 640 [] 641 [] 643 ::= [] 644 645 [] 647 ::= (|) [] 649 ::=[] 650 [] 651 [] 652 [] 653 [] 655 6.5. The PCInitiate message 657 As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE 658 sends a PCInitiate message to a PCC to recommend instantiation of a 659 P2P TE LSP, this document extends the format of PCInitiate message 660 for the creation of P2MP TE LSPs but the creation and deletion 661 operations of P2MP TE LSP are same to the P2P TE LSP. 663 The format of PCInitiate message is as follows: 665 ::= 666 667 Where: 669 ::= 670 [] 672 ::= 673 (|) 675 ::= 676 677 678 [] 680 ::= 681 683 Where: 685 ::= 686 [] 687 688 [] 690 ::= (|) 691 [] 693 is defined in [RFC5440] and extended 694 by PCEP extensions. 696 The PCInitiate message with an LSP object with N bit (P2MP) set is 697 used to convey operation on a P2MP TE LSP. The SRP object is used to 698 correlate between initiation requests sent by the PCE and the error 699 reports and state reports sent by the PCC as described in [RFC8231]. 701 The END-POINTS object MUST be carried in PCInitiate message when N 702 bit is set in LSP object for P2MP TE LSP. If the END-POINTS object 703 is missing, the receiving PCC MUST send a PCErr message with Error- 704 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 705 object missing) (defined in [RFC5440]. 707 6.6. Example 708 6.6.1. P2MP TE LSP Update Request 710 LSP Update Request message is sent by an active stateful PCE to 711 update the P2MP TE LSP parameters or attributes. An example of a 712 PCUpd message for P2MP TE LSP is described below: 714 Common Header 715 SRP 716 LSP with P2MP flag set 717 END-POINTS for leaf type 3 718 ERO list 720 In this example, a stateful PCE request updation of path taken by 721 some of the leaves in a P2MP tree. The update request uses the END- 722 POINT type 3 (modified/reoptimized). The ERO list represents the 723 S2LS path after modification. The update message does not need to 724 encode the full P2MP tree in this case. 726 6.6.2. P2MP TE LSP Report 728 LSP State Report message is sent by a PCC to report or delegate the 729 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 730 LSP is described below to add new leaves to an existing P2MP TE LSP: 732 Common Header 733 LSP with P2MP flag set 734 END-POINTS for leaf type 1 735 S2LS (O=DOWN) 736 ERO list (empty) 738 An example of a PCRpt message for P2MP TE LSP is described below to 739 prune leaves from an existing P2MP TE LSP: 741 Common Header 742 LSP with P2MP flag set 743 END-POINTS for leaf type 2 744 S2LS (O=UP) 745 ERO list 747 An example of a PCRpt message for a delegated P2MP TE LSP is 748 described below to report status of leaves in an existing P2MP TE 749 LSP: 751 Common Header 752 LSP with P2MP flag set 753 END-POINTS for leaf type 3 754 S2LS (O=UP) 755 ERO list 756 END-POINTS for leaf type 3 757 S2LS (O=DOWN) 758 ERO list 760 An example of a PCRpt message for a non-delegated P2MP TE LSP is 761 described below to report status of leaves: 763 Common Header 764 LSP with P2MP flag set 765 END-POINTS for leaf type 4 766 S2LS (O=ACTIVE) 767 ERO list 768 END-POINTS for leaf type 4 769 S2LS (O=DOWN) 770 ERO list 772 7. PCEP Object Extensions 774 The PCEP TLV defined in this document is compliant with the PCEP TLV 775 format defined in [RFC5440]. 777 7.1. Extension of LSP Object 779 LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 780 PLSP-ID to uniquely identify an LSP that is constant for the life 781 time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify 782 a P2MP TE LSP uniquely. This document adds the following flags to 783 the LSP Object: 785 N (P2MP bit - TBD7): If the bit is set to 1, it specifies the 786 message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd 787 message for a P2MP TE LSP. 789 F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies 790 the message is fragmented. 792 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 793 present in LSP object. 795 7.2. P2MP-LSP-IDENTIFIER TLV 797 The P2MP LSP Identifier TLV MUST be included in the LSP object in 798 PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is 799 missing, the PCE will generate an error with error-type 6 (mandatory 800 object missing) and error-value TBD12 (P2MP-LSP-IDENTIFIER TLV 801 missing) and close the PCEP session. 803 The P2MP LSP Identifier TLV MAY be included in the LSP object in 804 PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value 805 of all zeros for this TLV is used to refer to all paths pertaining to 806 a particular PLSP-ID. 808 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 809 IPv6. 811 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 812 following figure: 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type=TBD9 | Length=16 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | IPv4 Tunnel Sender Address | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | LSP ID | Tunnel ID | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Extended Tunnel ID | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | P2MP ID | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format 830 The type (16-bit) of the TLV is TBD9 to be assigned by IANA. The 831 length (16-bit) has a fixed value of 16 octets. The value contains 832 the following fields: 834 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 835 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 836 Sender Template Object. 838 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 839 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 840 Object. 842 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 843 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 845 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 846 identifier defined in [RFC3209], Section 4.6.1.1 for the 847 LSP_TUNNEL_IPv4 Session Object. 849 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 850 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 851 Object. 853 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 854 following figure: 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Type=TBD10 | Length=40 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | 862 + + 863 | IPv6 tunnel sender address | 864 + (16 octets) + 865 | | 866 + + 867 | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | LSP ID | Tunnel ID | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | | 872 + + 873 | Extended Tunnel ID | 874 + (16 octets) + 875 | | 876 + + 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | P2MP ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format 884 The type of the TLV is TBD10 to be assigned by IANA. The length 885 (16-bit) has a fixed length of 40 octets. The value contains the 886 following fields: 888 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 889 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 890 Sender Template Object. 892 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 893 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 894 Object. 896 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 897 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 899 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 900 identifier defined in [RFC3209], Section 4.6.1.2 for the 901 LSP_TUNNEL_IPv6 Session Object. 903 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 905 Tunnel ID remains constant over the life time of a tunnel. 907 7.3. S2LS Object 909 The S2LS (Source-to-Leaves) Object is used to report RSVP-TE state of 910 one or more destinations (leaves) encoded within the END-POINTS 911 object for a P2MP TE LSP. It MUST be carried in PCRpt message along 912 with END-POINTS object when N bit is set in LSP object. 914 S2LS Object-Class is TBD19. 916 S2LS Object-Types is 1. 918 The format of the S2LS object is shown in the following figure: 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Flags | O| 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | | 926 // Optional TLVs // 927 | | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Figure 8: S2LS object format 932 Flags(32 bits): 934 O(Operational - 3 bits) the O Field represents the operational 935 status of the group of destinations. The values are as per 936 Operational field in LSP object defined in Section 7.3 of 937 [RFC8231]. 939 When N bit is set in LSP object then the O field in LSP object 940 represents the operational status of the full P2MP TE LSP and the O 941 field in S2LS object represents the operational status of a group of 942 destinations encoded within the END-POINTS object. 944 Future documents MAY define optional TLVs that MAY be included in the 945 S2LS Object. 947 8. Message Fragmentation 949 The total PCEP message length, including the common header, is 16 950 bytes. In certain scenarios the P2MP report and update request may 951 not fit into a single PCEP message (e.g. initial report or update). 952 The F-bit is used in the LSP object to signal that the initial 953 report, update, or initiate message was too large to fit into a 954 single message and will be fragmented into multiple messages. In 955 order to identify the single report or update each message will use 956 the same PLSP-ID. In order to identify that a series of PCInitiate 957 messages represents a single Initiate, each message will use the same 958 PLSP-ID (in this case 0) and SRP-ID-number. 960 Fragmentation procedure described below for report or update message 961 is similar to [I-D.ietf-pce-rfc6006bis] which describes request and 962 response message fragmentation. 964 8.1. Report Fragmentation Procedure 966 If the initial report is too large to fit into a single report 967 message, the PCC will split the report over multiple messages. Each 968 message sent to the PCE, except the last one, will have the F-bit set 969 in the LSP object to signify that the report has been fragmented into 970 multiple messages. In order to identify that a series of report 971 messages represents a single report, each message will use the same 972 PLSP-ID. 974 To indicate P2MP message fragmentation errors associated with a P2MP 975 Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new 976 error-value TBD13 is used if a PCE has not received the last piece of 977 the fragmented message, it should send an error message to the PCC to 978 signal that it has received an incomplete message (i.e., "Fragmented 979 Report failure"). 981 8.2. Update Fragmentation Procedure 983 Once the PCE computes and updates a path for some or all leaves in a 984 P2MP TE LSP, an update message is sent to the PCC. If the update is 985 too large to fit into a single update message, the PCE will split the 986 update over multiple messages. Each update message sent by the PCE, 987 except the last one, will have the F-bit set in the LSP object to 988 signify that the update has been fragmented into multiple messages. 989 In order to identify that a series of update messages represents a 990 single update, each message will use the same PLSP-ID and SRP-ID- 991 number. 993 To indicate P2MP message fragmentation errors associated with a P2MP 994 Update request, a Error-Type (18) for "P2MP Fragmentation Error" and 995 a new error-value TBD14 is used if a PCC has not received the last 996 piece of the fragmented message, it should send an error message to 997 the PCE to signal that it has received an incomplete message (i.e., 998 "Fragmented Update failure"). 1000 8.3. PCIntiate Fragmentation Procedure 1002 Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate 1003 message is sent to the PCC. If the PCInitiate is too large to fit 1004 into a single PCInitiate message, the PCE will split the PCInitiate 1005 over multiple messages. Each PCInitiate message sent by the PCE, 1006 except the last one, will have the F-bit set in the LSP object to 1007 signify that the PCInitiate has been fragmented into multiple 1008 messages. In order to identify that a series of PCInitiate messages 1009 represents a single Initiate, each message will use the same PLSP-ID 1010 (in this case 0) and SRP-ID-number. 1012 To indicate P2MP message fragmentation errors associated with a P2MP 1013 PCInitiate, a Error-Type (18) for "P2MP Fragmentation Error" and a 1014 new error-value TBD15 is used if a PCC has not received the last 1015 piece of the fragmented message, it should send an error message to 1016 the PCE to signal that it has received an incomplete message (i.e., 1017 "Fragmented Instantiation failure"). 1019 9. Non-Support of P2MP TE LSPs for Stateful PCE 1021 The PCEP protocol extensions described in this document for stateful 1022 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 1023 its stateful capability with P2MP as per Section 5.2. If the PCEP 1024 Speaker on the PCC supports the extensions of this draft (understands 1025 the P2MP flag in the LSP object) but did not advertise this 1026 capability, then upon receipt of PCUpd message from the PCE, it 1027 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1028 error-value TBD17 (Attempted LSP Update Request for P2MP if active 1029 stateful PCE capability for P2MP was not advertised). If the PCEP 1030 Speaker on the PCE supports the extensions of this draft (understands 1031 the P2MP flag in the LSP object) but did not advertise this 1032 capability, then upon receipt of a PCRpt message from the PCC, it 1033 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1034 error-value TBD16 (Attempted LSP State Report for P2MP if stateful 1035 PCE capability for P2MP was not advertised) and it will terminate the 1036 PCEP session. 1038 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1039 does not understand the P2MP flag in the LSP object, and therefore 1040 the PCEP extensions described in this document, then the Stateful PCE 1041 would act as per [RFC8231]. 1043 The PCEP protocol extensions described in this document for PCC or 1044 PCE with instantiation capability for P2MP TE LSPs MUST NOT be used 1045 if PCC or PCE has not advertised its stateful capability with 1046 Instantiation and P2MP capability as per Section 5.2. If the PCEP 1047 Speaker on the PCC supports the extensions of this draft (understands 1048 the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but 1049 did not advertise this capability, then upon receipt of PCInitiate 1050 message from the PCE, it SHOULD generate a PCErr with error-type 19 1051 (Invalid Operation), error-value TBD18 (Attempted LSP Instantiation 1052 Request for P2MP if stateful PCE instantiation capability for P2MP 1053 was not advertised). 1055 10. Manageability Considerations 1057 All manageability requirements and considerations listed in 1058 [RFC5440], [I-D.ietf-pce-rfc6006bis], [RFC8231], and 1059 [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol extensions 1060 defined in this document. In addition, requirements and 1061 considerations listed in this section apply. 1063 10.1. Control of Function and Policy 1065 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1066 capability, the LSP Update capability, and the LSP Initiation 1067 capability for P2MP LSPs. 1069 10.2. Information and Data Models 1071 The PCEP YANG module [I-D.ietf-pce-pcep-yang] SHOULD be extended to 1072 include advertised P2MP stateful capabilities, P2MP synchronization 1073 status, and delegation status of P2MP LSP etc. The statistics module 1074 should also count P2MP LSP related data. 1076 10.3. Liveness Detection and Monitoring 1078 Mechanisms defined in this document do not imply any new liveness 1079 detection and monitoring requirements in addition to those already 1080 listed in [RFC5440]. 1082 10.4. Verify Correct Operations 1084 Mechanisms defined in this document do not imply any new operation 1085 verification requirements in addition to those already listed in 1086 [RFC5440], [I-D.ietf-pce-rfc6006bis], [RFC8231], and 1087 [I-D.ietf-pce-pce-initiated-lsp]. 1089 10.5. Requirements On Other Protocols 1091 Mechanisms defined in this document do not imply any new requirements 1092 on other protocols. 1094 10.6. Impact On Network Operations 1096 Mechanisms defined in this document do not have any impact on network 1097 operations in addition to those already listed in [RFC5440], 1098 [I-D.ietf-pce-rfc6006bis], [RFC8231], and 1099 [I-D.ietf-pce-pce-initiated-lsp]. 1101 Stateful PCE feature for P2MP LSP would help with network operations. 1103 11. IANA Considerations 1105 This document requests IANA actions to allocate code points for the 1106 protocol elements defined in this document. 1108 11.1. PCE Capabilities in IGP Advertisements 1110 IANA is requested to allocate new bits in the OSPF Parameters "PCE 1111 Capability Flags" registry, as follows: 1113 Bit Meaning Reference 1114 TBD1 Active Stateful [This I-D] 1115 PCE with P2MP 1116 TBD2 Passive Stateful [This I-D] 1117 PCE with P2MP 1118 TBD3 Stateful PCE [This I-D] 1119 Initiation with P2MP 1121 11.2. STATEFUL-PCE-CAPABILITY TLV 1123 The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and a 1124 registry is requested to be created to manage the flags in the TLV. 1125 IANA is requested to make the following allocations in the 1126 aforementioned registry. 1128 Bit Description Reference 1130 TBD4 P2MP-CAPABILITY [This I-D] 1131 TBD5 P2MP-LSP-UPDATE- [This I-D] 1132 CAPABILITY 1133 TBD6 P2MP-LSP- [This I-D] 1134 INSTANTIATION- 1135 CAPABILITY 1137 11.3. LSP Object 1139 The LSP object is defined in [RFC8231] and a registry is created to 1140 manage the Flags field of the LSP object. 1142 IANA is requested to make the following allocations in the 1143 aforementioned registry. 1145 Bit Description Reference 1147 TBD7 P2MP [This I-D] 1148 TBD8 Fragmentation [This I-D] 1150 11.4. PCEP-Error Object 1152 IANA is requested to allocate new error values within the "PCEP-ERROR 1153 Object Error Types and Values" sub-registry of the PCEP Numbers 1154 registry, as follows: 1156 Error-Type Meaning 1157 6 Mandatory Object missing [RFC5440] 1158 Error-value=TBD11: S2LS object missing 1159 Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing 1160 18 P2MP Fragmentation Error [I-D.ietf-pce-rfc6006bis] 1161 Error-value= TBD13. Fragmented Report 1162 failure 1163 Error-value= TBD14. Fragmented Update 1164 failure 1165 Error-value= TBD15. Fragmented Instantiation 1166 failure 1167 19 Invalid Operation [RFC8231] 1168 Error-value= TBD16. Attempted LSP State Report 1169 for P2MP if stateful PCE capability 1170 for P2MP was not advertised 1171 Error-value= TBD17. Attempted LSP Update Request 1172 for P2MP if active stateful PCE capability 1173 for P2MP was not advertised 1174 Error-value= TBD18. Attempted LSP Instantiation 1175 Request for P2MP if stateful PCE 1176 instantiation capability for P2MP was not 1177 advertised 1179 Reference for all new Error-Value above is [This I-D]. 1181 11.5. PCEP TLV Type Indicators 1183 IANA is requested to make the assignment of a new value for the 1184 existing "PCEP TLV Type Indicators" registry as follows: 1186 Value Meaning Reference 1187 TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] 1188 TBD10 P2MP-IPV6-LSP-IDENTIFIERS [This I-D] 1190 11.6. PCEP object 1192 IANA is requested to allocate new object-class values and object 1193 types within the "PCEP Objects" sub-registry of the PCEP Numbers 1194 registry, as follows. 1196 Object-Class Value Name Reference 1198 TBD19 S2LS [This.I-D] 1199 Object-Type 1200 0: Reserved 1201 1: S2LS 1203 11.7. S2LS object 1205 This document requests that a new sub-registry, named "S2LS Object 1206 Flag Field", is created within the "Path Computation Element Protocol 1207 (PCEP) Numbers" registry to manage the Flag field of the S2LS 1208 object.New values are to be assigned by Standards Action [RFC8126]. 1209 Each bit should be tracked with the following qualities: 1211 o Bit number (counting from bit 0 as the most significant bit) 1213 o Capability description 1215 o Defining RFC 1217 The following values are defined in this document: 1219 Bit Description Reference 1221 29-31 Operational (3-bit) [This.I-D] 1223 12. Security Considerations 1225 The stateful operations on P2MP TE LSP are more CPU-intensive and 1226 also utilize more bandwidth on wire. In the event of an unauthorized 1227 stateful P2MP operations, or a denial of service attack, the 1228 subsequent PCEP operations may be disruptive to the network. 1229 Consequently, it is important that implementations conform to the 1230 relevant security requirements of [RFC5440], 1231 [I-D.ietf-pce-rfc6006bis] and [RFC8231], and 1232 [I-D.ietf-pce-pce-initiated-lsp]. Further [RFC8253] discusses an 1233 enhanced approach to provide secure transport for PCEP via Transport 1234 Layer Security (TLS). 1236 13. Acknowledgments 1238 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 1239 comments. 1241 14. References 1243 14.1. Normative References 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, 1247 DOI 10.17487/RFC2119, March 1997, 1248 . 1250 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1251 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1252 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1253 . 1255 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1256 Zhang, "OSPF Protocol Extensions for Path Computation 1257 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1258 January 2008, . 1260 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1261 Zhang, "IS-IS Protocol Extensions for Path Computation 1262 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1263 January 2008, . 1265 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1266 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1267 DOI 10.17487/RFC5440, March 2009, 1268 . 1270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1272 May 2017, . 1274 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1275 Computation Element Communication Protocol (PCEP) 1276 Extensions for Stateful PCE", RFC 8231, 1277 DOI 10.17487/RFC8231, September 2017, 1278 . 1280 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1281 and D. Dhody, "Optimizations of Label Switched Path State 1282 Synchronization Procedures for a Stateful PCE", RFC 8232, 1283 DOI 10.17487/RFC8232, September 2017, 1284 . 1286 [I-D.ietf-pce-pce-initiated-lsp] 1287 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1288 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1289 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 1290 progress), October 2017. 1292 [I-D.ietf-pce-rfc6006bis] 1293 Zhao, Q., Dhody, D., Palleti, R., and D. King, "Extensions 1294 to the Path Computation Element Communication Protocol 1295 (PCEP) for Point-to-Multipoint Traffic Engineering Label 1296 Switched Paths", draft-ietf-pce-rfc6006bis-04 (work in 1297 progress), September 2017. 1299 14.2. Informative References 1301 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1302 Element (PCE)-Based Architecture", RFC 4655, 1303 DOI 10.17487/RFC4655, August 2006, 1304 . 1306 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 1307 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 1308 June 2007, . 1310 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1311 Yasukawa, Ed., "Extensions to Resource Reservation 1312 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1313 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1314 DOI 10.17487/RFC4875, May 2007, 1315 . 1317 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1318 Path Computation Element (PCE) to Point-to-Multipoint 1319 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1320 DOI 10.17487/RFC5671, October 2009, 1321 . 1323 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1324 Stateful Path Computation Element (PCE)", RFC 8051, 1325 DOI 10.17487/RFC8051, January 2017, 1326 . 1328 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1329 Writing an IANA Considerations Section in RFCs", BCP 26, 1330 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1331 . 1333 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1334 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1335 Path Computation Element Communication Protocol (PCEP)", 1336 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1337 . 1339 [I-D.ietf-pce-pcep-yang] 1340 Dhody, D., Hardwick, J., Beeram, V., and j. 1341 jefftant@gmail.com, "A YANG Data Model for Path 1342 Computation Element Communications Protocol (PCEP)", 1343 draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. 1345 Appendix A. Contributor Addresses 1347 Yuji Kamite 1348 NTT Communications Corporation 1349 Granpark Tower 1350 3-4-1 Shibaura, Minato-ku 1351 Tokyo 108-8118 1352 Japan 1354 EMail: y.kamite@ntt.com 1356 Authors' Addresses 1358 Udayasree Palle 1359 Huawei Technologies 1360 Divyashree Techno Park, Whitefield 1361 Bangalore, Karnataka 560066 1362 India 1364 EMail: udayasreereddy@gmail.com 1366 Dhruv Dhody 1367 Huawei Technologies 1368 Divyashree Techno Park, Whitefield 1369 Bangalore, Karnataka 560066 1370 India 1372 EMail: dhruv.ietf@gmail.com 1374 Yosuke Tanaka 1375 NTT Communications Corporation 1376 Granpark Tower 1377 3-4-1 Shibaura, Minato-ku 1378 Tokyo 108-8118 1379 Japan 1381 EMail: yosuke.tanaka@ntt.com 1383 Vishnu Pavan Beeram 1384 Juniper Networks 1386 EMail: vbeeram@juniper.net