idnits 2.17.1 draft-ietf-pce-pce-initiated-lsp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2017) is 2499 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft Individual Contributor 4 Intended status: Standards Track I. Minei 5 Expires: December 24, 2017 Google, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 June 22, 2017 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-ietf-pce-pce-initiated-lsp-10 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 The extensions for stateful PCE provide active control of 22 Multiprotocol Label Switching (MPLS) Traffic Engineering Label 23 Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates 24 control over one or more locally configured LSPs to the PCE. This 25 document describes the creation and deletion of PCE-initiated LSPs 26 under the stateful PCE model. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 24, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 5 72 4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 5 73 4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 6 74 5. PCE-initiated LSP Instantiation and Deletion . . . . . . . . 6 75 5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 6 76 5.2. The R flag in the SRP Object . . . . . . . . . . . . . . 7 77 5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 8 78 5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 10 79 5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 11 80 5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 11 81 6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 11 82 7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 12 83 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 9.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 13 86 9.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 14 87 9.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 14 88 9.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 14 89 9.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 10.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 15 92 10.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 16 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 12.2. Informative References . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 [RFC5440] describes the Path Computation Element Communication 102 Protocol (PCEP). PCEP defines the communication between a Path 103 Computation Client (PCC) and a Path Computation Element (PCE), or 104 between PCE and PCE, enabling computation of Multiprotocol Label 105 Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 106 characteristics. 108 [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to 109 enable stateful control of TE LSPs between and across PCEP sessions 110 in compliance with [RFC4657]. It includes 112 o mechanisms to effect LSP state synchronization between PCCs and 113 PCEs 114 o delegation of control of LSPs to PCEs 115 o PCE control of timing and sequence of path computations within and 116 across PCEP sessions 118 It focuses on a model where LSPs are configured on the PCC and 119 control over them is delegated to the PCE. 121 This document describes the setup, maintenance and teardown of PCE- 122 initiated LSPs under the stateful PCE model, without the need for 123 local configuration on the PCC, thus allowing for a dynamic network 124 that is centrally controlled and deployed. 126 2. Terminology 128 This document uses the following terms defined in [RFC5440]: PCC, 129 PCE, PCEP Peer. 131 This document uses the following terms defined in [RFC8051]: Stateful 132 PCE, Delegation. 134 This document uses the following terms defined in 135 [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, State 136 Timeout Interval, LSP State Report, LSP Update Request. 138 The following terms are defined in this document: 140 PCE-initiated LSP: LSP that is instantiated as a result of a request 141 from the PCE. 143 The message formats in this document are specified using Routing 144 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 146 3. Architectural Overview 148 3.1. Motivation 150 [I-D.ietf-pce-stateful-pce] provides active control over LSPs that 151 are locally configured on the PCC. This model relies on the Label 152 Edge Router (LER) taking an active role in delegating locally 153 configured LSPs to the PCE, and is well suited in environments where 154 the LSP placement is fairly static. However, in environments where 155 the LSP placement needs to change in response to application demands, 156 it is useful to support dynamic creation and tear down of LSPs. The 157 ability for a PCE to trigger the creation of LSPs on demand can be 158 seamlessly integrated into a controller-based network architecture, 159 where intelligence in the controller can determine when and where to 160 set up paths. 162 A possible use case is a software-driven network, where applications 163 request network resources and paths from the network infrastructure. 164 For example, an application can request a path with certain 165 constraints between two LSRs by contacting the PCE. The PCE can 166 compute a path satisfying the constraints, and instruct the head end 167 LSR to instantiate and signal it. When the path is no longer 168 required by the application, the PCE can request its teardown. 170 Another use case is dynamically adjusting aggregate bandwidth between 171 two points in the network using multiple LSPs. This functionality is 172 very similar to auto-bandwidth, but allows for providing the desired 173 capacity through multiple LSPs. This approach overcomes two of the 174 limitations auto-bandwidth can experience: 1) growing the capacity 175 between the endpoints beyond the capacity of individual links in the 176 path and 2) achieving good bin-packing through use of several small 177 LSPs instead of a single large one. The number of LSPs varies based 178 on the demand, and LSPs are created and deleted dynamically to 179 satisfy the bandwidth requirements. 181 Another use case is demand engineering, where a PCE with visibility 182 into both the network state and the demand matrix can anticipate and 183 optimize how traffic is distributed across the infrastructure. Such 184 optimizations may require creating new paths across the 185 infrastructure. 187 3.2. Operation Overview 189 This document defines the new I flag in the STATEFUL-PCE-CAPABILITY 190 TLV to indicate that the sender supports PCE-initiated LSPs (see 191 details in Section 4.1). A PCC or PCE sets this flag in the Open 192 message during the PCEP Initialization Phase to indicate that it 193 supports the procedures of this document. 195 This document defines a new PCEP message, the LSP Initiate Request 196 (PCInitiate) message, which a PCE can send to a PCE to request the 197 initiaton or deletion of an LSP. The decision when to instantiate or 198 delete a PCE-initiated LSP is out of the scope of this document. 200 The PCE sends a PCInitiate message to the PCC to request the 201 initiation of an LSP. The PCC creates the LSP using the attributes 202 communicated by the PCE and local values for any unspecified 203 parameters. The PCC generates an LSP State Report (PCRpt) for the 204 LSP, carrying a newly assigned PLSP-ID for the LSP and delegating the 205 LSP to the PCE via the Delegate flag in the LSP object. 207 The PCE can update the attributes of the LSP by sending subsequent 208 PCUpd messages. Subsequent LSP State Report (PCRpt) and LSP Update 209 Request (PCUpd) messages that the PCC and PCE, respectively, send for 210 the LSP will carry the PCC-assigned PLSP-ID, which uniquely 211 identifies the LSP. See details in Section 5.3. 213 The PCE sends a PCInitiate message to the PCC to request the deletion 214 of an LSP. To indicate a delete operation, this document defines the 215 new R flag in the SRP object in the PCInitiate message, as described 216 in Section 5.2. As a result of the deletion request, the PCC removes 217 all state related to the LSP and sends a PCRpt for the removed state. 218 See details in Section 5.4. 220 4. Support of PCE-initiated LSPs 222 A PCEP speaker indicates its ability to support PCE-initiated LSPs 223 during the PCEP Initialization phase, as follows. When the PCEP 224 session is created, it sends an Open message with an OPEN object that 225 contains the "Stateful PCE Capability" TLV, defined in 226 [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP-INSTANTIATION- 227 CAPABILITY) flag, is introduced to this TLV to indicate support for 228 instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only 229 for PCCs that advertised this capability. A PCC will follow the 230 procedures described in this document only on sessions where the PCE 231 advertised the I flag. 233 4.1. STATEFUL-PCE-CAPABILITY TLV 235 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 236 following figure: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length=4 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Flags |I|S|U| 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 246 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 248 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 249 has a fixed length of 4 octets. 251 The value comprises a single field - Flags (32 bits). The U and S 252 bits are defined in [I-D.ietf-pce-stateful-pce] and 253 [I-D.ietf-pce-stateful-sync-optimizations] respectively. 255 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 256 I Flag indicates that the PCC allows instantiation of an LSP by a 257 PCE. If set to 1 by a PCE, the I flag indicates that the PCE 258 supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY 259 flag must be set by both PCC and PCE in order to enable PCE- 260 initiated LSP instantiation. 262 Unassigned bits are considered reserved. They MUST be set to 0 on 263 transmission and MUST be ignored on receipt. 265 5. PCE-initiated LSP Instantiation and Deletion 267 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 268 message format, objects and TLVs are discussed separately below for 269 the creation and the deletion cases. 271 5.1. The LSP Initiate Request 273 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 274 by a PCE to a PCC to trigger LSP instantiation or deletion. The 275 Message-Type field of the PCEP common header for the PCInitiate 276 message is set to 12. The PCInitiate message MUST include the SRP 277 and the LSP objects, and MAY contain other objects, as discussed 278 later in this section. 280 The format of a PCInitiate message is as follows: 282 ::= 283 284 Where: 285 is defined in [RFC5440] 287 ::= 288 [] 290 ::= (| 291 ) 293 ::= 294 295 [] 296 297 [] 299 ::= 300 302 Where: 303 is defined in [RFC5440] and extended by 304 PCEP extensions. 306 The SRP object is defined in [I-D.ietf-pce-stateful-pce]. The SRP 307 Object contains an SRP-ID-number which is unique within a PCEP 308 session. The PCE increments the last-used SRP-ID-number before it 309 sends each PCInitiate message. The PCC MUST echo the value of the 310 SRP-ID-number in PCErr and PCRpt messages that it sends as a result 311 of the PCInitiate to allow the PCE to correlate them with the 312 corresponding PCInitiate message. 314 5.2. The R flag in the SRP Object 316 The format of the SRP object is shown in Figure 2: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Flags |R| 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | SRP-ID-number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 // Optional TLVs // 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 2: The SRP Object format 332 A new flag is defined to indicate a delete operation initiated by the 333 PCE: 335 R (LSP-REMOVE - 1 bit): If set to 0, it indicates a request to 336 create an LSP. If set to 1, it indicates a request to remove an 337 LSP. 339 5.3. LSP Instantiation 341 The LSP is instantiated by sending a PCInitiate message. The LSP is 342 set up using RSVP-TE. Extensions for other setup methods are outside 343 the scope of this draft. 345 The PCInitiate message, when used to instantiate an LSP, MUST contain 346 an LSP object with the reserved PLSP-ID 0. The LSP Object MUST 347 include the SYMBOLIC-PATH-NAME TLV, which is used to correlate 348 between the PCC-assigned PLSP-ID and the LSP. 350 The PCInitiate message, when used to instantiate an LSP, MUST contain 351 an Explicit Route Object (ERO) for the LSP. 353 For an instantiation request of an RSVP-signaled LSP, the destination 354 address may be needed. The PCC MAY determine it from a provided 355 object (e.g., ERO) or a local decision. Alternatively, the END- 356 POINTS object MAY be included to explicitly convey the destination 357 addresses to be used in the RSVP-TE signaling. The source address 358 MAY be either specified or left up to the PCC decision using the 359 0.0.0.0 value. For LSPs to be setup by other means, the END-POINTS 360 object MAY be omitted; the exact behavior for other types of LSPs 361 will be specified in further documents. 363 The PCE MAY include various attributes as per [RFC5440]. The PCC 364 MUST use these values in the LSP instantiation, and local values for 365 unspecified parameters. After the LSP setup, the PCC MUST send a 366 PCRpt to the PCE, reflecting these values. The SRP object in the 367 PCRpt message MUST echo the value of the PCInitiate message that 368 triggered the setup. LSPs that were instantiated as a result of a 369 PCInitiate message MUST have the Create flag (Section 5.3.1) set in 370 the LSP object. 372 If the PCC receives a PCInitiate message with a non-zero PLSP-ID and 373 the R flag in the SRP object set to zero, then it MUST send a PCErr 374 message with Error-type=19 (Invalid Operation) and Error-value=8 375 (Non-zero PLSP-ID in the PCInitiate message). 377 If the PCC receives a PCInitiate message without an ERO and the R 378 flag in the SRP object set to zero, then it MUST send a PCErr message 379 with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO 380 Object missing). 382 If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME 383 TLV, then it MUST send a PCErr message with Error-type=10 (Invalid 384 object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV missing). 386 The PCE MUST NOT provide a symbolic path name that conflicts with the 387 symbolic path name of any existing LSP in the PCC. (Existing LSPs 388 may be either statically configured, or initiated by another PCE). 389 If there is a conflict with the symbolic path name of an existing 390 LSP, the PCC MUST send a PCErr message with Error-type=23 (Bad 391 Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The 392 only exception to this rule is for LSPs for which the State Timeout 393 Interval timer is running (see Section 6). 395 If the PCC determines that the LSP parameters proposed in the 396 PCInitiate message are unacceptable, it MUST send a PCErr message 397 with Error-type=24 (PCE instantiation error) and Error-value=1 398 (Unacceptable instantiation parameters). If the PCC encounters an 399 internal error during the processing of the PCInitiate message, it 400 MUST send a PCErr message with Error-type=24 (PCE instantiation 401 error) and Error-value=2 (Internal error). 403 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 404 initiated LSP by sending a PCErr message with Error-type=24 (PCE 405 instantiation error) and Error-value=3 (Signaling error). The PCErr 406 message MUST echo the SRP-ID-number of the PCInitiate message. The 407 PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP 408 ERROR_SPEC object was returned to the PCC by a downstream node). 409 After the LSP is set up, errors in RSVP signaling are reported in 410 PCRpt messages, as described in [I-D.ietf-pce-stateful-pce]. 412 On successful completion of the LSP instantiation, the PCC MUST send 413 a PCRpt message. The LSP object message MUST contain a non-zero 414 PLSP-ID that uniquely identifies the LSP within this PCC, and MUST 415 have the Create flag (Section 5.3.1) and Delegate flag set. The SRP 416 object MUST contain an SRP-ID-number that echoes the value from the 417 PCInitiate message that triggered the setup. The PCRpt MUST include 418 the attributes that the PCC used to instantiate the LSP. 420 A PCC SHOULD be able to place a limit on either the number of LSPs or 421 the percentage of resources that are allocated to honor PCE-initiated 422 LSP requests. As soon as that limit is reached, the PCC MUST send a 423 PCErr message with Error-type=19 (Invalid Operation) and Error- 424 value=6 (PCE-initiated LSP limit reached) and is free to drop any 425 incoming PCInitiate messages without additional processing. 427 Similarly, the PCE SHOULD be able to place a limit on either the 428 number of PCInitiate messages pending for a particular PCC, or on the 429 time it waits for a response (positive or negative) to a PCInitiate 430 message from a PCC and MAY take further action (such as closing the 431 session or removing all its LSPs) if this limit is reached. 433 5.3.1. The Create Flag 435 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 436 here for easy reference. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | PLSP-ID |Flags |C| O |A|R|S|D| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 // TLVs // 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 3: The LSP Object format 449 A new flag, the Create (C) flag is introduced. On a PCRpt message, 450 the C Flag set to 1 indicates that this LSP was created via a 451 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 452 message for the duration of existence of the LSP. The Create flag 453 allows PCEs to be aware of which LSPs were PCE-initiated (a state 454 that would otherwise only be known by the PCC and the PCE that 455 initiated them). 457 5.3.2. The SPEAKER-ENTITY-ID TLV 459 The optional SPEAKER-ENTITY-ID TLV defined in 460 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 461 object in a PCRpt message, as an optional TLV for LSPs for which the 462 C flag is 1. The SPEAKER-ENTITY-ID TLV identifies the PCE which 463 initiated the creation of the LSP on all PCEP sessions, a state that 464 would otherwise only be known by the PCC and the PCE that initiated 465 the LSP. If the TLV appears in a PCRpt for an LSP for which the C 466 flag is 0, the LSP MUST be ignored and the PCE MUST send a PCErr 467 message with Error-type=23 ("Bad parameter value") and Error-value=2 468 ("Speaker identity included for an LSP that is not PCE-initiated"). 470 5.4. LSP Deletion 472 A PCE can initiate the removal of a PCE-initiated LSP by sending a 473 PCInitiate message with an LSP object carrying the PLSP-ID of the LSP 474 to be removed and an SRP object with the R flag set (see 475 Section 5.2). A PLSP-ID of zero removes all LSPs that were initiated 476 by the PCE. 478 If the PLSP-ID is unknown, the PCC MUST send a PCErr message with 479 Error-type=19 ("Invalid operation") and Error-value=3 ("Unknown PLSP- 480 ID") ([I-D.ietf-pce-stateful-pce]). 482 If the PLSP-ID specified in the PCInitiate message is not delegated 483 to the PCE, the PCC MUST send a PCErr message with Error-type=19 484 ("Invalid operation") and Error-value=1 ("LSP is not delegated") 485 ([I-D.ietf-pce-stateful-pce]). 487 If the PLSP-ID specified in the PCInitiate message was not created by 488 a PCE, the PCC MUST send a PCErr message with Error-type=19 ("Invalid 489 operation") and Error-value=9 ("LSP is not PCE-initiated"). 491 Following the removal of the LSP, the PCC MUST send a PCRpt as 492 described in [I-D.ietf-pce-stateful-pce]. The SRP object in the 493 PCRpt MUST include the SRP-ID-number from the PCInitiate message that 494 triggered the removal. The R flag in the SRP object MUST be set. 496 6. LSP Delegation and Cleanup 498 The PCC MUST delegate PCE-initiated LSPs to the PCE upon 499 instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt 500 that includes the assigned PLSP-ID. 502 The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an 503 active PCEP session. Therefore, all PCRpt messages from the PCC to 504 the PCE that owns the delegation MUST have the delegation bit set to 505 1. If the PCE that owns the delegation receives a PCRpt message with 506 the delegation bit set to 0 then it MUST send a PCErr message with 507 Error-type=19 ("Invalid Operation") and Error-value=7 ("Delegation 508 for PCE-initiated LSP cannot be revoked"). The PCE MAY further react 509 by closing the session. 511 Control over a PCE-initiated LSP can revert to the PCC in two ways. 512 A PCE MAY return a delegation to the PCC to allow for LSP transfer 513 between PCEs. Alternatively, the PCC gains control an LSP if the 514 PCEP session that it was delegated on fails and the Redelegation 515 Timeout Interval timer expires. In both cases, the LSP becomes an 516 orphan until the expiration of the State Timeout Interval timer 517 ([I-D.ietf-pce-stateful-pce]). 519 The PCC MAY attempt to redelegate an orphaned LSP by following the 520 procedures of [I-D.ietf-pce-stateful-pce]. Alternatively, if the 521 orphaned LSP was PCE-initiated, then a PCE MAY obtain control over 522 it, as follows. 524 A PCE (either the original or one of its backups) sends a PCInitiate 525 message, including just the SRP and LSP objects, and carrying the 526 PLSP-ID of the LSP it wants to take control of. If the PCC receives 527 a PCInitiate message with a PLSP-ID pointing to an orphaned PCE- 528 initiated LSP, then it MUST redelegate that LSP to the PCE. Any 529 other non-zero PLSP-ID MUST result in the generation of a PCErr 530 message using the rules described in Section 5.4. The State Timeout 531 Interval timer for the LSP is stopped upon the redelegation. After 532 obtaining control of the LSP, the PCE may remove it using the 533 procedures described in this document. 535 The State Timeout Interval timer ensures that a PCE crash does not 536 result in automatic and immediate disruption for the services using 537 PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately 538 upon PCE failure. Instead, they are cleaned up on the expiration of 539 this timer. This allows for network cleanup without manual 540 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 541 as one of the behaviors applied on expiration of the State Timeout 542 Interval timer. The behavior SHOULD be picked based on local policy, 543 and can result either in LSP removal, or in reverting to operator- 544 defined default parameters. 546 7. LSP State Synchronization 548 LSP State Synchronization procedures are described in section 5.4 of 549 [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC 550 reports the state of its LSPs to the PCE using PCRpt messages, 551 setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the 552 PCC MUST also set the Create Flag in the LSP Object and MAY include 553 the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP 554 creation. At the end of state synchronization, the PCE SHOULD 555 compare the reported PCE-Initiated LSPs with its configuration. For 556 any mismatch, the PCE SHOULD send a PCInitiate message to initiate 557 any missing LSPs and/or remove any LSPs that are not wanted. 559 8. Implementation Status 561 This section to be removed by the RFC editor. 563 This section records the status of known implementations of the 564 protocol defined by this specification at the time of posting of this 565 Internet-Draft, and is based on a proposal described in [RFC7942]. 566 The description of implementations in this section is intended to 567 assist the IETF in its decision processes in progressing drafts to 568 RFCs. Please note that the listing of any individual implementation 569 here does not imply endorsement by the IETF. Furthermore, no effort 570 has been spent to verify the information presented here that was 571 supplied by IETF contributors. This is not intended as, and must not 572 be construed to be, a catalog of available implementations or their 573 features. Readers are advised to note that other implementations may 574 exist. 576 According to RFC 7942, "this will allow reviewers and working groups 577 to assign due consideration to documents that have the benefit of 578 running code, which may serve as evidence of valuable experimentation 579 and feedback that have made the implemented protocols more mature. 580 It is up to the individual working groups to use this information as 581 they see fit". 583 Two vendors are implementing the extensions described in this draft 584 and have included the functionality in releases that will be shipping 585 in the near future. An additional entity is working on implementing 586 these extensions in the scope of research projects. 588 9. IANA Considerations 590 This document requests IANA actions to allocate code points for the 591 protocol elements defined in this document. 593 9.1. PCEP Messages 595 IANA is requested to confirm the early allocation of the following 596 new message type within the "PCEP Messages" sub-registry of the PCEP 597 Numbers registry, and to update the reference in the registry to 598 point to this document, when it is an RFC: 600 Value Meaning Reference 601 12 LSP Initiate Request This document 603 Note to IANA: The early allocation was done for a message called 604 "Initiate". This name has changed to "LSP Initiate Request" as 605 above. 607 9.2. LSP Object 609 [I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that 610 IANA creates a registry to manage the value of the LSP Object's Flag 611 field. IANA is requested to allocate a new bit in the LSP Object 612 Flag Field registry, as follows: 614 Bit Description Reference 616 4 Create This document 618 9.3. SRP object 620 This document requests that a new sub-registry, named "SRP Object 621 Flag Field", is created within the "Path Computation Element Protocol 622 (PCEP) Numbers" registry to manage the Flag field of the SRP object. 623 New values are to be assigned by Standards Action [RFC5226]. Each 624 bit should be tracked with the following qualities: bit number 625 (counting from bit 0 as the most significant bit), description and 626 defining RFC. 628 The following values are defined in this document: 630 Bit Description Reference 632 31 LSP-Remove This document 634 9.4. STATEFUL-PCE-CAPABILITY TLV 636 [I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV 637 and requests that IANA creates a registry to manage the value of the 638 STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to 639 allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field 640 registry, as follows: 642 Bit Description Reference 644 29 I (LSP-INSTANTIATION- This document 645 CAPABILITY) 647 9.5. PCEP-Error Object 649 IANA is requested to confirm the early allocation of the following 650 new error types and error values within the "PCEP-ERROR Object Error 651 Types and Values" sub-registry of the PCEP Numbers registry, and to 652 update the reference in the registry to point to this document, when 653 it is an RFC: 655 Error-Type Meaning 656 10 Invalid Object 658 Error-value=8: SYMBOLIC-PATH-NAME TLV missing 659 19 Invalid operation 661 Error-value=6: PCE-initiated LSP limit reached 662 Error-value=7: Delegation for PCE-initiated LSP cannot 663 be revoked 664 Error-value=8: Non-zero PLSP-ID in PCInitiate message 665 Error-value=9: LSP is not PCE-initiated 666 Error-value=10: PCE-initiated operation-frequency limit 667 reached 668 23 Bad parameter value 670 Error-value=1: SYMBOLIC-PATH-NAME in use 671 Error-value=2: Speaker identity included for an LSP 672 that is not PCE-initiated 673 24 LSP instantiation error 675 Error-value=1: Unacceptable instantiation parameters 676 Error-value=2: Internal error 677 Error-value=3: Signaling error 679 10. Security Considerations 681 The security considerations described in [I-D.ietf-pce-stateful-pce] 682 apply to the extensions described in this document. Additional 683 considerations related to a malicious PCE are introduced. 685 10.1. Malicious PCE 687 The LSP instantiation mechanism described in this document allows a 688 PCE to generate state on the PCC and throughout the network. As a 689 result, it introduces a new attack vector: an attacker may flood the 690 PCC with LSP instantiation requests and consume network and LSR 691 resources, either by spoofing messages or by compromising the PCE 692 itself. 694 A PCC can protect itself from such an attack by imposing a limit on 695 either the number of LSPs or the percentage of resources that are 696 allocated to honor PCE-initiated LSP requests. As soon as that limit 697 is reached, the PCC MUST send a PCErr message with Error-type=19 698 ("Invalid Operation") and Error-value=6 ("PCE-initiated LSP limit 699 reached") and is free to drop any incoming PCInitiate messages for 700 LSP instantiation without additional processing. 702 Rapid flaps triggered by the PCE can also be an attack vector. A PCC 703 can protect itself from such an attack by imposing a limit on the 704 number of flaps per unit of time that it allows a PCE to generate. 705 As soon as that limit is reached, a PCC MUST send a PCErr message 706 with Error-type=19 ("Invalid Operation") and Error-value=10 ("PCE- 707 initiated operation frequency reached") and is free to treat the 708 session as having reached the limit in terms of resources allocated 709 to honor PCE-initiated LSP requests, either permanently or for a 710 locally-defined cool-off period. 712 10.2. Malicious PCC 714 The LSP instantiation mechanism described in this document requires 715 the PCE to keep state for LSPs that it instantiates and relies on the 716 PCC responding (with either a state report or an error message) to 717 requests for LSP instantiation. A malicious PCC or one that reached 718 the limit of the number of PCE-initiated LSPs, can ignore PCE 719 requests and consume PCE resources. A PCE can protect itself by 720 imposing a limit on the number of requests pending, or by setting a 721 timeout and it MAY take further action such as closing the session or 722 removing all the LSPs it initiated. 724 11. Acknowledgements 726 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 727 Cyril Margaria, Dhruv Dhody, Raveendra Trovi and Jon Hardwick for 728 their contributions to this document. 730 12. References 732 12.1. Normative References 734 [I-D.ietf-pce-stateful-pce] 735 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 736 Extensions for Stateful PCE", draft-ietf-pce-stateful- 737 pce-21 (work in progress), June 2017. 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, 741 DOI 10.17487/RFC2119, March 1997, 742 . 744 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 745 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 746 DOI 10.17487/RFC5440, March 2009, 747 . 749 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 750 Used to Form Encoding Rules in Various Routing Protocol 751 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 752 2009, . 754 12.2. Informative References 756 [I-D.ietf-pce-stateful-sync-optimizations] 757 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 758 and D. Dhody, "Optimizations of Label Switched Path State 759 Synchronization Procedures for a Stateful PCE", draft- 760 ietf-pce-stateful-sync-optimizations-10 (work in 761 progress), March 2017. 763 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 764 Element (PCE) Communication Protocol Generic 765 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 766 2006, . 768 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 769 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 770 DOI 10.17487/RFC5226, May 2008, 771 . 773 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 774 Code: The Implementation Status Section", BCP 205, 775 RFC 7942, DOI 10.17487/RFC7942, July 2016, 776 . 778 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 779 Stateful Path Computation Element (PCE)", RFC 8051, 780 DOI 10.17487/RFC8051, January 2017, 781 . 783 Authors' Addresses 785 Edward Crabbe 786 Individual Contributor 788 Email: edward.crabbe@gmail.com 790 Ina Minei 791 Google, Inc. 792 1600 Amphitheatre Parkway 793 Mountain View, CA 94043 794 US 796 Email: inaminei@google.com 798 Siva Sivabalan 799 Cisco Systems, Inc. 800 170 West Tasman Dr. 801 San Jose, CA 95134 802 US 804 Email: msiva@cisco.com 806 Robert Varga 807 Pantheon Technologies SRO 808 Mlynske Nivy 56 809 Bratislava 821 05 810 Slovakia 812 Email: robert.varga@pantheon.tech