idnits 2.17.1 draft-palle-pce-stateful-pce-initiated-p2mp-lsp-07.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 (January 10, 2016) is 3029 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 459, but not defined == Unused Reference: 'RFC4857' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-04 == Outdated reference: A later version (-09) exists of draft-palle-pce-stateful-pce-p2mp-07 == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group U. Palle 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 13, 2016 Y. Tanaka 6 NTT Communications 7 Z. Ali 8 Cisco Systems 9 V. Beeram 10 Juniper Networks 11 January 10, 2016 13 PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a 14 Stateful PCE Model 15 draft-palle-pce-stateful-pce-initiated-p2mp-lsp-07 17 Abstract 19 The Path Computation Element (PCE) has been identified as an 20 appropriate technology for the determination of the paths of point- 21 to-multipoint (P2MP) TE LSPs. This document provides extensions 22 required for Path Computation Element communication Protocol (PCEP) 23 so as to enable the usage of a stateful PCE initiation capability in 24 recommending P2MP TE LSP instantiation. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 13, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 64 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 66 4. Support of PCE Initiated P2MP TE LSPs . . . . . . . . . . . . 5 67 5. IGP Extensions for PCE-Initiation for P2MP Capabilities 68 Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. PCE-initiated P2MP TE LSP Operations . . . . . . . . . . . . 6 70 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 6 71 6.2. P2MP TE LSP Instantiation . . . . . . . . . . . . . . . . 8 72 6.3. P2MP TE LSP Deletion . . . . . . . . . . . . . . . . . . 8 73 6.4. Adding and Pruning Leaves for the P2MP TE LSP . . . . . . 8 74 6.5. P2MP TE LSP Delegation and Cleanup . . . . . . . . . . . 8 75 7. PCIntiate Message Fragmentation . . . . . . . . . . . . . . . 9 76 7.1. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 9 77 8. Non-Support of P2MP TE LSP Instantiation for Stateful PCE . . 9 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 10. Manageability Considerations . . . . . . . . . . . . . . . . 10 80 10.1. Control of Function and Policy . . . . . . . . . . . . . 10 81 10.2. Information and Data Models . . . . . . . . . . . . . . 10 82 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 10 83 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 10 84 10.5. Requirements On Other Protocols . . . . . . . . . . . . 10 85 10.6. Impact On Network Operations . . . . . . . . . . . . . . 11 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 11 88 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 11 89 11.3. Extension of PCEP-Error Object . . . . . . . . . . . . . 11 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 14.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 98 1. Introduction 100 As per [RFC4655], the Path Computation Element (PCE) is an entity 101 that is capable of computing a network path or route based on a 102 network graph, and applying computational constraints. A Path 103 Computation Client (PCC) may make requests to a PCE for paths to be 104 computed. 106 [RFC4857]describes how to set up point-to-multipoint (P2MP) Traffic 107 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 108 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 109 PCE has been identified as a suitable application for the computation 110 of paths for P2MP TE LSPs ( [RFC5671]). 112 The PCEP is designed as a communication protocol between PCCs and 113 PCEs for point-to-point (P2P) path computations and is defined in 114 [RFC5440]. The extensions of PCEP to request path computation for 115 P2MP TE LSPs are described in [RFC6006]. 117 Stateful PCEs are shown to be helpful in many application scenarios, 118 in both MPLS and GMPLS networks, as illustrated in 119 [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to 120 P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the 121 fundamental extensions needed for stateful PCE to support general 122 functionality for P2P TE LSP. Further 123 [I-D.palle-pce-stateful-pce-p2mp] focuses on the extensions that are 124 necessary in order for the deployment of stateful PCEs to support 125 P2MP TE LSPs. It includes mechanisms to effect P2MP LSP state 126 synchronization between PCCs and PCEs, delegation of control of P2MP 127 LSPs to PCEs, and PCE control of timing and sequence of P2MP path 128 computations within and across PCEP sessions and focuses on a model 129 where P2MP LSPs are configured on the PCC and control over them is 130 delegated to the PCE. 132 [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental extensions 133 needed for stateful PCE-initiated P2P TE LSP recommended 134 instantiation. 136 This document describes the setup, maintenance and teardown of PCE- 137 initiated P2MP LSPs under the stateful PCE model, without the need 138 for local configuration on the PCC, thus allowing for a dynamic 139 network that is centrally controlled and deployed. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Terminology 149 Terminology used in this document is same as terminology used in 150 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp] and 151 [RFC6006]. 153 3. Architectural Overview 155 3.1. Motivation 157 [I-D.palle-pce-stateful-pce-p2mp] provides stateful control over P2MP 158 TE LSPs that are locally configured on the PCC. This model relies on 159 the Ingress taking an active role in delegating locally configured 160 P2MP TE LSPs to the PCE, and is well suited in environments where the 161 P2MP TE LSP placement is fairly static. However, in environments 162 where the P2MP TE LSP placement needs to change in response to 163 application demands, it is useful to support dynamic creation and 164 tear down of P2MP TE LSPs. The ability for a PCE to trigger the 165 creation of P2MP TE LSPs on demand can be seamlessly integrated into 166 a controller-based network architecture, where intelligence in the 167 controller can determine when and where to set up paths. 169 Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further describes the 170 motivation behind the PCE-Initiation capability, which are equally 171 applicable for P2MP TE LSPs. 173 3.2. Operation Overview 175 A PCC or PCE indicates its ability to support PCE provisioned dynamic 176 P2MP LSPs during the PCEP Initialization Phase via mechanism 177 described in Section 4. 179 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 180 a Path Computation LSP Initiate Request (PCInitiate) message to the 181 PCC to suggest instantiation or deletion of a P2P TE LSP. This 182 document extends the PCInitiate message to support P2MP TE LSP (see 183 details in Section 6.1). 185 P2MP TE LSP suggested instantiation and deletion operations are same 186 as P2P LSP as described in section 5.3 and 5.4 of 187 [I-D.ietf-pce-pce-initiated-lsp]. This document focuses on 188 extensions needed for further handling of P2MP TE LSP (see details in 189 Section 6.2). 191 4. Support of PCE Initiated P2MP TE LSPs 193 During PCEP Initialization Phase, as per Section 7.1.1 of 194 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 195 capability via Stateful PCE Capability TLV in open message. A new 196 flag is defined for the STATEFUL-PCE-CAPABILITY TLV defined in 197 [I-D.ietf-pce-stateful-pce] and updated in 198 [I-D.ietf-pce-pce-initiated-lsp], 199 [I-D.ietf-pce-stateful-sync-optimizations], and 200 [I-D.palle-pce-stateful-pce-p2mp]. 202 A new bit P (P2MP-LSP-INSTANTIATION-CAPABILITY) is added in this 203 document: 205 P (P2MP-LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, 206 the P Flag indicates that the PCC allows suggested instantiation 207 of an P2MP LSP by a PCE. If set to 1 by a PCE, the P flag 208 indicates that the PCE will suggest P2MP LSP instantiation. The 209 P2MP-LSP-INSTANTIATION-CAPABILITY flag must be set by both PCC and 210 PCE in order to support PCE-initiated P2MP LSP instantiation. 212 A PCEP speaker should continue to advertise the basic P2MP capability 213 via mechanisms as described in [RFC6006]. 215 5. IGP Extensions for PCE-Initiation for P2MP Capabilities 216 Advertisement 218 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 219 are either LSRs or servers also participating in the IGP, an 220 effective mechanism for PCE discovery within an IGP routing domain 221 consists of utilizing IGP advertisements. Extensions for the 222 advertisement of PCE Discovery Information are defined for OSPF and 223 for IS-IS in [RFC5088] and [RFC5089] respectively. 225 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 226 TLV used to advertise PCE capabilities. It MAY be present within the 227 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 228 provide the description and processing rules for this sub-TLV when 229 carried within OSPF and IS-IS, respectively. 231 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 232 reference: 234 Type: 5 235 Length: Multiple of 4. 237 Value: This contains an array of units of 32 bit flags with the most 238 significant bit as 0. Each bit represents one PCE capability. 240 PCE capability bits are defined in [RFC5088]. This document defines 241 a new capability bit for the PCE-Initiation with P2MP as follows: 243 Bit Capability 244 TBD PCE-Initiation with P2MP 246 Note that while PCE-Initiation for P2MP capability may be advertised 247 during discovery, PCEP Speakers that wish to use stateful PCEP MUST 248 negotiate stateful PCE-Initiation capabilities during PCEP session 249 setup, as specified in the current document. 251 6. PCE-initiated P2MP TE LSP Operations 253 6.1. The PCInitiate message 255 As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE 256 sends a PCInitiate message to a PCC to recommend instantiation of a 257 P2P TE LSP, this document extends the format of PCInitiate message 258 for the creation of P2MP TE LSPs but the creation and deletion 259 operations of P2MP TE LSP are same to the P2P TE LSP. 261 The format of PCInitiate message is as follows: 263 ::= 264 265 Where: 267 ::= 268 [] 270 ::= 271 (|) 273 ::= 274 275 276 [] 278 ::= 279 281 Where: 283 ::= 284 [] 285 286 [] 288 ::= (|) 289 [] 291 is defined in [RFC5440] and extended 292 by PCEP extensions. 294 The PCInitiate message with an LSP object with N bit (P2MP) set is 295 used to convey operation on a P2MP TE LSP. The SRP object is used to 296 correlate between initiation requests sent by the PCE and the error 297 reports and state reports sent by the PCC as described in 298 [I-D.ietf-pce-stateful-pce]. 300 The END-POINTS object MUST be carried in PCInitiate message when N 301 bit is set in LSP object for P2MP TE LSP. If the END-POINTS object 302 is missing, the receiving PCC MUST send a PCErr message with Error- 303 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 304 object missing) (defined in [RFC5440]. 306 6.2. P2MP TE LSP Instantiation 308 The Instantiation operation of P2MP TE LSP is same as defined in 309 section 5.3 of [I-D.ietf-pce-pce-initiated-lsp] including handling of 310 PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error 311 codes remains unchanged. Further, as defined in section 6.1 of 312 [I-D.palle-pce-stateful-pce-p2mp], N bit MUST be set in LSP object in 313 PCInitiate message by PCE to specify the instantiation is for P2MP TE 314 LSP and the PCC or PCE MUST follow the mechanism defined in 315 [I-D.palle-pce-stateful-pce-p2mp] for delegation and updation of P2MP 316 TE LSPs. 318 Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV 319 defined in section 6.2 of [I-D.palle-pce-stateful-pce-p2mp] MUST NOT 320 be included in the LSP object in PCIntiitate message as it SHOULD be 321 generated by PCC and carried in PCRpt message. 323 6.3. P2MP TE LSP Deletion 325 The deletion operation of P2MP TE LSP is same as defined in section 326 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 327 Message with an LSP object carrying the PLSP-ID of the LSP to be 328 removed and an SRP object with the R flag set (LSP-REMOVE as per 329 section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of 330 processing and error codes remains unchanged. 332 6.4. Adding and Pruning Leaves for the P2MP TE LSP 334 Adding of new leaves and Pruning of old Leaves for the PCE initiated 335 P2MP TE LSP MUST be carried in PCUpd message and SHOULD refer 336 [I-D.palle-pce-stateful-pce-p2mp] for P2MP TE LSP extensions. As 337 defined in [RFC6006], leaf type = 1 for adding of new leaves, leaf 338 type = 2 for pruning of old leaves of P2MP END-POINTS Object are used 339 in PCUpd message. 341 PCC MAY use the Incremental State Update mechanims as described in 342 [RFC4875] to signal adding and pruning of leaves. 344 6.5. P2MP TE LSP Delegation and Cleanup 346 P2MP TE LSP delegation and cleanup operations are same as defined in 347 section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing 348 and error codes remains unchanged. 350 7. PCIntiate Message Fragmentation 352 The total PCEP message length, including the common header, is 16 353 bytes. In certain scenarios the P2MP LSP Initiate may not fit into a 354 single PCEP message (e.g. initial PCInitiate message). The F-bit is 355 used in the LSP object to signal that the initial PCInitiate was too 356 large to fit into a single message and will be fragmented into 357 multiple messages. 359 Fragmentation procedure described below for PCInitiate message is 360 similar to [RFC6006] which describes request and response message 361 fragmentation. 363 7.1. PCIntiate Fragmentation Procedure 365 Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate 366 message is sent to the PCC. If the PCInitiate is too large to fit 367 into a single PCInitiate message, the PCE will split the PCInitiate 368 over multiple messages. Each PCInitiate message sent by the PCE, 369 except the last one, will have the F-bit set in the LSP object to 370 signify that the PCInitiate has been fragmented into multiple 371 messages. In order to identify that a series of PCInitiate messages 372 represents a single Initiate, each message will use the same PLSP-ID 373 (in this case 0) and SRP-ID-number. 375 To indicate P2MP message fragmentation errors associated with a P2MP 376 PCInitiate, a Error-Type (18) and a new error-value TBD is used if a 377 PCC has not received the last piece of the fragmented message, it 378 should send an error message to the PCE to signal that it has 379 received an incomplete message (i.e., "Fragmented Instantiation 380 failure"). 382 8. Non-Support of P2MP TE LSP Instantiation for Stateful PCE 384 The PCEP protocol extensions described in this document for PCC or 385 PCE with instantiation capability for P2MP TE LSPs MUST NOT be used 386 if PCC or PCE has not advertised its stateful capability with 387 Instantiation and P2MP capability as per Section 4. If the PCEP 388 Speaker on the PCC supports the extensions of this draft (understands 389 the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but 390 did not advertise this capability, then upon receipt of PCInitiate 391 message from the PCE, it SHOULD generate a PCErr with error-type 19 392 (Invalid Operation), error-value TBD (Attempted LSP Instantiation 393 Request for P2MP if stateful PCE instantiation capability for P2MP 394 was not advertised). 396 9. Security Considerations 398 The stateful operations on P2MP TE LSP are more CPU-intensive and 399 also utilize more link bandwidth. In the event of an unauthorized 400 stateful P2MP operations, or a denial of service attack, the 401 subsequent PCEP operations may be disruptive to the network. 402 Consequently, it is important that implementations conform to the 403 relevant security requirements of [RFC5440], [RFC6006], 404 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp]. 406 10. Manageability Considerations 408 All manageability requirements and considerations listed in 409 [RFC5440], [RFC6006], [I-D.ietf-pce-stateful-pce] and 410 [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol extensions 411 defined in this document. In addition, requirements and 412 considerations listed in this section apply. 414 10.1. Control of Function and Policy 416 A PCE or PCC implementation MUST allow configuring the stateful 417 Initiation capability for P2MP LSPs. 419 10.2. Information and Data Models 421 The PCEP MIB module SHOULD be extended to include advertised P2MP 422 stateful PCE-Initiation capability etc. 424 10.3. Liveness Detection and Monitoring 426 Mechanisms defined in this document do not imply any new liveness 427 detection and monitoring requirements in addition to those already 428 listed in [RFC5440]. 430 10.4. Verify Correct Operations 432 Mechanisms defined in this document do not imply any new operation 433 verification requirements in addition to those already listed in 434 [RFC5440], [RFC6006] and [I-D.ietf-pce-stateful-pce]. 436 10.5. Requirements On Other Protocols 438 Mechanisms defined in this document do not imply any new requirements 439 on other protocols. 441 10.6. Impact On Network Operations 443 Mechanisms defined in this document do not have any impact on network 444 operations in addition to those already listed in [RFC5440], 445 [RFC6006] and [I-D.ietf-pce-stateful-pce]. 447 11. IANA Considerations 449 This document requests IANA actions to allocate code points for the 450 protocol elements defined in this document. Values shown here are 451 suggested for use by IANA. 453 11.1. PCE Capabilities in IGP Advertisements 455 IANA is requested to allocate a new bit in "PCE Capability Flags" 456 registry for PCE-Initiation for P2MP capability as follows: 458 Bit Meaning Reference 459 TBD Stateful PCE [This I-D] 460 Initiation with P2MP 462 11.2. STATEFUL-PCE-CAPABILITY TLV 464 The following values are defined in this document for the Flags field 465 in the STATEFUL-PCE-CAPABILITY-TLV (defined in 466 [I-D.ietf-pce-stateful-pce]) in the OPEN object: 468 Bit Description Reference 470 TBD P2MP-LSP- This.I-D 471 INSTANTIATION- 472 CAPABILITY 474 11.3. Extension of PCEP-Error Object 476 A error types 19 (recommended values) is defined in section 8.4 of 477 [I-D.ietf-pce-stateful-pce]. The error-type 18 is deined in 478 [RFC6006]. This document extend the new Error-Values for the error 479 type for the following error conditions: 481 Error-Type Meaning 482 18 P2MP Fragmentation Error 483 Error-value= TBD. Fragmented Instantiation 484 failure 485 19 Invalid Operation 486 Error-value= TBD. Attempted LSP Instantiation 487 Request for P2MP if stateful PCE 488 instantiation capability for P2MP was not 489 advertised 491 Upon approval of this document, IANA is requested to make the 492 assignment of a new error value for the existing "PCEP-ERROR Object 493 Error Types and Values" registry located at 494 http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object. 496 12. Security Considerations 498 The security considerations described in [I-D.ietf-pce-stateful-pce] 499 and [I-D.ietf-pce-pce-initiated-lsp] apply to the extensions 500 described in this document. The stateful operations on P2MP TE LSP 501 are more CPU-intensive and also utilize more link bandwidth. In the 502 event of an unauthorized stateful P2MP operations, or a denial of 503 service attack, the subsequent PCEP operations may be disruptive to 504 the network. Consequently, it is important that implementations 505 conform to the relevant security requirements of [RFC5440], 506 [RFC6006], [I-D.ietf-pce-stateful-pce], and 507 [I-D.ietf-pce-pce-initiated-lsp]. 509 13. Acknowledgments 511 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 512 comments. 514 14. References 516 14.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 524 Zhang, "OSPF Protocol Extensions for Path Computation 525 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 526 January 2008, . 528 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 529 Zhang, "IS-IS Protocol Extensions for Path Computation 530 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 531 January 2008, . 533 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 534 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 535 DOI 10.17487/RFC5440, March 2009, 536 . 538 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 539 Ali, Z., and J. Meuric, "Extensions to the Path 540 Computation Element Communication Protocol (PCEP) for 541 Point-to-Multipoint Traffic Engineering Label Switched 542 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 543 . 545 [I-D.ietf-pce-stateful-pce] 546 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 547 Extensions for Stateful PCE", draft-ietf-pce-stateful- 548 pce-13 (work in progress), December 2015. 550 [I-D.ietf-pce-pce-initiated-lsp] 551 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 552 Extensions for PCE-initiated LSP Setup in a Stateful PCE 553 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 554 progress), October 2015. 556 [I-D.ietf-pce-stateful-sync-optimizations] 557 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 558 and D. Dhody, "Optimizations of Label Switched Path State 559 Synchronization Procedures for a Stateful PCE", draft- 560 ietf-pce-stateful-sync-optimizations-04 (work in 561 progress), November 2015. 563 [I-D.palle-pce-stateful-pce-p2mp] 564 Palle, U., Dhody, D., Tanaka, Y., Ali, Z., and V. Beeram, 565 "Path Computation Element (PCE) Protocol Extensions for 566 Stateful PCE usage for Point-to-Multipoint Traffic 567 Engineering Label Switched Paths", draft-palle-pce- 568 stateful-pce-p2mp-07 (work in progress), June 2015. 570 14.2. Informative References 572 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 573 Element (PCE)-Based Architecture", RFC 4655, 574 DOI 10.17487/RFC4655, August 2006, 575 . 577 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 578 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 579 June 2007, . 581 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 582 Yasukawa, Ed., "Extensions to Resource Reservation 583 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 584 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 585 DOI 10.17487/RFC4875, May 2007, 586 . 588 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 589 Path Computation Element (PCE) to Point-to-Multipoint 590 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 591 DOI 10.17487/RFC5671, October 2009, 592 . 594 [I-D.ietf-pce-stateful-pce-app] 595 Zhang, X. and I. Minei, "Applicability of a Stateful Path 596 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 597 app-05 (work in progress), October 2015. 599 Appendix A. Contributor Addresses 601 Yuji Kamite 602 NTT Communications Corporation 603 Granpark Tower 604 3-4-1 Shibaura, Minato-ku 605 Tokyo 108-8118 606 Japan 608 EMail: y.kamite@ntt.com 610 Authors' Addresses 612 Udayasree Palle 613 Huawei Technologies 614 Divyashree Techno Park, Whitefield 615 Bangalore, Karnataka 560037 616 India 618 EMail: udayasree.palle@huawei.com 620 Dhruv Dhody 621 Huawei Technologies 622 Divyashree Techno Park, Whitefield 623 Bangalore, Karnataka 560037 624 India 626 EMail: dhruv.ietf@gmail.com 628 Yosuke Tanaka 629 NTT Communications Corporation 630 Granpark Tower 631 3-4-1 Shibaura, Minato-ku 632 Tokyo 108-8118 633 Japan 635 EMail: yosuke.tanaka@ntt.com 637 Zafar Ali 638 Cisco Systems 640 EMail: zali@cisco.com 641 Vishnu Pavan Beeram 642 Juniper Networks 644 EMail: vbeeram@juniper.net