idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-03.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 (May 13, 2017) is 2512 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 1196, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-04) exists of draft-ietf-pce-rfc6006bis-02 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-12 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: November 14, 2017 Y. Tanaka 6 NTT Communications 7 V. Beeram 8 Juniper Networks 9 May 13, 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-03 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 http://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 November 14, 2017. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 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. 144 [I-D.ietf-pce-stateful-pce] provides the fundamental extensions 145 needed for stateful PCE to support general functionality for P2P TE 146 LSP. [I-D.ietf-pce-pce-initiated-lsp] provides the an extensions 147 needed for stateful PCE-initiated P2P TE LSP. Complementarily, this 148 document focuses on the extensions that are necessary in order for 149 the deployment of stateful PCEs to support P2MP TE LSPs. This 150 document describes the setup, maintenance and teardown of PCE- 151 initiated P2MP LSPs under the stateful PCE model. 153 1.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 2. Terminology 161 Terminology used in this document is same as terminology used in 162 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and 163 [I-D.ietf-pce-rfc6006bis]. 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 [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE 173 LSPs. Complementarily, this document focuses on the extensions that 174 are necessary in order for the deployment of stateful PCEs to support 175 P2MP TE LSPs. 177 In addition to that, the stateful nature of a PCE simplifies the 178 information conveyed in PCEP messages since it is possible to refer 179 to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this 180 is an added advantage, where the size of message is much larger. 181 Incase of stateless PCE, a modification of P2MP tree requires 182 encoding of all leaves along with the paths in PCReq message, but 183 using a stateful PCE with P2MP capability, the PCEP message can be 184 used to convey only the modifications (the other information can be 185 retrieved from the P2MP 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 [I-D.ietf-pce-pce-initiated-lsp] further 194 describes the motivation behind the PCE-Initiation capability, which 195 are equally applicable for 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 [I-D.ietf-pce-stateful-pce]. 203 4. Functions to Support P2MP TE LSPs for Stateful PCEs 205 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 206 stateful PCE. It also specifies that a function can be initiated 207 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 208 (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 232 [I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation 233 or the PCE may give up the delegation 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 [I-D.ietf-pce-stateful-pce] to 243 support stateful PCE for P2P TE LSPs. In this document these 244 messages are extended to 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 [I-D.ietf-pce-stateful-pce]. In this document these messages 272 are extended to support P2MP TE LSPs as well. 274 5.2. Capability Advertisement 276 During PCEP Initialization Phase, as per Section 7.1.1 of 277 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 278 capability via Stateful PCE Capability TLV in open message. Two new 279 flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 280 [I-D.ietf-pce-stateful-pce] and updated in 281 [I-D.ietf-pce-pce-initiated-lsp] and 282 [I-D.ietf-pce-stateful-sync-optimizations]. 284 Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), 285 and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: 287 N (P2MP-CAPABILITY bit - TBD4): if set to 1 by a PCC, the N Flag 288 indicates that the PCC is willing to send P2MP LSP State Reports 289 whenever P2MP LSP parameters or operational status changes.; if 290 set to 1 by a PCE, the N Flag indicates that the PCE is interested 291 in receiving LSP State Reports whenever LSP parameters or 292 operational status changes. The P2MP-CAPABILITY Flag must be 293 advertised by both a PCC and a PCE for PCRpt messages P2MP 294 extension to be allowed on a PCEP session. 296 M (P2MP-LSP-UPDATE-CAPABILITY bit - TBD5): if set to 1 by a PCC, the 297 M Flag indicates that the PCC allows modification of P2MP LSP 298 parameters; if set to 1 by a PCE, the M Flag indicates that the 299 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 300 UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE 301 for PCUpd messages P2MP extension to be allowed on a PCEP session. 303 P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a 304 PCC, the P Flag indicates that the PCC allows instantiation of an 305 P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates 306 that the PCE supports P2MP LSP instantiation. The P2MP-LSP- 307 INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in 308 order to support PCE-initiated P2MP LSP instantiation. 310 A PCEP speaker should continue to advertise the basic P2MP capability 311 via mechanisms as described in [I-D.ietf-pce-rfc6006bis]. 313 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 315 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 316 are either LSRs or servers also participating in the IGP, an 317 effective mechanism for PCE discovery within an IGP routing domain 318 consists of utilizing IGP advertisements. Extensions for the 319 advertisement of PCE Discovery Information are defined for OSPF and 320 for IS-IS in [RFC5088] and [RFC5089] respectively. 322 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 323 TLV used to advertise PCE capabilities. It MAY be present within the 324 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 325 provide the description and processing rules for this sub-TLV when 326 carried within OSPF and IS-IS, respectively. 328 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 329 reference: 331 Type: 5 333 Length: Multiple of 4. 335 Value: This contains an array of units of 32 bit flags with the most 336 significant bit as 0. Each bit represents one PCE capability. 338 PCE capability bits are defined in [RFC5088]. This document defines 339 new capability bits for the stateful PCE with P2MP as follows: 341 Bit Capability 342 TBD1 Active Stateful PCE with P2MP 343 TBD2 Passive Stateful PCE with P2MP 344 TBD3 PCE-Initiation with P2MP 346 Note that while active, passive or initiation stateful PCE with P2MP 347 capabilities may be advertised during discovery, PCEP Speakers that 348 wish to use stateful PCEP MUST advertise stateful PCEP capabilities 349 during PCEP session setup, as specified in the current document. A 350 PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP 351 session setup even if it did not receive any IGP PCE capability 352 advertisements. 354 5.4. State Synchronization 356 State Synchronization operations described in Section 5.6 of 357 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 358 The optimizations described in 359 [I-D.ietf-pce-stateful-sync-optimizations] can also be applied for 360 P2MP. 362 5.5. LSP Delegation 364 LSP delegation operations described in Section 5.7 of 365 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 367 5.6. LSP Operations 369 5.6.1. Passive Stateful PCE 371 LSP operations for passive stateful PCE described in Section 5.8.1 of 372 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 374 The Path Computation Request and Response message format for P2MP TE 375 LSPs is described in Section 3.4 and Section 3.5 of 376 [I-D.ietf-pce-rfc6006bis] respectively. 378 The Request and Response message for P2MP TE LSPs are extended to 379 support encoding of LSP object, so that it is possible to refer to a 380 LSP with a unique identifier and simplify the PCEP message exchange. 381 For example, incase of modification of one leaf in a P2MP tree, there 382 should be no need to carry the full P2MP tree in PCReq message. 384 The extension for the Request and Response message for passive 385 stateful operations on P2MP TE LSPs are described in Section 6.3 and 386 Section 6.4. The extension for the Path Computation LSP State Report 387 (PCRpt) message is described in Section 6.1. 389 5.6.2. Active Stateful PCE 391 LSP operations for active stateful PCE described in Section 5.8.2 of 392 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 394 The extension for the Path Computation LSP Update (PCUpd) message for 395 active stateful operations on P2MP TE LSPs are described in 396 Section 6.2. 398 5.6.3. PCE-Initiated LSP 400 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 401 a Path Computation LSP Initiate Request (PCInitiate) message to the 402 PCC to suggest instantiation or deletion of a P2P TE LSP. This 403 document extends the PCInitiate message to support P2MP TE LSP (see 404 details in Section 6.5). 406 P2MP TE LSP suggested instantiation and deletion operations are same 407 as P2P LSP as described in section 5.3 and 5.4 of 408 [I-D.ietf-pce-pce-initiated-lsp]. 410 5.6.3.1. P2MP TE LSP Instantiation 412 The Instantiation operation of P2MP TE LSP is same as defined in 413 section 5.3 of [I-D.ietf-pce-pce-initiated-lsp] including handling of 414 PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error 415 codes remains unchanged. The N bit MUST be set in LSP object in 416 PCInitiate message by PCE to specify the instantiation is for P2MP TE 417 LSP. 419 Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV MUST 420 NOT be included in the LSP object in PCIntiitate message as it SHOULD 421 be generated by PCC and carried in PCRpt message. 423 5.6.3.2. P2MP TE LSP Deletion 425 The deletion operation of P2MP TE LSP is same as defined in section 426 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 427 Message with an LSP object carrying the PLSP-ID of the LSP to be 428 removed and an SRP object with the R flag set (LSP-REMOVE as per 429 section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of 430 processing and error codes remains unchanged. 432 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 434 Adding of new leaves and Pruning of old Leaves for the PCE initiated 435 P2MP TE LSP MUST be carried in PCUpd message and SHOULD refer 436 Section 6.2 for P2MP TE LSP extensions. As defined in 437 [I-D.ietf-pce-rfc6006bis], leaf type = 1 for adding of new leaves, 438 leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are 439 used in PCUpd message. 441 PCC MAY use the Incremental State Update mechanims as described in 442 [RFC4875] to signal adding and pruning of leaves. 444 5.6.3.4. P2MP TE LSP Delegation and Cleanup 446 P2MP TE LSP delegation and cleanup operations are same as defined in 447 section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing 448 and error codes remains unchanged. 450 6. PCEP Message Extensions 452 6.1. The PCRpt Message 454 As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is 455 used to report the current state of a P2P TE LSP. This document 456 extends the PCRpt message in reporting the status of P2MP TE LSP. 458 The format of PCRpt message is as follows: 460 ::= 461 462 Where: 464 ::= 465 [] 467 ::= [] 468 469 470 [ 471 ] 472 474 Where: 476 ::= 477 [] 478 [] 479 480 [] 482 ::= 483 [] 484 485 [] 487 ::= (|) 488 [] 490 ::= (|) 491 [] 493 is defined in [RFC5440] and 494 extended by PCEP extensions. 495 consists of the actual computed and 496 signaled values of the and 497 objects defined in [RFC5440]. 499 The P2MP END-POINTS object defined in [I-D.ietf-pce-rfc6006bis] is 500 mandatory for specifying address of P2MP leaves grouped based on leaf 501 types. 503 o New leaves to add (leaf type = 1) 505 o Old leaves to remove (leaf type = 2) 506 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 508 o Old leaves whose path must be left unchanged (leaf type = 4) 510 When reporting the status of a P2MP TE LSP, the destinations are 511 grouped in END-POINTS object based on the operational status (O field 512 in S2LS object) and leaf type (in END-POINTS). This way the leaves 513 that share the same operational status are grouped together. For 514 reporting the status of delegated P2MP TE LSP, leaf-type = 3, where 515 as for non-delegated P2MP TE LSP, leaf-type = 4 is used. 517 For delegated P2MP TE LSP configuration changes are reported via 518 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 519 type = 1) is used where as removing of old leaves (leaf-type = 2) is 520 used. 522 Note that we preserve compatibility with the 523 [I-D.ietf-pce-stateful-pce] definition of . At least 524 one instance of MUST be present in this message for P2MP 525 LSP. 527 During state synchronization, the PCRpt message must report the 528 status of the full P2MP TE LSP. 530 The S2LS object MUST be carried in PCRpt message along with END- 531 POINTS object when N bit is set in LSP object for P2MP TE LSP. If 532 the S2LS object is missing, the receiving PCE MUST send a PCErr 533 message with Error-type=6 (Mandatory Object missing) and Error- 534 value=TBD11 (S2LS object missing). If the END-POINTS object is 535 missing, the receiving PCE MUST send a PCErr message with Error- 536 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 537 object missing) (defined in [RFC5440]. 539 6.2. The PCUpd Message 541 As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is 542 used to update P2P TE LSP attributes. This document extends the 543 PCUpd message in updating the attributes of P2MP TE LSP. 545 The format of a PCUpd message is as follows: 547 ::= 548 550 Where: 552 ::= 553 [] 555 ::= 556 557 558 560 Where: 562 ::= 563 [] 564 565 [] 567 ::= (|) 568 [] 570 is defined in [RFC5440] and 571 extended by PCEP extensions. 573 Note that we preserve compatibility with the 574 [I-D.ietf-pce-stateful-pce] definition of . 576 The PCC MAY use the make-before-break or sub-group-based procedures 577 described in [RFC4875] based on a local policy decision. 579 The END-POINTS object MUST be carried in PCUpd message when N bit is 580 set in LSP object for P2MP TE LSP. If the END-POINTS object is 581 missing, the receiving PCC MUST send a PCErr message with Error- 582 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 583 object missing) (defined in [RFC5440]. 585 6.3. The PCReq Message 587 As per Section 3.4 of [I-D.ietf-pce-rfc6006bis], PCReq message is 588 used for a P2MP path computation request. This document extends the 589 PCReq message such that a PCC MAY include the LSP object in the PCReq 590 message if the stateful PCE P2MP capability has been negotiated on a 591 PCEP session between the PCC and a PCE. 593 The format of PCReq message is as follows: 595 ::= 596 [] 597 599 where: 601 ::= 602 [] 603 [] 604 [] 606 ::=[] 608 ::= 609 610 [] 611 [] 612 [] 613 [] 614 [] 615 [|] 616 [] 618 ::= 619 [[]] 620 [] 622 ::=(|)[] 623 ::=[] 625 6.4. The PCRep Message 627 As per Section 3.5 of [I-D.ietf-pce-rfc6006bis], PCRep message is 628 used for a P2MP path computation reply. This document extends the 629 PCRep message such that a PCE MAY include the LSP object in the PCRep 630 message if the stateful PCE P2MP capability has been negotiated on a 631 PCEP session between the PCC and a PCE. 633 The format of PCRep message is as follows: 635 ::= 636 638 where: 640 ::=[] 642 ::= 643 [] 644 [] 645 [] 646 [] 647 [] 649 ::= [] 650 651 [] 653 ::= (|) [] 655 ::=[] 656 [] 657 [] 658 [] 659 [] 661 6.5. The PCInitiate message 663 As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE 664 sends a PCInitiate message to a PCC to recommend instantiation of a 665 P2P TE LSP, this document extends the format of PCInitiate message 666 for the creation of P2MP TE LSPs but the creation and deletion 667 operations of P2MP TE LSP are same to the P2P TE LSP. 669 The format of PCInitiate message is as follows: 671 ::= 672 673 Where: 675 ::= 676 [] 678 ::= 679 (|) 681 ::= 682 683 684 [] 686 ::= 687 689 Where: 691 ::= 692 [] 693 694 [] 696 ::= (|) 697 [] 699 is defined in [RFC5440] and extended 700 by PCEP extensions. 702 The PCInitiate message with an LSP object with N bit (P2MP) set is 703 used to convey operation on a P2MP TE LSP. The SRP object is used to 704 correlate between initiation requests sent by the PCE and the error 705 reports and state reports sent by the PCC as described in 706 [I-D.ietf-pce-stateful-pce]. 708 The END-POINTS object MUST be carried in PCInitiate message when N 709 bit is set in LSP object for P2MP TE LSP. If the END-POINTS object 710 is missing, the receiving PCC MUST send a PCErr message with Error- 711 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 712 object missing) (defined in [RFC5440]. 714 6.6. Example 716 6.6.1. P2MP TE LSP Update Request 718 LSP Update Request message is sent by an active stateful PCE to 719 update the P2MP TE LSP parameters or attributes. An example of a 720 PCUpd message for P2MP TE LSP is described below: 722 Common Header 723 SRP 724 LSP with P2MP flag set 725 END-POINTS for leaf type 3 726 ERO list 728 In this example, a stateful PCE request updation of path taken by 729 some of the leaves in a P2MP tree. The update request uses the END- 730 POINT type 3 (modified/reoptimized). The ERO list represents the 731 S2LS path after modification. The update message does not need to 732 encode the full P2MP tree in this case. 734 6.6.2. P2MP TE LSP Report 736 LSP State Report message is sent by a PCC to report or delegate the 737 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 738 LSP is described below to add new leaves to an existing P2MP TE LSP: 740 Common Header 741 LSP with P2MP flag set 742 END-POINTS for leaf type 1 743 S2LS (O=DOWN) 744 ERO list (empty) 746 An example of a PCRpt message for P2MP TE LSP is described below to 747 prune leaves from an existing P2MP TE LSP: 749 Common Header 750 LSP with P2MP flag set 751 END-POINTS for leaf type 2 752 S2LS (O=UP) 753 ERO list 755 An example of a PCRpt message for a delegated P2MP TE LSP is 756 described below to report status of leaves in an existing P2MP TE 757 LSP: 759 Common Header 760 LSP with P2MP flag set 761 END-POINTS for leaf type 3 762 S2LS (O=UP) 763 ERO list 764 END-POINTS for leaf type 3 765 S2LS (O=DOWN) 766 ERO list 768 An example of a PCRpt message for a non-delegated P2MP TE LSP is 769 described below to report status of leaves: 771 Common Header 772 LSP with P2MP flag set 773 END-POINTS for leaf type 4 774 S2LS (O=ACTIVE) 775 ERO list 776 END-POINTS for leaf type 4 777 S2LS (O=DOWN) 778 ERO list 780 7. PCEP Object Extensions 782 The PCEP TLV defined in this document is compliant with the PCEP TLV 783 format defined in [RFC5440]. 785 7.1. Extension of LSP Object 787 LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. 788 It specifies PLSP-ID to uniquely identify an LSP that is constant for 789 the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID 790 identify a P2MP TE LSP uniquely. This document adds the following 791 flags to the LSP Object: 793 N (P2MP bit - TBD7): If the bit is set to 1, it specifies the 794 message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd 795 message for a P2MP TE LSP. 797 F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies 798 the message is fragmented. 800 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 801 present in LSP object. 803 7.2. P2MP-LSP-IDENTIFIER TLV 805 The P2MP LSP Identifier TLV MUST be included in the LSP object in 806 PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is 807 missing, the PCE will generate an error with error-type 6 (mandatory 808 object missing) and error-value TBD12 (P2MP-LSP-IDENTIFIER TLV 809 missing) and close the PCEP session. 811 The P2MP LSP Identifier TLV MAY be included in the LSP object in 812 PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value 813 of all zeros for this TLV is used to refer to all paths pertaining to 814 a particular PLSP-ID. 816 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 817 IPv6. 819 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 820 following figure: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Type=TBD9 | Length=16 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | IPv4 Tunnel Sender Address | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | LSP ID | Tunnel ID | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Extended Tunnel ID | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | P2MP ID | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format 838 The type (16-bit) of the TLV is TBD9 to be assigned by IANA. The 839 length (16-bit) has a fixed value of 16 octets. The value contains 840 the following fields: 842 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 843 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 844 Sender Template Object. 846 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 847 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 848 Object. 850 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 851 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 853 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 854 identifier defined in [RFC3209], Section 4.6.1.1 for the 855 LSP_TUNNEL_IPv4 Session Object. 857 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 858 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 859 Object. 861 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 862 following figure: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Type=TBD10 | Length=40 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 + + 871 | IPv6 tunnel sender address | 872 + (16 octets) + 873 | | 874 + + 875 | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | LSP ID | Tunnel ID | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | | 880 + + 881 | Extended Tunnel ID | 882 + (16 octets) + 883 | | 884 + + 885 | | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | P2MP ID | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format 892 The type of the TLV is TBD10 to be assigned by IANA. The length 893 (16-bit) has a fixed length of 40 octets. The value contains the 894 following fields: 896 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 897 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 898 Sender Template Object. 900 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 901 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 902 Object. 904 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 905 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 907 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 908 identifier defined in [RFC3209], Section 4.6.1.2 for the 909 LSP_TUNNEL_IPv6 Session Object. 911 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 913 Tunnel ID remains constant over the life time of a tunnel. 915 7.3. S2LS Object 917 The S2LS (Source-to-Leaves) Object is used to report RSVP-TE state of 918 one or more destinations (leaves) encoded within the END-POINTS 919 object for a P2MP TE LSP. It MUST be carried in PCRpt message along 920 with END-POINTS object when N bit is set in LSP object. 922 S2LS Object-Class is TBD19. 924 S2LS Object-Types is 1. 926 The format of the S2LS object is shown in the following figure: 928 0 1 2 3 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Flags | O| 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 // Optional TLVs // 935 | | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Figure 8: S2LS object format 940 Flags(32 bits): 942 O(Operational - 3 bits) the O Field represents the operational 943 status of the group of destinations. The values are as per 944 Operational field in LSP object defined in Section 7.3 of 945 [I-D.ietf-pce-stateful-pce]. 947 When N bit is set in LSP object then the O field in LSP object 948 represents the operational status of the full P2MP TE LSP and the O 949 field in S2LS object represents the operational status of a group of 950 destinations encoded within the END-POINTS object. 952 Future documents MAY define optional TLVs that MAY be included in the 953 S2LS Object. 955 8. Message Fragmentation 957 The total PCEP message length, including the common header, is 16 958 bytes. In certain scenarios the P2MP report and update request may 959 not fit into a single PCEP message (e.g. initial report or update). 960 The F-bit is used in the LSP object to signal that the initial 961 report, update, or initiate message was too large to fit into a 962 single message and will be fragmented into multiple messages. In 963 order to identify the single report or update each message will use 964 the same PLSP-ID. In order to identify that a series of PCInitiate 965 messages represents a single Initiate, each message will use the same 966 PLSP-ID (in this case 0) and SRP-ID-number. 968 Fragmentation procedure described below for report or update message 969 is similar to [I-D.ietf-pce-rfc6006bis] which describes request and 970 response message fragmentation. 972 8.1. Report Fragmentation Procedure 974 If the initial report is too large to fit into a single report 975 message, the PCC will split the report over multiple messages. Each 976 message sent to the PCE, except the last one, will have the F-bit set 977 in the LSP object to signify that the report has been fragmented into 978 multiple messages. In order to identify that a series of report 979 messages represents a single report, each message will use the same 980 PLSP-ID. 982 To indicate P2MP message fragmentation errors associated with a P2MP 983 Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new 984 error-value TBD13 is used if a PCE has not received the last piece of 985 the fragmented message, it should send an error message to the PCC to 986 signal that it has received an incomplete message (i.e., "Fragmented 987 Report failure"). 989 8.2. Update Fragmentation Procedure 991 Once the PCE computes and updates a path for some or all leaves in a 992 P2MP TE LSP, an update message is sent to the PCC. If the update is 993 too large to fit into a single update message, the PCE will split the 994 update over multiple messages. Each update message sent by the PCE, 995 except the last one, will have the F-bit set in the LSP object to 996 signify that the update has been fragmented into multiple messages. 997 In order to identify that a series of update messages represents a 998 single update, each message will use the same PLSP-ID and SRP-ID- 999 number. 1001 To indicate P2MP message fragmentation errors associated with a P2MP 1002 Update request, a Error-Type (18) for "P2MP Fragmentation Error" and 1003 a new error-value TBD14 is used if a PCC has not received the last 1004 piece of the fragmented message, it should send an error message to 1005 the PCE to signal that it has received an incomplete message (i.e., 1006 "Fragmented Update failure"). 1008 8.3. PCIntiate Fragmentation Procedure 1010 Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate 1011 message is sent to the PCC. If the PCInitiate is too large to fit 1012 into a single PCInitiate message, the PCE will split the PCInitiate 1013 over multiple messages. Each PCInitiate message sent by the PCE, 1014 except the last one, will have the F-bit set in the LSP object to 1015 signify that the PCInitiate has been fragmented into multiple 1016 messages. In order to identify that a series of PCInitiate messages 1017 represents a single Initiate, each message will use the same PLSP-ID 1018 (in this case 0) and SRP-ID-number. 1020 To indicate P2MP message fragmentation errors associated with a P2MP 1021 PCInitiate, a Error-Type (18) for "P2MP Fragmentation Error" and a 1022 new error-value TBD15 is used if a PCC has not received the last 1023 piece of the fragmented message, it should send an error message to 1024 the PCE to signal that it has received an incomplete message (i.e., 1025 "Fragmented Instantiation failure"). 1027 9. Non-Support of P2MP TE LSPs for Stateful PCE 1029 The PCEP protocol extensions described in this document for stateful 1030 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 1031 its stateful capability with P2MP as per Section 5.2. If the PCEP 1032 Speaker on the PCC supports the extensions of this draft (understands 1033 the P2MP flag in the LSP object) but did not advertise this 1034 capability, then upon receipt of PCUpd message from the PCE, it 1035 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1036 error-value TBD17 (Attempted LSP Update Request for P2MP if active 1037 stateful PCE capability for P2MP was not advertised). If the PCEP 1038 Speaker on the PCE supports the extensions of this draft (understands 1039 the P2MP flag in the LSP object) but did not advertise this 1040 capability, then upon receipt of a PCRpt message from the PCC, it 1041 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1042 error-value TBD16 (Attempted LSP State Report for P2MP if stateful 1043 PCE capability for P2MP was not advertised) and it will terminate the 1044 PCEP session. 1046 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1047 does not understand the P2MP flag in the LSP object, and therefore 1048 the PCEP extensions described in this document, then the Stateful PCE 1049 would act as per [I-D.ietf-pce-stateful-pce]. 1051 The PCEP protocol extensions described in this document for PCC or 1052 PCE with instantiation capability for P2MP TE LSPs MUST NOT be used 1053 if PCC or PCE has not advertised its stateful capability with 1054 Instantiation and P2MP capability as per Section 5.2. If the PCEP 1055 Speaker on the PCC supports the extensions of this draft (understands 1056 the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but 1057 did not advertise this capability, then upon receipt of PCInitiate 1058 message from the PCE, it SHOULD generate a PCErr with error-type 19 1059 (Invalid Operation), error-value TBD18 (Attempted LSP Instantiation 1060 Request for P2MP if stateful PCE instantiation capability for P2MP 1061 was not advertised). 1063 10. Manageability Considerations 1065 All manageability requirements and considerations listed in 1066 [RFC5440], [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], 1067 and [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol 1068 extensions defined in this document. In addition, requirements and 1069 considerations listed in this section apply. 1071 10.1. Control of Function and Policy 1073 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1074 capability, the LSP Update capability, and the LSP Initiation 1075 capability for P2MP LSPs. 1077 10.2. Information and Data Models 1079 The PCEP YANG module [I-D.ietf-pce-pcep-yang] SHOULD be extended to 1080 include advertised P2MP stateful capabilities, P2MP synchronization 1081 status, and delegation status of P2MP LSP etc. The statistics module 1082 should also count P2MP LSP related data. 1084 10.3. Liveness Detection and Monitoring 1086 Mechanisms defined in this document do not imply any new liveness 1087 detection and monitoring requirements in addition to those already 1088 listed in [RFC5440]. 1090 10.4. Verify Correct Operations 1092 Mechanisms defined in this document do not imply any new operation 1093 verification requirements in addition to those already listed in 1094 [RFC5440], [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], 1095 and [I-D.ietf-pce-pce-initiated-lsp]. 1097 10.5. Requirements On Other Protocols 1099 Mechanisms defined in this document do not imply any new requirements 1100 on other protocols. 1102 10.6. Impact On Network Operations 1104 Mechanisms defined in this document do not have any impact on network 1105 operations in addition to those already listed in [RFC5440], 1106 [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], and 1107 [I-D.ietf-pce-pce-initiated-lsp]. 1109 Stateful PCE feature for P2MP LSP would help with network operations. 1111 11. IANA Considerations 1113 This document requests IANA actions to allocate code points for the 1114 protocol elements defined in this document. 1116 11.1. PCE Capabilities in IGP Advertisements 1118 IANA is requested to allocate new bits in the OSPF Parameters "PCE 1119 Capability Flags" registry, as follows: 1121 Bit Meaning Reference 1122 TBD1 Active Stateful [This I-D] 1123 PCE with P2MP 1124 TBD2 Passive Stateful [This I-D] 1125 PCE with P2MP 1126 TBD3 Stateful PCE [This I-D] 1127 Initiation with P2MP 1129 11.2. STATEFUL-PCE-CAPABILITY TLV 1131 The STATEFUL-PCE-CAPABILITY TLV is defined in 1132 [I-D.ietf-pce-stateful-pce] and a registry is requested to be 1133 created to manage the flags in the TLV. IANA is requested to make 1134 the following allocations in the aforementioned registry. 1136 Bit Description Reference 1138 TBD4 P2MP-CAPABILITY [This I-D] 1139 TBD5 P2MP-LSP-UPDATE- [This I-D] 1140 CAPABILITY 1141 TBD6 P2MP-LSP- [This I-D] 1142 INSTANTIATION- 1143 CAPABILITY 1145 11.3. LSP Object 1147 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and a 1148 registry is created to manage the Flags field of the LSP object. 1150 IANA is requested to make the following allocations in the 1151 aforementioned registry. 1153 Bit Description Reference 1155 TBD7 P2MP [This I-D] 1156 TBD8 Fragmentation [This I-D] 1158 11.4. PCEP-Error Object 1160 IANA is requested to allocate new error values within the "PCEP-ERROR 1161 Object Error Types and Values" sub-registry of the PCEP Numbers 1162 registry, as follows: 1164 Error-Type Meaning 1165 6 Mandatory Object missing [RFC5440] 1166 Error-value=TBD11: S2LS object missing 1167 Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing 1168 18 P2MP Fragmentation Error [I-D.ietf-pce-rfc6006bis] 1169 Error-value= TBD13. Fragmented Report 1170 failure 1171 Error-value= TBD14. Fragmented Update 1172 failure 1173 Error-value= TBD15. Fragmented Instantiation 1174 failure 1175 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1176 Error-value= TBD16. Attempted LSP State Report 1177 for P2MP if stateful PCE capability 1178 for P2MP was not advertised 1179 Error-value= TBD17. Attempted LSP Update Request 1180 for P2MP if active stateful PCE capability 1181 for P2MP was not advertised 1182 Error-value= TBD18. Attempted LSP Instantiation 1183 Request for P2MP if stateful PCE 1184 instantiation capability for P2MP was not 1185 advertised 1187 Referece for all new Error-Value above is [This I-D]. 1189 11.5. PCEP TLV Type Indicators 1191 IANA is requested to make the assignment of a new value for the 1192 existing "PCEP TLV Type Indicators" registry as follows: 1194 Value Meaning Reference 1195 TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] 1196 TBD10 P2MP-IPV6-LSP-IDENTIFIERS [This I-D] 1198 11.6. PCEP object 1200 IANA is requested to allocate new object-class values and object 1201 types within the "PCEP Objects" sub-registry of the PCEP Numbers 1202 registry, as follows. 1204 Object-Class Value Name Reference 1206 TBD19 S2LS [This.I-D] 1207 Object-Type 1208 1 1210 11.7. S2LS object 1212 This document requests that a new sub-registry, named "S2LS Object 1213 Flag Field", is created within the "Path Computation Element Protocol 1214 (PCEP) Numbers" registry to manage the Flag field of the S2LS 1215 object.New values are to be assigned by Standards Action [RFC5226]. 1216 Each bit should be tracked with the following qualities: 1218 o Bit number (counting from bit 0 as the most significant bit) 1220 o Capability description 1222 o Defining RFC 1224 The following values are defined in this document: 1226 Bit Description Reference 1228 29-31 Operational (3-bit) [This.I-D] 1230 12. Security Considerations 1232 The stateful operations on P2MP TE LSP are more CPU-intensive and 1233 also utilize more bandwidth on wire. In the event of an unauthorized 1234 stateful P2MP operations, or a denial of service attack, the 1235 subsequent PCEP operations may be disruptive to the network. 1236 Consequently, it is important that implementations conform to the 1237 relevant security requirements of [RFC5440], 1238 [I-D.ietf-pce-rfc6006bis] and [I-D.ietf-pce-stateful-pce], and 1239 [I-D.ietf-pce-pce-initiated-lsp]. Further [I-D.ietf-pce-pceps] 1240 discusses an enhanced approach to provide secure transport for PCEP 1241 via Transport Layer Security (TLS). 1243 13. Acknowledgments 1245 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 1246 comments. 1248 14. References 1250 14.1. Normative References 1252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1253 Requirement Levels", BCP 14, RFC 2119, 1254 DOI 10.17487/RFC2119, March 1997, 1255 . 1257 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1258 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1259 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1260 . 1262 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1263 Zhang, "OSPF Protocol Extensions for Path Computation 1264 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1265 January 2008, . 1267 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1268 Zhang, "IS-IS Protocol Extensions for Path Computation 1269 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1270 January 2008, . 1272 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1273 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1274 DOI 10.17487/RFC5440, March 2009, 1275 . 1277 [I-D.ietf-pce-stateful-pce] 1278 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1279 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1280 pce-18 (work in progress), December 2016. 1282 [I-D.ietf-pce-stateful-sync-optimizations] 1283 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1284 and D. Dhody, "Optimizations of Label Switched Path State 1285 Synchronization Procedures for a Stateful PCE", draft- 1286 ietf-pce-stateful-sync-optimizations-10 (work in 1287 progress), March 2017. 1289 [I-D.ietf-pce-pce-initiated-lsp] 1290 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1291 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1292 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 1293 progress), March 2017. 1295 [I-D.ietf-pce-rfc6006bis] 1296 Zhao, Q., Dhody, D., Palleti, R., and D. King, "Extensions 1297 to the Path Computation Element Communication Protocol 1298 (PCEP) for Point-to-Multipoint Traffic Engineering Label 1299 Switched Paths", draft-ietf-pce-rfc6006bis-02 (work in 1300 progress), April 2017. 1302 14.2. Informative References 1304 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1305 Element (PCE)-Based Architecture", RFC 4655, 1306 DOI 10.17487/RFC4655, August 2006, 1307 . 1309 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 1310 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 1311 June 2007, . 1313 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1314 Yasukawa, Ed., "Extensions to Resource Reservation 1315 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1316 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1317 DOI 10.17487/RFC4875, May 2007, 1318 . 1320 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1321 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1322 DOI 10.17487/RFC5226, May 2008, 1323 . 1325 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1326 Path Computation Element (PCE) to Point-to-Multipoint 1327 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1328 DOI 10.17487/RFC5671, October 2009, 1329 . 1331 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1332 Stateful Path Computation Element (PCE)", RFC 8051, 1333 DOI 10.17487/RFC8051, January 2017, 1334 . 1336 [I-D.ietf-pce-pceps] 1337 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 1338 Transport for PCEP", draft-ietf-pce-pceps-12 (work in 1339 progress), April 2017. 1341 [I-D.ietf-pce-pcep-yang] 1342 Dhody, D., Hardwick, J., Beeram, V., and j. 1343 jefftant@gmail.com, "A YANG Data Model for Path 1344 Computation Element Communications Protocol (PCEP)", 1345 draft-ietf-pce-pcep-yang-02 (work in progress), March 1346 2017. 1348 Appendix A. Contributor Addresses 1350 Yuji Kamite 1351 NTT Communications Corporation 1352 Granpark Tower 1353 3-4-1 Shibaura, Minato-ku 1354 Tokyo 108-8118 1355 Japan 1357 EMail: y.kamite@ntt.com 1359 Authors' Addresses 1361 Udayasree Palle 1362 Huawei Technologies 1363 Divyashree Techno Park, Whitefield 1364 Bangalore, Karnataka 560066 1365 India 1367 EMail: udayasreereddy@gmail.com 1369 Dhruv Dhody 1370 Huawei Technologies 1371 Divyashree Techno Park, Whitefield 1372 Bangalore, Karnataka 560066 1373 India 1375 EMail: dhruv.ietf@gmail.com 1377 Yosuke Tanaka 1378 NTT Communications Corporation 1379 Granpark Tower 1380 3-4-1 Shibaura, Minato-ku 1381 Tokyo 108-8118 1382 Japan 1384 EMail: yosuke.tanaka@ntt.com 1386 Vishnu Pavan Beeram 1387 Juniper Networks 1389 EMail: vbeeram@juniper.net