idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-08.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 22, 2018) is 2007 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 1190, but not defined -- 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 (~~), 3 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: April 25, 2019 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 October 22, 2018 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-08 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 April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 6.7. Adding and Pruning Leaves to/from the P2MP Tree . . . . . 18 90 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 18 91 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 18 92 7.2. P2MP-LSP-IDENTIFIER 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 . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . 28 113 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 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 [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 [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 needed for stateful PCE to support general 145 functionality for P2P TE LSP. [RFC8281] provides the an extensions 146 needed for stateful PCE-initiated P2P TE LSP. Complementarily, this 147 document focuses on the extensions that are necessary in order for 148 the deployment of stateful PCEs to support P2MP TE LSPs. This 149 document describes the setup, maintenance and teardown of PCE- 150 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 LSP 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. 173 Complementarily, this document focuses on the extensions that are 174 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 PLSP-ID ([RFC8231]). For P2MP this is an added 180 advantage, where the size of message is much larger. In case of 181 stateless PCE, a modification of P2MP tree requires encoding of all 182 leaves along with the paths in PCEP message, but using a stateful PCE 183 with P2MP capability, the PCEP message can be used to convey only the 184 modifications (the other information can be retrieved from the P2MP 185 LSP identifier in the LSP database (LSPDB)). 187 In environments where the P2MP TE LSP placement needs to change in 188 response to application demands, it is useful to support dynamic 189 creation and tear down of P2MP TE LSPs. The ability for a PCE to 190 trigger the creation of P2MP TE LSPs on demand can be seamlessly 191 integrated into a controller-based network architecture, where 192 intelligence in the controller can determine when and where to set up 193 paths. Section 3 of [RFC8281] further describes the motivation 194 behind the PCE-Initiation capability, which is equally applicable to 195 P2MP TE LSPs. 197 3.2. Objectives 199 The objectives for the protocol extensions to support P2MP TE LSP for 200 stateful PCE are same as the objectives described in section 3.2 of 201 [RFC8231]. 203 4. Functions to Support P2MP TE LSPs for Stateful PCEs 205 [RFC8231] specifies new functions to support a stateful PCE. It also 206 specifies that a function can be initiated either from a PCC towards 207 a PCE (C-E) or from a PCE towards a PCC (E-C). 209 This document extends these functions to support P2MP TE LSPs. 211 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 212 announce during PCEP session establishment that they support 213 Stateful PCE extensions for P2MP using mechanisms defined in 214 Section 5.2. 216 LSP State Synchronization (C-E): after the session between the PCC 217 and a stateful PCE with P2MP capability is initialized, the PCE 218 must learn the state of a PCC's P2MP TE LSPs before it can perform 219 path computations or update LSP attributes in a PCC. 221 LSP Update Request (E-C): a stateful PCE with P2MP capability 222 requests modification of attributes on a PCC's P2MP TE LSP. 224 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 225 whenever the state of a P2MP TE LSP changes. 227 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 228 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 229 the authoritative source of the LSP's attributes as long as the 230 delegation is in effect (See Section 5.7 of [RFC8231]); the PCC 231 may withdraw the delegation or the PCE may give up the delegation 232 at any time. 234 PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate 235 Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281]. 237 5. Architectural Overview of Protocol Extensions 239 5.1. Extension of PCEP Messages 241 New PCEP messages are defined in [RFC8231] to support stateful PCE 242 for P2P TE LSPs. In this document these messages are extended to 243 support P2MP TE LSPs. 245 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 246 in a PCRpt message can contain actual P2MP TE LSP path attributes, 247 LSP status, etc. An LSP State Report carried in a PCRpt message 248 is also used in delegation or revocation of control of a P2MP TE 249 LSP to/from a PCE. The extension of PCRpt message is described in 250 Section 6.1. 252 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 253 Request in a PCUpd message MUST contain all LSP parameters that a 254 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 255 carried in a PCUpd message is also used to return LSP delegations 256 if at any point PCE no longer desires control of a P2MP TE LSP. 257 The PCUpd message is described in Section 6.2. 259 A PCEP message is defined in [RFC8281] to support stateful PCE 260 instantiation of P2P TE LSPs. In this document this message is 261 extended to support P2MP TE LSPs. 263 Path Computation LSP Initiate Message (PCInitiate): is a PCEP 264 message sent by a PCE to a PCC to trigger P2MP TE LSP 265 instantiation or deletion. The PCInitiate message is described in 266 Section 6.5. 268 The path computation request (PCReq) and path computation reply 269 (PCRep) messages are also extended to support passive stateful PCE 270 for P2P TE LSP in [RFC8231]. In this document these messages are 271 extended to support P2MP TE LSPs as well. 273 5.2. Capability Advertisement 275 During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231], 276 PCEP speakers advertises Stateful capability via Stateful PCE 277 Capability TLV in open message. Various flags are defined for the 278 STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in 279 [RFC8281] and [RFC8232]. 281 Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), 282 and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: 284 N (P2MP-CAPABILITY bit): if set to 1 by a PCC, the N Flag indicates 285 that the PCC is willing to send P2MP LSP State Reports whenever 286 P2MP LSP parameters or operational status changes.; if set to 1 by 287 a PCE, the N Flag indicates that the PCE is interested in 288 receiving LSP State Reports whenever LSP parameters or operational 289 status changes. The P2MP-CAPABILITY Flag must be advertised by 290 both a PCC and a PCE for PCRpt messages P2MP extension to be 291 allowed on a PCEP session. 293 M (P2MP-LSP-UPDATE-CAPABILITY bit): if set to 1 by a PCC, the M Flag 294 indicates that the PCC allows modification of P2MP LSP parameters; 295 if set to 1 by a PCE, the M Flag indicates that the PCE is capable 296 of updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY 297 Flag must be advertised by both a PCC and a PCE for PCUpd messages 298 P2MP extension to be allowed on a PCEP session. 300 P (P2MP-LSP-INSTANTIATION-CAPABILITY bit): If set to 1 by a PCC, the 301 P Flag indicates that the PCC allows instantiation of an P2MP LSP 302 by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE 303 supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION- 304 CAPABILITY flag must be set by both PCC and PCE in order to 305 support PCE-initiated P2MP LSP instantiation. 307 A PCEP speaker should continue to advertise the basic P2MP capability 308 via mechanisms as described in [RFC8306]. 310 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 312 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 313 are either LSRs or servers also participating in the IGP, an 314 effective mechanism for PCE discovery within an IGP routing domain 315 consists of utilizing IGP advertisements. Extensions for the 316 advertisement of PCE Discovery Information are defined for OSPF and 317 for IS-IS in [RFC5088] and [RFC5089] respectively. 319 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 320 TLV used to advertise PCE capabilities. It MAY be present within the 321 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 322 provide the description and processing rules for this sub-TLV when 323 carried within OSPF and IS-IS, respectively. 325 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 326 reference: 328 Type: 5 330 Length: Multiple of 4. 332 Value: This contains an array of units of 32 bit flags with the most 333 significant bit as 0. Each bit represents one PCE capability. 335 PCE capability bits are defined in [RFC5088]. This document defines 336 new capability bits (early allocated by IANA) for the stateful PCE 337 with P2MP as follows: 339 Bit Capability 340 13 Active Stateful PCE with P2MP 341 14 Passive Stateful PCE with P2MP 342 15 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 the P2MP TE LSPs as well. The 356 optimizations described in [RFC8232] can also be applied for P2MP TE 357 LSPs. 359 5.5. LSP Delegation 361 LSP delegation operations (described in Section 5.7 of [RFC8231]) are 362 applicable for P2MP TE LSPs as well. 364 5.6. LSP Operations 366 5.6.1. Passive Stateful PCE 368 LSP operations for passive stateful PCE (described in Section 5.8.1 369 of [RFC8231]) are applicable for P2MP TE LSPs as well. 371 The PCReq and PCRep message format for P2MP TE LSPs is described in 372 Section 3.4 and Section 3.5 of [RFC8306] respectively. 374 The PCReq and PCRep message for P2MP TE LSPs are extended to support 375 encoding of LSP object, so that it is possible to refer to a LSP with 376 a unique identifier and simplify the PCEP message exchange. For 377 example, in case of modification of one leaf in a P2MP tree, there 378 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 [RFC8281], the PCE sends a Path Computation LSP 397 Initiate Request (PCInitiate) message to the PCC to suggest 398 instantiation or deletion of a P2P TE LSP. This document extends the 399 PCInitiate message to support P2MP TE LSP (see details in 400 Section 6.5). 402 The P2MP TE LSP suggested instantiation and deletion operations are 403 same as P2P LSP as described in section 5.3 and 5.4 of [RFC8281]. 405 5.6.3.1. P2MP TE LSP Instantiation 407 The Instantiation operation of P2MP TE LSP is same as defined in 408 section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC- 409 PATH-NAME TLV etc. Rules of processing and error codes remains 410 unchanged. The N (P2MP) bit (Section 7.1) MUST be set in LSP object 411 in PCInitiate message by PCE to specify the instantiation is for P2MP 412 TE LSP. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIER 413 TLV SHOULD NOT be included in the LSP object in PCIntiitate message 414 (as it is generated by PCC and carried in PCRpt message instead) and 415 MUST be ignored on receipt. 417 5.6.3.2. P2MP TE LSP Deletion 419 The deletion operation of P2MP TE LSP is same as defined in section 420 5.4 of [RFC8281] by sending an LSP Initiate Message with an LSP 421 object carrying the PLSP-ID of the LSP to be removed and an SRP 422 object with the R flag set (LSP-REMOVE as per section 5.2 of 423 [RFC8281]). Rules of processing and error codes remains unchanged. 425 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 427 Adding of new leaves and Pruning of old Leaves for the PCE initiated 428 P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for 429 P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for 430 adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP 431 END-POINTS Object are used in PCUpd message. 433 PCC MAY use the Incremental State Update mechanism as described in 434 [RFC4875] to signal adding and pruning of leaves. 436 5.6.3.4. P2MP TE LSP Delegation and Cleanup 438 P2MP TE LSP delegation and cleanup operations are same as defined in 439 section 6 of [RFC8281]. Rules of processing and error codes remains 440 unchanged. 442 6. PCEP Message Extensions 444 6.1. The PCRpt Message 446 As per Section 6.1 of [RFC8231], PCRpt message is used to report the 447 current state of a P2P TE LSP. This document extends the PCRpt 448 message in reporting the status of P2MP TE LSP. 450 The format of PCRpt message is as follows: 452 ::= 453 454 Where: 456 ::= 457 [] 459 ::= [] 460 461 462 [ 463 ] 464 466 Where: 468 ::= 469 [] 470 [] 471 472 [] 474 ::= 475 [] 476 477 [] 479 ::= (|) 480 [] 482 ::= (|) 483 [] 485 is defined in [RFC5440] and 486 extended by PCEP extensions. 487 consists of the actual computed and 488 signaled values of the and 489 objects defined in [RFC5440]. 491 The P2MP END-POINTS object defined in [RFC8306] is mandatory for 492 specifying address of P2MP leaves grouped based on leaf types. 494 o New leaves to add (leaf type = 1) 496 o Old leaves to remove (leaf type = 2) 498 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 499 o Old leaves whose path must be left unchanged (leaf type = 4) 501 When reporting the status of a P2MP TE LSP, the destinations are 502 grouped in END-POINTS object based on the operational status (O field 503 in S2LS object) and leaf type (in END-POINTS). This way the leaves 504 that share the same operational status are grouped together. For 505 reporting the status of delegated P2MP TE LSP leaf-type = 3 is used, 506 where as for non-delegated P2MP TE LSP, leaf-type = 4 is used. 508 For delegated P2MP TE LSP configuration changes are reported via 509 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 510 type = 1) is used where as removing of old leaves (leaf-type = 2) is 511 used. 513 Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be 515 present in this message for P2MP LSP. 517 During state synchronization, the PCRpt message reports the status of 518 the full P2MP TE LSP. 520 The S2LS object MUST be carried in PCRpt message along with END- 521 POINTS object when N (P2MP) bit is set in LSP object for P2MP TE LSP. 522 If the S2LS object is missing, the receiving PCE MUST send a PCErr 523 message with Error-type=6 (Mandatory Object missing) and Error- 524 value=13 (early allocated by IANA) (S2LS object missing). If the 525 END-POINTS object is missing, the receiving PCE MUST send a PCErr 526 message with Error-type=6 (Mandatory Object missing) and Error- 527 value=3 (END-POINTS object missing) (defined in [RFC5440]. 529 6.2. The PCUpd Message 531 As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P 532 TE LSP attributes. This document extends the PCUpd message in 533 updating the attributes of P2MP TE LSP. 535 The format of a PCUpd message is as follows: 537 ::= 538 540 Where: 542 ::= 543 [] 545 ::= 546 547 548 550 Where: 552 ::= 553 [] 554 555 [] 557 ::= (|) 558 [] 560 is defined in [RFC5440] and 561 extended by PCEP extensions. 563 Note that the compatibility with the [RFC8231] definition of is preserved. 566 The PCC SHOULD use the make-before-break or sub-group-based 567 procedures described in [RFC4875] based on a local policy decision. 569 The END-POINTS object MUST be carried in PCUpd message when N bit is 570 set in LSP object for P2MP TE LSP. If the END-POINTS object is 571 missing, the receiving PCC MUST send a PCErr message with Error- 572 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 573 object missing) (defined in [RFC5440]. 575 6.3. The PCReq Message 577 As per Section 3.4 of [RFC8306], PCReq message is used for a P2MP 578 path computation request. This document extends the PCReq message 579 such that a PCC MAY include the LSP object in the PCReq message if 580 the stateful PCE P2MP capability has been negotiated on a PCEP 581 session between the PCC and a PCE. 583 The format of PCReq message is as follows: 585 ::= 586 [] 587 589 where: 591 ::= 592 [] 593 [] 594 [] 596 ::=[] 598 ::= 599 600 [] 601 [] 602 [] 603 [] 604 [] 605 [|] 606 [] 608 ::= 609 [[]] 610 [] 612 ::=(|)[] 613 ::=[] 615 6.4. The PCRep Message 617 As per Section 3.5 of [RFC8306], PCRep message is used for a P2MP 618 path computation reply. This document extends the PCRep message such 619 that a PCE MAY include the LSP object in the PCRep message if the 620 stateful PCE P2MP capability has been negotiated on a PCEP session 621 between the PCC and a PCE. 623 The format of PCRep message is as follows: 625 ::= 626 628 where: 630 ::=[] 632 ::= 633 [] 634 [] 635 [] 636 [] 637 [] 639 ::= [] 640 641 [] 643 ::= (|) [] 645 ::=[] 646 [] 647 [] 648 [] 649 [] 651 6.5. The PCInitiate message 653 As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate 654 message to a PCC to recommend instantiation of a P2P TE LSP, this 655 document extends the format of PCInitiate message for the creation of 656 P2MP TE LSPs but the creation and deletion operations of P2MP TE LSP 657 are same to the P2P TE LSP. 659 The format of PCInitiate message is as follows: 661 ::= 662 663 Where: 665 ::= 666 [] 668 ::= 669 (|) 671 ::= 672 673 674 [] 676 ::= 677 679 Where: 681 ::= 682 [] 683 684 [] 686 ::= (|) 687 [] 689 is defined in [RFC5440] and extended 690 by PCEP extensions. 692 The PCInitiate message with an LSP object with N bit (P2MP) set is 693 used to convey operation on a P2MP TE LSP. The SRP object is used to 694 correlate between initiation requests sent by the PCE and the error 695 reports and state reports sent by the PCC as described in [RFC8231]. 697 The END-POINTS object MUST be carried in PCInitiate message when N 698 bit is set in LSP object for P2MP TE LSP. If the END-POINTS object 699 is missing, the receiving PCC MUST send a PCErr message with Error- 700 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 701 object missing) (defined in [RFC5440]. 703 6.6. Example 704 6.6.1. P2MP TE LSP Update Request 706 LSP Update Request message is sent by an active stateful PCE to 707 update the P2MP TE LSP parameters or attributes. An example of a 708 PCUpd message for P2MP TE LSP is described below: 710 Common Header 711 SRP 712 LSP with P2MP flag set 713 END-POINTS for leaf type 3 714 ERO list 716 In this example, a stateful PCE request updation of path taken by 717 some of the leaves in a P2MP tree. The update request uses the END- 718 POINT type 3 (modified/reoptimized). The ERO list represents the 719 S2LS path after modification. The update message does not need to 720 encode the full P2MP tree in this case. 722 6.6.2. P2MP TE LSP Report 724 LSP State Report message is sent by a PCC to report or delegate the 725 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 726 LSP is described below to add new leaves to an existing P2MP TE LSP: 728 Common Header 729 LSP with P2MP flag set 730 END-POINTS for leaf type 1 731 S2LS (O=DOWN) 732 ERO list (empty) 734 An example of a PCRpt message for P2MP TE LSP is described below to 735 prune leaves from an existing P2MP TE LSP: 737 Common Header 738 LSP with P2MP flag set 739 END-POINTS for leaf type 2 740 S2LS (O=UP) 741 ERO list 743 An example of a PCRpt message for a delegated P2MP TE LSP is 744 described below to report status of leaves in an existing P2MP TE 745 LSP: 747 Common Header 748 LSP with P2MP flag set 749 END-POINTS for leaf type 3 750 S2LS (O=UP) 751 ERO list 752 END-POINTS for leaf type 3 753 S2LS (O=DOWN) 754 ERO list 756 An example of a PCRpt message for a non-delegated P2MP TE LSP is 757 described below to report status of leaves: 759 Common Header 760 LSP with P2MP flag set 761 END-POINTS for leaf type 4 762 S2LS (O=ACTIVE) 763 ERO list 764 END-POINTS for leaf type 4 765 S2LS (O=DOWN) 766 ERO list 768 6.7. Adding and Pruning Leaves to/from the P2MP Tree 770 Section 3.10 of [RFC8306] defines the error-handling procedures when 771 adding new leaves to or removing old leaves from the existing P2MP 772 tree for PCReq message. The same error handling and error-codes are 773 also applicable to the stateful PCE messages as described in this 774 document. 776 7. PCEP Object Extensions 778 The PCEP TLV defined in this document is compliant with the PCEP TLV 779 format defined in [RFC5440]. 781 7.1. Extension of LSP Object 783 LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 784 PLSP-ID to uniquely identify an LSP that is constant for the life 785 time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify 786 a P2MP TE LSP uniquely. This document adds the following flags to 787 the LSP Object: 789 N (P2MP bit): If the bit is set to 1, it specifies the message is 790 for P2MP TE LSP which MUST be set in PCRpt, PCUpd, or PCInitiate 791 message for a P2MP TE LSP. 793 F (Fragmentation bit): If the bit is set to 1, it specifies the 794 message is fragmented. 796 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 797 present in LSP object. 799 7.2. P2MP-LSP-IDENTIFIER TLV 801 The P2MP LSP Identifier TLV MUST be included in the LSP object in 802 PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is 803 missing, the PCE will generate an error with error-type 6 (mandatory 804 object missing) and error-value 14 (early allocated by IANA) (P2MP- 805 LSP-IDENTIFIER TLV missing) and close the PCEP session. 807 The P2MP LSP Identifier TLV MAY be included in the LSP object in 808 PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value 809 of all zeros for this TLV is used to refer to all paths pertaining to 810 a particular PLSP-ID. 812 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 813 IPv6. 815 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 816 following figure: 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Type=32 | Length=16 | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | IPv4 Tunnel Sender Address | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | LSP ID | Tunnel ID | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Extended Tunnel ID | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | P2MP ID | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format 834 The type (16-bit) of the TLV is 32 (early allocated by IANA). The 835 length (16-bit) has a fixed value of 16 octets. The value contains 836 the following fields: 838 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 839 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 840 Sender Template Object. 842 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 843 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 844 Object. 846 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 847 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 849 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 850 identifier defined in [RFC3209], Section 4.6.1.1 for the 851 LSP_TUNNEL_IPv4 Session Object. 853 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 854 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 855 Object. 857 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 858 following figure: 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Type=33 | Length=40 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 + + 867 | IPv6 tunnel sender address | 868 + (16 octets) + 869 | | 870 + + 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | LSP ID | Tunnel ID | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | | 876 + + 877 | Extended Tunnel ID | 878 + (16 octets) + 879 | | 880 + + 881 | | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | P2MP ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format 888 The type of the TLV is 33 (early allocated by IANA). The length 889 (16-bit) has a fixed length of 40 octets. The value contains the 890 following fields: 892 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 893 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 894 Sender Template Object. 896 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 897 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 898 Object. 900 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 901 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 903 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 904 identifier defined in [RFC3209], Section 4.6.1.2 for the 905 LSP_TUNNEL_IPv6 Session Object. 907 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 909 Tunnel ID remains constant over the life time of a tunnel. 911 7.3. S2LS Object 913 The S2LS (Source-to-Leaves) Object is used to report state of one or 914 more destinations (leaves) encoded within the END-POINTS object for a 915 P2MP TE LSP. It MUST be carried in PCRpt message along with END- 916 POINTS object when N bit is set in LSP object. 918 S2LS Object-Class is 41 (Early allocated by IANA). 920 S2LS Object-Types is 1. 922 The format of the S2LS object is shown in the following figure: 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Flags | O| 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | 930 // Optional TLVs // 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 8: S2LS object format 936 Flags(32 bits): 938 O(Operational - 3 bits) the O Field represents the operational 939 status of the group of destinations. The values are as per 940 Operational field in LSP object defined in Section 7.3 of 941 [RFC8231]. 943 When N bit is set in LSP object then the O field in LSP object 944 represents the operational status of the full P2MP TE LSP and the O 945 field in S2LS object represents the operational status of a group of 946 destinations encoded within the END-POINTS object. 948 Future documents MAY define optional TLVs that MAY be included in the 949 S2LS Object. 951 8. Message Fragmentation 953 The total PCEP message length, including the common header, is 16 954 bytes. In certain scenarios the P2MP report and update request may 955 not fit into a single PCEP message (e.g. initial report or update). 956 The F-bit is used in the LSP object to signal that the initial 957 report, update, or initiate message was too large to fit into a 958 single message and will be fragmented into multiple messages. In 959 order to identify the single report or update each message will use 960 the same PLSP-ID. In order to identify that a series of PCInitiate 961 messages represents a single Initiate, each message will use the same 962 PLSP-ID (in this case 0) and SRP-ID-number. 964 Fragmentation procedure described below for report or update message 965 is similar to [RFC8306] which describes request and response message 966 fragmentation. 968 8.1. Report Fragmentation Procedure 970 If the initial report is too large to fit into a single report 971 message, the PCC will split the report over multiple messages. Each 972 message sent to the PCE, except the last one, will have the F-bit set 973 in the LSP object to signify that the report has been fragmented into 974 multiple messages. In order to identify that a series of report 975 messages represents a single report, each message will use the same 976 PLSP-ID. 978 To indicate P2MP message fragmentation errors associated with a P2MP 979 Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new 980 error-value 2 (early allocated by IANA) is used if a PCE has not 981 received the last piece of the fragmented message, it should send an 982 error message to the PCC to signal that it has received an incomplete 983 message (i.e., "Fragmented Report failure"). 985 8.2. Update Fragmentation Procedure 987 Once the PCE computes and updates a path for some or all leaves in a 988 P2MP TE LSP, an update message is sent to the PCC. If the update is 989 too large to fit into a single update message, the PCE will split the 990 update over multiple messages. Each update message sent by the PCE, 991 except the last one, will have the F-bit set in the LSP object to 992 signify that the update has been fragmented into multiple messages. 993 In order to identify that a series of update messages represents a 994 single update, each message will use the same PLSP-ID and SRP-ID- 995 number. 997 To indicate P2MP message fragmentation errors associated with a P2MP 998 Update request, a Error-Type (18) for "P2MP Fragmentation Error" and 999 a new error-value 3 (early allocated by IANA) is used if a PCC has 1000 not received the last piece of the fragmented message, it should send 1001 an error message to the PCE to signal that it has received an 1002 incomplete message (i.e., "Fragmented Update failure"). 1004 8.3. PCIntiate Fragmentation Procedure 1006 Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate 1007 message is sent to the PCC. If the PCInitiate is too large to fit 1008 into a single PCInitiate message, the PCE will split the PCInitiate 1009 over multiple messages. Each PCInitiate message sent by the PCE, 1010 except the last one, will have the F-bit set in the LSP object to 1011 signify that the PCInitiate has been fragmented into multiple 1012 messages. In order to identify that a series of PCInitiate messages 1013 represents a single Initiate, each message will use the same PLSP-ID 1014 (in this case 0) and SRP-ID-number. 1016 To indicate P2MP message fragmentation errors associated with a P2MP 1017 PCInitiate, a Error-Type (18) for "P2MP Fragmentation Error" and a 1018 new error-value 4 (early allocated by IANA) is used if a PCC has not 1019 received the last piece of the fragmented message, it should send an 1020 error message to the PCE to signal that it has received an incomplete 1021 message (i.e., "Fragmented Instantiation failure"). 1023 9. Non-Support of P2MP TE LSPs for Stateful PCE 1025 The PCEP protocol extensions described in this document for stateful 1026 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 1027 its stateful capability with P2MP as per Section 5.2. If the PCEP 1028 Speaker on the PCC supports the extensions of this draft (understands 1029 the P2MP flag in the LSP object) but did not advertise this 1030 capability, then upon receipt of PCUpd message from the PCE, it 1031 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1032 error-value 12 (early allocated by IANA) (Attempted LSP Update 1033 Request for P2MP if active stateful PCE capability for P2MP was not 1034 advertised). If the PCEP Speaker on the PCE supports the extensions 1035 of this draft (understands the P2MP flag in the LSP object) but did 1036 not advertise this capability, then upon receipt of a PCRpt message 1037 from the PCC, it SHOULD generate a PCErr with error-type 19 (Invalid 1038 Operation), error-value 11 (early allocated by IANA) (Attempted LSP 1039 State Report for P2MP if stateful PCE capability for P2MP was not 1040 advertised) and it will terminate the PCEP session. 1042 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1043 does not understand the P2MP flag in the LSP object, and therefore 1044 the PCEP extensions described in this document, then the Stateful PCE 1045 would act as per [RFC8231]. 1047 The PCEP extensions described in this document for PCC or PCE with 1048 instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or 1049 PCE has not advertised its stateful capability with Instantiation and 1050 P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC 1051 supports the extensions of this draft (understands the P (P2MP-LSP- 1052 INSTANTIATION-CAPABILITY) flag) but did not advertise this 1053 capability, then upon receipt of PCInitiate message from the PCE, it 1054 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1055 error-value 13 (early allocated by IANA) (Attempted LSP Instantiation 1056 Request for P2MP if stateful PCE instantiation capability for P2MP 1057 was not advertised). 1059 10. Manageability Considerations 1061 All manageability requirements and considerations listed in 1062 [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP protocol 1063 extensions defined in this document. In addition, requirements and 1064 considerations listed in this section apply. 1066 10.1. Control of Function and Policy 1068 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1069 capability, the LSP Update capability, and the LSP Initiation 1070 capability for P2MP LSPs. 1072 10.2. Information and Data Models 1074 The PCEP YANG module [I-D.ietf-pce-pcep-yang] SHOULD be extended to 1075 include advertised P2MP stateful capabilities, P2MP synchronization 1076 status, and delegation status of P2MP LSP etc. The statistics module 1077 should also count P2MP LSP related data. 1079 10.3. Liveness Detection and Monitoring 1081 Mechanisms defined in this document do not imply any new liveness 1082 detection and monitoring requirements in addition to those already 1083 listed in [RFC5440]. 1085 10.4. Verify Correct Operations 1087 Mechanisms defined in this document do not imply any new operation 1088 verification requirements in addition to those already listed in 1089 [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. 1091 10.5. Requirements On Other Protocols 1093 Mechanisms defined in this document do not imply any new requirements 1094 on other protocols. 1096 10.6. Impact On Network Operations 1098 Mechanisms defined in this document do not have any impact on network 1099 operations in addition to those already listed in [RFC5440], 1100 [RFC8306], [RFC8231], and [RFC8281]. 1102 Stateful PCE feature for P2MP LSP would help with network operations. 1104 11. IANA Considerations 1106 This document requests IANA to confirm the early allocation of the 1107 code-points for the protocol elements defined in this document. 1109 11.1. PCE Capabilities in IGP Advertisements 1111 IANA is requested to confirm the early allocation for the new bits in 1112 the OSPF Parameters "PCE Capability Flags" registry, as follows: 1114 Bit Meaning Reference 1115 13 Active Stateful [This I-D] 1116 PCE with P2MP 1117 14 Passive Stateful [This I-D] 1118 PCE with P2MP 1119 15 Stateful PCE [This I-D] 1120 Initiation with P2MP 1122 11.2. STATEFUL-PCE-CAPABILITY TLV 1124 The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and a 1125 registry was created to manage the flags in the TLV. IANA is 1126 requested to confirm the early allocation of the following code- 1127 points in the aforementioned registry. 1129 Bit Description Reference 1131 25 P2MP-CAPABILITY [This I-D] 1132 24 P2MP-LSP-UPDATE- [This I-D] 1133 CAPABILITY 1134 23 P2MP-LSP- [This I-D] 1135 INSTANTIATION- 1136 CAPABILITY 1138 11.3. LSP Object 1140 The LSP object is defined in [RFC8231] and a registry was created to 1141 manage the Flags field of the LSP object. 1143 IANA is requested to confirm the early allocation of the following 1144 code-points in the aforementioned registry. 1146 Bit Description Reference 1148 3 P2MP [This I-D] 1149 2 Fragmentation [This I-D] 1151 11.4. PCEP-Error Object 1153 IANA is requested to confirm the early allocation of the new error 1154 values within the "PCEP-ERROR Object Error Types and Values" sub- 1155 registry of the PCEP Numbers registry, as follows: 1157 Error-Type Meaning 1158 6 Mandatory Object missing [RFC5440] 1159 Error-value=13: S2LS object missing 1160 Error-value=14: P2MP-LSP-IDENTIFIER TLV missing 1161 18 P2MP Fragmentation Error [RFC8306] 1162 Error-value= 2. Fragmented Report 1163 failure 1164 Error-value= 3. Fragmented Update 1165 failure 1166 Error-value= 4. Fragmented Instantiation 1167 failure 1168 19 Invalid Operation [RFC8231] 1169 Error-value= 11. Attempted LSP State Report 1170 for P2MP if stateful PCE capability 1171 for P2MP was not advertised 1172 Error-value= 12. Attempted LSP Update Request 1173 for P2MP if active stateful PCE capability 1174 for P2MP was not advertised 1175 Error-value= 13. Attempted LSP Instantiation 1176 Request for P2MP if stateful PCE 1177 instantiation capability for P2MP was not 1178 advertised 1180 Reference for all new Error-Value above is [This I-D]. 1182 11.5. PCEP TLV Type Indicators 1184 IANA is requested to confirm the early allocation of the following 1185 code-points in the existing "PCEP TLV Type Indicators" registry as 1186 follows: 1188 Value Meaning Reference 1189 32 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] 1190 33 P2MP-IPV6-LSP-IDENTIFIERS [This I-D] 1192 11.6. PCEP object 1194 IANA is requested to confirm the early allocation for the new object- 1195 class values and object types within the "PCEP Objects" sub-registry 1196 of the PCEP Numbers registry, as follows. 1198 Object-Class Value Name Reference 1200 41 S2LS [This.I-D] 1201 Object-Type 1202 0: Reserved 1203 1: S2LS 1205 11.7. S2LS object 1207 This document requests that a new sub-registry, named "S2LS Object 1208 Flag Field", is created within the "Path Computation Element Protocol 1209 (PCEP) Numbers" registry to manage the Flag field of the S2LS 1210 object.New values are to be assigned by Standards Action [RFC8126]. 1211 Each bit should be tracked with the following qualities: 1213 o Bit number (counting from bit 0 as the most significant bit) 1215 o Capability description 1217 o Defining RFC 1219 The following values are defined in this document: 1221 Bit Description Reference 1223 29-31 Operational (3-bit) [This.I-D] 1225 12. Security Considerations 1227 The stateful operations on P2MP TE LSP are more CPU-intensive and 1228 also utilize more bandwidth on wire. In the event of an unauthorized 1229 stateful P2MP operations, or a denial of service attack, the 1230 subsequent PCEP operations may be disruptive to the network. 1231 Consequently, it is important that implementations conform to the 1232 relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], 1233 and [RFC8281]. 1235 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 1236 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 1237 vulnerabilities and weakness. PCEP also support Transport Layer 1238 Security (TLS) [RFC8253] as per the recommendations and best current 1239 practices in [RFC7525]. 1241 13. Acknowledgments 1243 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 1244 comments. 1246 14. References 1248 14.1. Normative References 1250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1251 Requirement Levels", BCP 14, RFC 2119, 1252 DOI 10.17487/RFC2119, March 1997, 1253 . 1255 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1256 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1257 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1258 . 1260 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1261 Zhang, "OSPF Protocol Extensions for Path Computation 1262 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1263 January 2008, . 1265 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1266 Zhang, "IS-IS Protocol Extensions for Path Computation 1267 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1268 January 2008, . 1270 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1271 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1272 DOI 10.17487/RFC5440, March 2009, 1273 . 1275 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1276 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1277 May 2017, . 1279 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1280 Computation Element Communication Protocol (PCEP) 1281 Extensions for Stateful PCE", RFC 8231, 1282 DOI 10.17487/RFC8231, September 2017, 1283 . 1285 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1286 and D. Dhody, "Optimizations of Label Switched Path State 1287 Synchronization Procedures for a Stateful PCE", RFC 8232, 1288 DOI 10.17487/RFC8232, September 2017, 1289 . 1291 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1292 Computation Element Communication Protocol (PCEP) 1293 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1294 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1295 . 1297 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1298 "Extensions to the Path Computation Element Communication 1299 Protocol (PCEP) for Point-to-Multipoint Traffic 1300 Engineering Label Switched Paths", RFC 8306, 1301 DOI 10.17487/RFC8306, November 2017, 1302 . 1304 14.2. Informative References 1306 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1307 Element (PCE)-Based Architecture", RFC 4655, 1308 DOI 10.17487/RFC4655, August 2006, 1309 . 1311 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 1312 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 1313 June 2007, . 1315 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1316 Yasukawa, Ed., "Extensions to Resource Reservation 1317 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1318 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1319 DOI 10.17487/RFC4875, May 2007, 1320 . 1322 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1323 Path Computation Element (PCE) to Point-to-Multipoint 1324 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1325 DOI 10.17487/RFC5671, October 2009, 1326 . 1328 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1329 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1330 June 2010, . 1332 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1333 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1334 and Authentication for Routing Protocols (KARP) Design 1335 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1336 . 1338 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1339 "Recommendations for Secure Use of Transport Layer 1340 Security (TLS) and Datagram Transport Layer Security 1341 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1342 2015, . 1344 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1345 Stateful Path Computation Element (PCE)", RFC 8051, 1346 DOI 10.17487/RFC8051, January 2017, 1347 . 1349 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1350 Writing an IANA Considerations Section in RFCs", BCP 26, 1351 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1352 . 1354 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1355 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1356 Path Computation Element Communication Protocol (PCEP)", 1357 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1358 . 1360 [I-D.ietf-pce-pcep-yang] 1361 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1362 YANG Data Model for Path Computation Element 1363 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1364 yang-09 (work in progress), October 2018. 1366 Appendix A. Contributor Addresses 1368 Yuji Kamite 1369 NTT Communications Corporation 1370 Granpark Tower 1371 3-4-1 Shibaura, Minato-ku 1372 Tokyo 108-8118 1373 Japan 1375 EMail: y.kamite@ntt.com 1377 Authors' Addresses 1379 Udayasree Palle 1380 Huawei Technologies 1381 Divyashree Techno Park, Whitefield 1382 Bangalore, Karnataka 560066 1383 India 1385 EMail: udayasreereddy@gmail.com 1387 Dhruv Dhody 1388 Huawei Technologies 1389 Divyashree Techno Park, Whitefield 1390 Bangalore, Karnataka 560066 1391 India 1393 EMail: dhruv.ietf@gmail.com 1395 Yosuke Tanaka 1396 NTT Communications Corporation 1397 Granpark Tower 1398 3-4-1 Shibaura, Minato-ku 1399 Tokyo 108-8118 1400 Japan 1402 EMail: yosuke.tanaka@ntt.com 1404 Vishnu Pavan Beeram 1405 Juniper Networks 1407 EMail: vbeeram@juniper.net