idnits 2.17.1 draft-ietf-pce-enhanced-errors-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5440, but the abstract doesn't seem to directly say this. It does mention RFC5440 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5440, updated by this document, for RFC5378 checks: 2005-11-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 August 2021) is 962 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: 'RFCYYYY' is mentioned on line 655, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H.P. Pouyllau 3 Internet-Draft Alcatel-Lucent 4 Updates: 5440 (if approved) R.T. Theillaud 5 Intended status: Standards Track Marben Products 6 Expires: 1 March 2022 J.M. Meuric 7 Orange 8 H. Zheng (Editor) 9 X. Zhang 10 Huawei Technologies 11 28 August 2021 13 Extensions to the Path Computation Element Communication Protocol for 14 Enhanced Errors and Notifications 15 draft-ietf-pce-enhanced-errors-10 17 Abstract 19 This document defines new error and notification TLVs for the PCE 20 Communication Protocol (PCEP) specified in RFC5440, and will update 21 it. It identifies the possible PCEP behaviors in case of error or 22 notification. Thus, this draft defines types of errors and how they 23 are disclosed to other PCEs in order to support predefined PCEP 24 behaviors. 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 https://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 1 March 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . 4 64 3.1.2. Notification use-case . . . . . . . . . . . . . . . . 4 65 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . 5 67 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . 6 68 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . 6 69 5. PCEP Extensions for Error and Notification Handling . . . . . 7 70 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . 7 72 5.3. Behaviors and TLV combinations . . . . . . . . . . . . . 8 73 5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . 9 74 5.4.1. Time-To-Live (TTL) TLV . . . . . . . . . . . . . . . 9 75 5.4.2. DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . 9 76 5.4.3. Rules Applied to Existing Errors and Notifications . 11 77 6. Error Handling Guidelines for Future PCEP Extension . . . . . 15 78 7. Backward Compatibility Consideration . . . . . . . . . . . . 15 79 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 16 83 10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . 17 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 11.2. Informational References . . . . . . . . . . . . . . . . 19 87 Appendix A. Error and Notification Scenarios . . . . . . . . . . 20 88 A.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . 20 89 A.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . 21 90 A.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . 21 91 A.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Terminology 96 PCE terminology is defined in [RFC4655]. 98 PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a 99 PCE). 101 Source PCC: the PCC, for a given path computation query, initiating 102 the first PCEP request, which may then trigger a chain of successive 103 requests. 105 Target PCE: the PCE that can compute a path to the destination 106 without having to query any other PCE. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Introduction 116 The PCE Communication Protocol [RFC5440] is designed to be flexible 117 and extensible in order to allow future evolutions or specific 118 constraint support such as proposed in [RFC7470]. Crossing different 119 PCE implementations (e.g. from different providers or due to 120 different releases), a PCEP request may encounter unknown errors or 121 notification messages. In such a case, the PCEP RFC [RFC5440] 122 specifies to send a specific error code to the PCEP peer. This 123 document updates [RFC5440] by introducing mechanism to propagate the 124 error message, with specifying error and notification TLVs. 126 In the context of path computation crossing different routing domains 127 or autonomous systems, the number of different PCE system 128 specificities is potentially high, thus possibly leading to divergent 129 and unstable situations. Such phenomenon can also occur in 130 homogeneous cases since PCE systems have their own policies that can 131 introduce differences in requests treatment even for requests having 132 the same destination. In order to generalize PCEP behaviors in the 133 case of heterogeneous PCE systems, new objects have to be defined. 134 Dealing with heterogeneity is a major challenge considering PCE 135 applicability, particularly in multi-layer, multi-domain and H-PCE 136 contexts [RFC8751]. Thus, extending such error codes and PCEP 137 behaviors accordingly would improve interoperability among different 138 PCEP implementations and would solve some of these issues. However, 139 some of them would still remain (e.g. the divergences in request 140 treatment introduced by different policies). 142 The purpose of this draft is to identify and specify new optional 143 TLVs and objects in order to generalize PCEP behaviors. 145 3.1. Examples 147 The two following scenarios underline the need for a normalization of 148 the PCEP behaviors according to existing error or notification types. 150 3.1.1. Error use-case 152 PCE(i-1) has sent a request to PCE(i) which has also sent a request 153 to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but 154 not PCE(i). If PCE(i+1) throws an error type and value unknown by 155 PCE(i). PCE(i) could then adopt any other behaviors and sends back 156 to PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown 157 Object) or 4 (Not supported Object) for instance. As a consequence, 158 the path request would be cancelled but the error has no meaning for 159 PCE(i-1) whereas if PCE(i) had simply forwarded the error sent by 160 PCE(i+1), it would have been understood by PCE(i-1). 162 3.1.2. Notification use-case 164 PCE(i-1) has sent a request to PCE(i) which has also sent a request 165 to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1) 166 should send a notification of type 2 and a value flag giving its 167 estimated congestion duration. PCE(i) can choose to stop the path 168 computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1) 169 ignores the congestion duration on PCE(i+1) and could seek it for 170 further requests. 172 4. PCEP Behaviors 174 One of the purposes of the PCE architecture is to compute paths 175 across networks, but an added value is to compute such paths in 176 inter-area/layer/domain environments. The PCE Communication Protocol 177 [RFC5440] is based on the Transport Communication Protocol (TCP). 178 Thus, to compute a path within the PCE architecture, several TCP/PCEP 179 sessions have to be set up, in a peer-to-peer manner, along a set of 180 identified PCEs. 182 When the PCEP session is up for two PCEP peers, the PCC of the first 183 PCE System (the source PCC) sends a PCReq message. If the PCC does 184 not receive any reply before the dead timer is out, then it goes back 185 to the idle state. A PCC can expect two kinds of replies: a PCRep 186 message containing one or more valid paths (EROs) or a negative PCRep 187 message containing a NO-PATH object. 189 Beside PCReq and PCRep messages, notification and error messages, 190 named respectively PCNtf and PCErr, can be sent. There are two types 191 of notification messages: type 1 is for cancelling pending requests 192 and type 2 for signaling a congestion of the PCE. Several error 193 values are described in [RFC5440]. The error types concerning the 194 session phase begin at 2, error type 1 values are dedicated to the 195 initialization phase. 197 As the PCE Communication Protocol is built to work in a peer-to-peer 198 manner (i.e. supported by a TCP Connection), it supposes that the 199 "deadtimer" of the source PCC is long enough to support the end-to- 200 end distributed path computation process. 202 The exchange of messages in the PCE Communication Protocol is 203 described in details when PCEP is in states OpenWait and KeepWait in 204 [RFC5440]. When the session is up, message exchange is defined in 205 [RFC5440]. [RFC5441] describes the Backward Recursive Path 206 Computation (BRPC) procedure, and, because it considers an inter- 207 domain path computation, gives a bigger picture of the possible 208 behaviors when the session is up. Detailed behavior is mostly let 209 free to any specific implementation. The following sections 210 identifies the PCEP behaviors in case of error or notification and 211 also introduce the requirement of PCEP peer identification in both 212 cases. 214 4.1. PCEP Behaviors in Case of Error 216 [RFC5440] specifies that "a PCEP Error message is sent in several 217 situations: when a protocol error condition is met or the request is 218 not compliant with the PCEP specification". On this basis, and 219 according to the other RFCs, the identified PCEP behaviors are the 220 followings: 222 * "Propagation": the received message requires to be propagated 223 forwardly or backwardly (depending on which PCEP peer has sent the 224 message) to a set of PCEP peers; 226 * "Criticality level": in different RFCs, error-types affects the 227 state of the PCEP request or session in different manners; hence, 228 different level of criticality can be observed: 230 - Low-level of criticality: the received message does not affect 231 the PCEP connection and further answer can still be expected; 233 - Medium-level of criticality: the received message does not 234 affect the PCEP connection but the request(s) is(are) 235 cancelled; 237 - High-level of criticality: the received message indicates that 238 the PCEP peer will close the session with its peer (and so 239 pending requests associated by the error, if any, are 240 cancelled.) 242 The high-level of criticality has been extracted from [RFC5440] which 243 associates such a behavior to error-type of 1 (errors raised during 244 the PCEP session establishment). Hence, such errors are quite 245 specific. For the sake of completeness, they have been included in 246 this document. 248 4.2. PCEP Behaviors in Case of Notification 250 Notification messages can be employed in two different manners: 251 during the treatment of a PCEP request, or independently from it to 252 advertise information (in [RFC5440], the request ID list within a 253 PCNtf message is optional). Hence, three different types of 254 behaviors can be identified: 256 * "Local": the notification does not imply any forward or backward 257 propagation of the message; 259 * "Request-specific propagation": the received message requires to 260 be propagated forwardly or backwardly (depending on which peer has 261 sent the message) to the PCEP peers; 263 * "Non request-specific propagation": the received message must be 264 propagated to any known peers (e.g. if PCE discovery is activated) 265 or to a list of identified peers. 267 4.3. PCE Peer Identification 269 The propagation of errors and notifications affects the state of the 270 PCEP peers along the chain. In some cases, for instance a 271 notification that a PCE is overloaded, the identification of the PCEP 272 peer - or that the sender PCE is not the direct neighbor - might be 273 an important information for the PCEP peers receiving the message. 274 The ID of sender PCE is not carried in the error TLVs, but can be 275 achieved via the speaker entity ID TLV during state synchronization. 276 An example can be found in [RFC8232]. 278 5. PCEP Extensions for Error and Notification Handling 280 This section describes extensions to support error and notification 281 with respect to the PCEP behavior description defined in Section 4. 282 This document does not intend to modify errors and notification types 283 previously defined in existing documents (e.g. [RFC5440], [RFC5441], 284 etc.). Error related TLVs have been specified in this section, while 285 the notification functionality can be achieved via using PCNtf 286 message with RP object with no need to extend further notification 287 type. 289 5.1. Propagation TLV 291 To support the propagation behavior mentioned in Section 4.1 and 292 Section 4.2, a new optional TLV is defined, which can be carried in 293 PCEP-ERROR and NOTIFICATION objects, to indicate whether a message 294 has to be propagateed or not. The allocation from the "PCEP TLV Type 295 Indicators" sub-registry will be assigned by IANA and the request is 296 documented in Section 10. 298 The description is "Propagation", the length value is 2 bytes and the 299 value field is 1 byte. The value field is set to 0 meaning that the 300 message MUST NOT be propagated. If the value field is set to 1, the 301 message MUST be propagated. Section 5.4 specifies the destination 302 and to limit the number of messages. 304 5.2. Error-criticality TLV 306 To support the shutdown behavior mentioned in Section 4.1, we extend 307 the PCEP-ERROR object by creating a new optional TLV to indicate 308 whether an error is recoverable or not. The allocation from the 309 "PCEP TLV Type Indicators" sub-registry will be assigned by IANA and 310 the request is documented in Section 10. 312 The description is "Error-criticality", the length value is 2 bytes 313 and the value field is 1 byte. The value field is set to 0 meaning 314 that the error has a low-level of criticality (so further messages 315 can be expected for this request). If the value field is set to 1, 316 the error has a medium-level of criticality and requests whose 317 identifiers appear in the same message MUST be cancelled (so no 318 further messages can be expected for these requests). If the value 319 field is set to 2, the error has a high-level of criticality, the 320 connection for this PCEP session is closed by the sender PCE peer. 322 5.3. Behaviors and TLV combinations 324 The propagation behavior MAY be combined with all criticality levels, 325 thus leading to 6 different behaviors. In the case of a criticality 326 level of 2, the session is closed by the PCE peer which sends the 327 message. Hence, the criticality level is purely informative for the 328 PCE peer which receives the message. If it is combined with a 329 propagation behavior, then the PCE propagating the message MUST 330 indicate the same level of criticality if it closes the session. 331 Otherwise, it MUST use a criticality level of 1 if it does not close 332 the session. 334 For a PCErr message, all the possible behaviors described in 335 Section 4.1 can be covered with TLVs included in a PCEP-ERROR object. 336 The following table captures all combinations of error behaviors: 338 | Error \Propogation| 0 | 1 | 339 | criticallity\ Value | ( No |(Propogation | 340 | value \ | Propagation) | Required) | 341 |------------------------------------------------------| 342 | 0 (low) | Type 1 | Type 4 | 343 | 1 (medium) | Type 2 | Type 5 | 344 | 2 (high) | Type 3 | Type 6 | 345 |------------------------------------------------------| 347 * "Error Behavior Type 1" : Local Error with a low level of 348 criticality; 350 * "Error Behavior Type 2": Local Error with a medium level of 351 criticality; 353 * "Error Behavior Type 3": Local Error with a high level of 354 criticality; 356 * "Error Behavior Type 4": Propagated Error with a low level of 357 criticality; 359 * "Error Behavior Type 5": Propagated Error with a medium level of 360 criticality; 362 * "Error Behavior Type 6": Propagated Error with a high level of 363 criticality; 365 5.4. Propagation Restrictions TLVs 367 In order to limit the propagation of errors and notifications, the 368 following mechanisms SHOULD be used: 370 A Time-To-Live(TTL) RLV: to limit the number of PCEP peers that 371 will recursively receive the message; 373 A DIFFUSION-LIST TLV: to specify the PCEP peer addresses or 374 domains of PCEP peers the message must be propagate to; 376 History mechanism: if a PCEP peer keeps track of the messages it 377 has relayed, it could avoid propagating an error or notification 378 it has already received. 380 Such mechanisms SHOULD be used jointly or independently depending the 381 error or notification behaviors they are associated to. The 382 conditions of use for the TTL and DIFFUSION-LIST TLVs are described 383 in sections below. 385 5.4.1. Time-To-Live (TTL) TLV 387 The TTL value is set to any integer value to indicate the number of 388 PCEP peers that will recursively receive the message. The TTL TLV 389 SHOULD be used with propagated errors or notifications ("Propagation" 390 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP 391 peer MUST decrement the TTL value before propagating the message. 392 When the TTL value becomes 0, the message is no more propagated. 394 If the message to be propagated is request-specific and there is no 395 TTL or DIFFUSION-LIST TLVs included, the message MUST reach the 396 source PCC (or alternatively the target PCE). 398 5.4.2. DIFFUSION-LIST TLV 400 The DIFFUSION-LIST TLV can be carried within either the error object 401 of a PCErr message, or the notification object of a PCNtf message. 402 It can either be used in a message sent by a PCC to a PCE or vice 403 versa. The DIFFUSION-LIST MAY be used with propagated errors (TLV 404 "Propagation"at value 1 in PCEP-ERROR object). 406 The format of the DIFFUSION-LIST object body is as follows: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 // (Sub-objects) // 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Type (16 bits): restricts the diffusion to certain peers. The 419 following values are currently defined: 421 0: Any PCEP peer indicated in the list must be reached. 423 1: Only PCEs must be reached (and not PCC). 425 2: All PCEP peers with which a session is still opened must be 426 reached. 428 The value of DIFFUSION-LIST is made of sub-objects similar to the IRO 429 defined in [RFC5440]. The following sub-object types are supported. 431 Type Sub-object 433 1 IPv4 address 434 2 IPv6 address 435 4 Unnumbered Interface ID 436 5 4-byte AS number 437 6 OSPF area ID 438 7 IS-IS Area ID 439 32 Autonomous System number 440 33 Explicit eXclusion Route Sub-object (EXRS) 442 If the error or notification codes target specific PCEP peers, a 443 DIFFUSION-LIST TLV avoids partially flooding all PCEP peers. Any 444 PCEP peer receiving a PCErr or PCNTf message containing a PCEP-ERROR 445 or a NOTIFICATION object with a TLV "Propagation" at value 1 and 446 where a DIFFUSION-LIST appears, MUST remove the addresses of the PCEP 447 peers from the DIFFUSION-LIST, before sending the message to any 448 other PCEP peers. This is performed by adding the PCEP peer 449 addresses to the Explicit eXclusion Route Sub-object of the 450 DIFFUSION-LIST. If a DIFFUSION-LIST value is empty, the PCEP peer 451 MUST NOT propagate the message to any peer. 453 Note that, a Diffusion-List could contain strict or loose addresses 454 to refer to a network domain (e.g. an Autonomous System number, an 455 OSPF area, an IP address). Hence, the PCEP peers targeted by the 456 message would be the PCEP peers covering the corresponding domain. 457 If an address is loose, each time a PCEP peer forwards a message to 458 another PCEP peer of this address, it MUST add it own address to the 459 Explicit eXclusion Route Sub-object (EXRS) of the Diffusion-List for 460 any forwarded messages. Hence, a PCE SHOULD avoid forwarding the 461 same message repeated to the same set of peers. Finally, when an 462 address is loose, the forwarding SHOULD be restrained indicating what 463 type of PCEP peers are targeted (i.e. PCE and/or PCC). 465 5.4.3. Rules Applied to Existing Errors and Notifications 467 Many existing normative references states on error definitions (see 468 for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], 469 [RFC5886], [RFC8231], [RFC8232],[RFC8253], [RFC8281], [RFC8306], 470 [RFC8408], [RFC8697]). This section provides processing rules for 471 existing error types handling, as a recommendation. According to the 472 definitions provided in this document, the follwoing rules are 473 applicable: 475 Error-type 1, described in [RFC5440], relates to PCEP session 476 establishement failures. All errors of this type are local and 477 not propagated. Hence, if a "Propagation" TLV is added to the 478 error message it is recommended to be set to value 0. Error- 479 values 1,2,6,7 have a high level of criticality. Hence, if the 480 "Error-criticality" TLV is included within a PCErr message of type 481 1 and value 1,2,6 or 7, it is recommended to have a value of 2. 483 Error-type 2,3,4, "Capability not supported", "Unknown object" and 484 "Not supported object" respectively, described in [RFC5440]: 485 errors of this type MAY be propagated using the TLV "Propagation". 486 Their level of criticality is defined as leading to cancel the 487 path computation request [RFC5440]. Hence, if the "Error- 488 criticality" TLV is included, it usually have a value of 1. The 489 error-value 4 of error-type 4 ("Unsupported parameter") associated 490 to the BRPC procedure [RFC5441] is suggested to contain the 491 "Propagation" TLV with a DIFFUSION-LIST requesting a propagation 492 to the PCC at the origin of the request. 494 Error-type 5 refers to "Policy violation", error values for this 495 type have been defined in [RFC5440], [RFC5541], [RFC5557], 496 [RFC5886] and [RFC8306]. In [RFC5440], it is specified that the 497 path computation request MUST be cancelled when an error of type 5 498 occurs. Hence, if the "Error-criticality" TLV is included, it 499 usually have a value of 1. As such errors might be conveyed to 500 several PCEs, the "Propagation" TLV MAY be used. 502 Error-type 6 described as "Mandatory object missing" in [RFC5440], 503 leads to the cancellation of the path computation request. Hence, 504 if the "Error-criticality" TLV is included, it usually have a 505 value of 1. The "Propagation" TLV MAY be used with such errors. 506 The error-value of 4 for Monitoring object missing defined in 507 [RFC5886] is no exception to the rule. 509 Error-type 7 is described as "synchronized path computation 510 request missing". In [RFC5440], it is specified that the reffered 511 synchronized path computation request MUST be cancelled when an 512 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 513 included, it usually have a value of 1. The "Propagation" TLV MAY 514 be used with such errors. 516 Error-type 8 is raised when a PCE receives a PCRep with an unknown 517 request reference. If the "Propagation" TLV is used with error- 518 type 8, it is recommended to be set at a value of 0. The "Error- 519 criticality" TLV is not particularly relevant for error-type 8. 520 Hence, it usually have the value of 0 if used. 522 Error-type 9 is raised when a PCE attempts to establish a second 523 PCEP session. The existing session must be preserved. Hence, if 524 the "Error-criticality" TLV is included, it usually have a value 525 of 0. By definition, such an error message SHOULD NOT be 526 propagated. Thus, if the "Propagation" TLV is used with error- 527 type 9, it is usually set to a value of 0. 529 Error-type 10 which refers to the reception of an invalid object 530 as described in [RFC5440] no indication is provided on the 531 cancellation of the path computation request. Hence, if the 532 "Error-criticality" TLV is included, it usually have a value of 0. 533 The "Propagation" TLV MAY be used with such errors with any value 534 depending on the expected behavior. 536 Error-type 11 relates to "Unrecognized EXRS subobject" and is 537 described in [RFC5521]. No path computation request cancellation 538 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 539 is included, it usually have a value of 0. The "Propagation" TLV 540 MAY be used with such errors with any value depending on the 541 expected behavior. 543 Error-type 12 refers to "Diffserv-aware TE error" and is described 544 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 545 a PCReq is recognized but not supported by a PCE. [RFC5455] does 546 not state about the path computation request when such errors are 547 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 548 be used within such error-types' messages and set to any specified 549 values. 551 Error-type 13 on "BRPC procedure completion failure" is described 552 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 553 message MUST be relayed to the PCC. Hence, such messages SHOULD 554 contain a "Propagation" TLV and a DIFFUSION-LIST with a Target- 555 Type of 0 and corresponding addresses or with a Target-Type of 2. 556 It is not specified in [RFC5441] whether the path computation 557 request should be canceled or not. If the procedure is not 558 supported, it does not necessarily imply to cancel the path 559 computation request if another procedure is able to read and write 560 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 561 any value depending on the expected behavior. 563 Error-type 15 refers to "Global Concurrent Optimization Error" 564 defined in [RFC5557]. [RFC5557] states that the corresponding 565 global concurrent path optimization MUST be cancelled at the PCC. 566 Hence, if the "Error-criticality" TLV is included, it usually have 567 a value of 1. The "Propagation" TLV MAY be used with such errors. 569 Error-type 16 relates to "P2MP Capability Error" defined in 570 [RFC8306]. Such errors lead to the cancellation of the path 571 computation request. Hence, if the "Error-criticality" TLV is 572 included, it usually have a value of 1. The "Propagation" TLV MAY 573 be used with such errors. 575 Error-type 17, titled "P2MP END-POINTS Error" is defined 576 [RFC8306]. Such errors are thrown when a PCE tries to add or 577 prune nodes to or from a P2MP Tree. [RFC8306] does not specify if 578 such errors lead to cancel the path computation request. Hence, 579 the "Error-criticality" and "Propagation" TLVs MAY be used with 580 this type of error with any value depending on the expected 581 behavior. 583 Error-type 18 of "P2MP Fragmentation Error" is described [RFC8306] 584 which does not specify whether the path computation request should 585 be cancelled. But, as messages are fragmented, it is natural to 586 think that the PCE should wait at least a bit for further 587 messages. The "Error-criticality" TLV MAY be included in such 588 error messages and is particularly adapted to differ the semantic 589 of the same error-type message: if it is included with a value of 590 0 then the PCE will still wait for further fragmented messages, 591 when this waiting time ends, the TLV can be included with a value 592 of 1 in order to finally cancel the request. The "Propagation" 593 TLV MAY also be used with such errors. 595 Error-type 19 of "Invalid Operation" is described in [RFC8231] and 596 [RFC8281], which implies a wrong capability description for PCEP 597 session. In this case, the PCErr message MUST be returned to PCC, 598 and this message usually contain a "Propagation" TLV and a 599 DIFFUSION-LIST with a Target-Type of 0 or 2. The "Error- 600 criticality" TLV is recommended be set to 2 in order to guanrantee 601 the termination of PCEP session. 603 Error-type 20 of "LSP State Synchronization Error" is described in 604 [RFC8231] and [RFC8232], which cannot successfully sync up the LSP 605 states. In this case, the "Error-criticality" TLV should be set 606 to 2 in order to guanrantee the termination of PCEP session. The 607 "Propagation" TLV MAY also be used with such errors. 609 Error-type 21 of "Invalid traffic engineering path setup type" is 610 described in [RFC8408] . Such errors failed to find a matched path 611 setup type and the PCEP sessions MUST be closed. In this case, 612 the "Error-criticality" TLV is usually set to 2 in order to 613 guanrantee the termination of PCEP session. The "Propagation" TLV 614 MAY also be used with such errors. 616 Error-type 23 of "Bad parameter value" is described in [RFC8281] . 617 Such errors occur when there is a conflict in path name of C flag 618 not set for PCE initiation. In this case, the "Error-criticality" 619 TLV may be set to either 0 or 1 to indicate whether the request is 620 still valid, with the PCEP session open. The "Propagation" TLV 621 MAY also be used with such errors. 623 Error-type 24 of "LSP instantiation error" is described in 624 [RFC8281] . Such errors occur when PCC detects problems when 625 establishing the path, the message MUST relay to the PCE, 626 therefore the "Propogation" TLV is usually contained. The "Error- 627 criticality" TLV may be set to either 0 or 1 to indicate whether 628 the request is still valid, with the PCEP session open. 630 Error-type 25 of "PCEP StartTLS failure" is described in 631 [RFC8253]. Such errors indicate the security issue in transport 632 layer. In this case, the "Error-criticality" TLV is usually set 633 to 2 in order to close the PCEP session. The "Propagation" TLV 634 MAY also be used with such errors, depending on the detailed 635 security conditions. 637 Error-type 26 of "Association Error " is described in [RFC8697] . 638 Such errors occur when there is problem for LSP association. In 639 this case, the "Error-criticality" TLV should be set to either 0 640 or 1 to indicate whether the request is still valid, with the PCEP 641 session open. The "Propagation" TLV MAY also be used with such 642 errors. 644 6. Error Handling Guidelines for Future PCEP Extension 646 Error and Notification handling in this document should be considered 647 in PCE documents that include new errors and notifications. A 648 requirement for the authors of these drafts is to evaluate the 649 applicability of the procedure in this document and provide details 650 about the "Error-criticality" TLV and "Propagation" TLV for errors 651 and notifications defined in the draft. Example text is provided as 652 follow. 654 Error-type XX (fill in value of the Error-type) of " XXXX " (fill in 655 name of the Error-type) is described in [RFCYYYY] (fill in the 656 document reference of the Error-type). Such errors occur when ZZZZ 657 (fill in typical scenario). In this case, the "Error-criticality" 658 TLV should be set to X (fill in the recommended value) to indicate 659 whether the request is still valid, with the PCEP session open. The 660 error messages SHOULD/MAY (select the mandatory level) contain a 661 "Propagation" TLV and a DIFFUSION-LIST with a Target-Type of A(fill 662 in the recommended value). 664 7. Backward Compatibility Consideration 666 There would be backward compatibility issue if there are multiple 667 PCEs with different level understanding of error message. In a 668 scenario that PCE(i) propagate the error message to PCE (i+1), it is 669 possible that PCE (i+1) is not capable to extract the message 670 correctly, then such error message would be ignored and not be 671 further propagated. 673 There can be potential approach to avoid these problem, such as 674 recognizing the incapable PCE and avoiding propagation. However, 675 these approach is not in the scope of this document. 677 8. Implementation Status 679 [NOTE TO RFC EDITOR : This whole section and the reference to 680 [RFC7942] is to be removed before publication as an RFC] 681 This section records the status of known implementations of the 682 protocol defined by this specification at the time of posting of this 683 Internet-Draft, and is based on a proposal described in [RFC7942]. 684 The description of implementations in this section is intended to 685 assist the IETF in its decision processes in progressing drafts to 686 RFCs. Please note that the listing of any individual implementation 687 here does not imply endorsement by the IETF. Furthermore, no effort 688 has been spent to verify the information presented here that was 689 supplied by IETF contributors. This is not intended as, and must not 690 be construed to be, a catalog of available implementations or their 691 features. Readers are advised to note that other implementations may 692 exist. 694 According to [RFC7942], "this will allow reviewers and working groups 695 to assign due consideration to documents that have the benefit of 696 running code, which may serve as evidence of valuable experimentation 697 and feedback that have made the implemented protocols more mature. 698 It is up to the individual working groups to use this information as 699 they see fit". 701 At the time of posting the -08 version of this document, there are no 702 known implementations of this mechanism. It is believed that two 703 vendors are considering prototype implementations, but these plans 704 are too vague to make any further assertions. 706 9. Security Considerations 708 Within the introduced set of TLVs, the "Propagation" TLV affects PCEP 709 security considerations since it forces propagation behaviors. Thus, 710 a PCEP implementation SHOULD activate stateful mechanism when 711 receiving PCEP-ERROR or NOTIFICATION object including this TLV in 712 order to avoid DoS attacks. 714 10. IANA Considerations 716 IANA maintains a registry of PCEP parameters. This includes a sub- 717 registry for PCEP Objects. 719 IANA is requested to make an allocation from the sub-registry as 720 follows. The values here are suggested for use by IANA. 722 10.1. PCEP TLV Type Indicators 724 As described in Section 5.4 the newly defined TLVs allows a PCE to 725 enforce specific error and notification behaviors within PCEP-ERROR 726 and NOTIFICATION objects. IANA is requested to make the following 727 allocations from the "PCEP TLV Type Indicators" sub-registry. 729 Value Description Reference 730 TBD Propagation this document 731 TBD Error-criticality this document 733 10.2. New DIFFUSION-LIST TLV 735 Type Value Meaning Reference 736 0 Any PCEP peers this document 738 1 PCEs but excludes 739 PCC-only peers this document 741 2 PCEs and PCCs this document 742 with which a session 743 is still opened 745 Subobjects Reference 746 1: IPv4 prefix this document 747 2: IPv6 prefix this document 748 4: Unnumbered Interface ID this document 749 5: 4-byte AS number this document 750 6 OSPF area ID this document 751 7 IS-IS Area ID this document 752 32: Autonomous system number this document 753 33: Explicit Exclusion Route subobject (EXRS) this document 755 11. References 757 11.1. Normative References 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, 761 DOI 10.17487/RFC2119, March 1997, 762 . 764 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 765 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 766 DOI 10.17487/RFC5440, March 2009, 767 . 769 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 770 "A Backward-Recursive PCE-Based Computation (BRPC) 771 Procedure to Compute Shortest Constrained Inter-Domain 772 Traffic Engineering Label Switched Paths", RFC 5441, 773 DOI 10.17487/RFC5441, April 2009, 774 . 776 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 777 Kumaki, "Diffserv-Aware Class-Type Object for the Path 778 Computation Element Communication Protocol", RFC 5455, 779 DOI 10.17487/RFC5455, March 2009, 780 . 782 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 783 Path Computation Element Communication Protocol (PCEP) for 784 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 785 2009, . 787 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 788 Objective Functions in the Path Computation Element 789 Communication Protocol (PCEP)", RFC 5541, 790 DOI 10.17487/RFC5541, June 2009, 791 . 793 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 794 Computation Element Communication Protocol (PCEP) 795 Requirements and Protocol Extensions in Support of Global 796 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 797 July 2009, . 799 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 800 Monitoring Tools for Path Computation Element (PCE)-Based 801 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 802 . 804 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 805 Computation Element Communication Protocol (PCEP) 806 Extensions for Stateful PCE", RFC 8231, 807 DOI 10.17487/RFC8231, September 2017, 808 . 810 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 811 and D. Dhody, "Optimizations of Label Switched Path State 812 Synchronization Procedures for a Stateful PCE", RFC 8232, 813 DOI 10.17487/RFC8232, September 2017, 814 . 816 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 817 "PCEPS: Usage of TLS to Provide a Secure Transport for the 818 Path Computation Element Communication Protocol (PCEP)", 819 RFC 8253, DOI 10.17487/RFC8253, October 2017, 820 . 822 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 823 Computation Element Communication Protocol (PCEP) 824 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 825 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 826 . 828 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 829 "Extensions to the Path Computation Element Communication 830 Protocol (PCEP) for Point-to-Multipoint Traffic 831 Engineering Label Switched Paths", RFC 8306, 832 DOI 10.17487/RFC8306, November 2017, 833 . 835 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 836 Hardwick, "Conveying Path Setup Type in PCE Communication 837 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 838 July 2018, . 840 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 841 Dhody, D., and Y. Tanaka, "Path Computation Element 842 Communication Protocol (PCEP) Extensions for Establishing 843 Relationships between Sets of Label Switched Paths 844 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 845 . 847 11.2. Informational References 849 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 850 Computation Element (PCE)-Based Architecture", RFC 4655, 851 DOI 10.17487/RFC4655, August 2006, 852 . 854 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 855 Constraints in the Path Computation Element Communication 856 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 857 . 859 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 860 Code: The Implementation Status Section", BCP 205, 861 RFC 7942, DOI 10.17487/RFC7942, July 2016, 862 . 864 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 865 "Hierarchical Stateful Path Computation Element (PCE)", 866 RFC 8751, DOI 10.17487/RFC8751, March 2020, 867 . 869 Appendix A. Error and Notification Scenarios 871 This section provides some examples depicting how the error described 872 above can be used in a PCEP session. The origin of the errors or 873 notifications is only illustrative and has no normative purpose. 874 Sometimes the PCE features behind may be implementation-specific 875 (e.g. detection of flooding). This section does not provide 876 scenarios for errors with a high-level of critcity (i.e., Error 877 behaviors 3 and 6) since such errors are very specific and until now 878 have been normalized only during the session establishment (error- 879 type of 1). 881 A.1. Error Behavior Type 1 883 In this example, a PCC attempts to establish a second PCEP session 884 with the same PCE for another request. Consequently the PCE sends 885 back an error message with error-type 9. This error stays local and 886 does not affect the former session. The second session is ignored. 887 If the "Propagation" TLV and "Error-criticality" TLV are used, they 888 should be both set to value 0. 890 +-+-+ +-+-+ 891 |PCC| |PCE| 892 +-+-+ +-+-+ 893 1) Path computation | | 894 event | | 895 2) PCE selection |----- Open Message--->| 896 |<--- Open message ----| 897 3) Path computation |---- PCReq message--->| 898 request X sent to | |4) Path computation 899 the selected PCE | | request queued 900 | | 901 5) Path computation | | 902 event | | 903 6) PCE selection | | 904 |----- Open Message--->|8) Session already 905 | |opened 906 |<--- PCErr message----| Error-type=9 907 | | 909 A.2. Error Behavior Type 2 911 In this example, the PCC sends a DiffServ-aware path computation 912 request. If the PCE receiving the request does not support the 913 indicated class-type, it thus sends back a PCErr message with error- 914 type=12 and error-value=1. If the "Propagation" TLV and "Error- 915 criticality" TLV are present, they should carry value 0 and value 1 916 respectively. Consequently, the request is cancelled. 918 +-+-+ +-+-+ 919 |PCC| |PCE| 920 +-+-+ +-+-+ 921 1) Path computation | | 922 event | | 923 2) PCE selection | | 924 3) Path computation |---- PCReq message--->| 925 request X sent to | |4) Path computation 926 the selected PCE | | request queued 927 | | 928 | |5) DiffServ class-type 929 | | not supported 930 | |6) Path computation 931 | | request X 932 | | cancelled 933 |<--- PCErr message----| Error-type=12 934 | | 936 A.3. Error Behavior Type 4 938 In this example, a PCC sends a path computation requests with no P 939 flag set (e.g. END-POINT object with P-flag cleared). This is 940 detected by another PCE in the sequence. The path computation 941 request can thus be treated but the P-Flag will be ignored. Hence, 942 this error is not critical but the source PCC should be informed of 943 this fact. So, a PCErr message with error-type 10 ("Reception of an 944 invalid object"). The PCEP-ERROR object of the message contains a 945 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 946 0. It is hence propagated backwardly to the source PCC. 948 +-+-+ +-+-+-+-+ +-+-+ 949 |PCC| |PCE|PCC| |PCE| 950 +-+-+ +-+-+-+-+ +-+-+ 951 |---- PCReq message-->| | 952 | | | 953 | |---- PCReq message--->| 954 | | | 955 | | |1) Parameter is 956 | | | not supported 957 | | | 958 | |<--- PCErr message----| Error-type=10 959 |<--- PCErr message---| | 960 | | | 962 A.4. Error Behavior Type 5 964 In this example, PCEs are using the BRPC procedure to treat a path 965 computation request [RFC5441]. However, one of the PCEs does not 966 support a parameter of the request. Hence, a PCErr message with 967 error-type 4 and error-value 4 is sent by this PCE and has to be 968 forwarded to the source PCC. The PCEP-ERROR object includes a 969 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 970 and the message is propagated backwardly to the source PCC. 971 Consequently, the request is cancelled. 973 +-+-+ +-+-+-+-+ +-+-+ 974 |PCC| |PCE|PCC| |PCE| 975 +-+-+ +-+-+-+-+ +-+-+ 976 |---- PCReq message-->| | 977 | | | 978 | |---- PCReq message--->| 979 | | | 980 | | |1) Unsupported 981 | | | Parameter BRPC 982 | | |2) Path 983 | | | computation 984 | | | request X 985 | | | cancelled 986 | |<--- PCErr message----| Error-type=4 987 |<--- PCErr message---| | 988 | | | 990 Authors' Addresses 991 Helia Pouyllau 992 Alcatel-Lucent 993 Route de Villejust 994 91620 NOZAY 995 France 997 Phone: + 33 (0)1 30 77 63 11 998 Email: helia.pouyllau@alcatel-lucent.com 1000 Remi Theillaud 1001 Marben Products 1002 176 rue Jean Jaures 1003 92800 Puteaux 1004 France 1006 Phone: + 33 (0)1 79 62 10 22 1007 Email: remi.theillaud@marben-products.com 1009 Julien Meuric 1010 Orange 1011 2, avenue Pierre Marzin 1012 22307 Lannion 1013 France 1015 Email: julien.meuric@orange.com 1017 Haomian Zheng (Editor) 1018 Huawei Technologies 1019 H1, Xiliu Beipo Village, Songshan Lake, 1020 Dongguan 1021 Guangdong, 523808 1022 China 1024 Email: zhenghaomian@huawei.com 1026 Xian Zhang 1027 Huawei Technologies 1028 A10, Huawei Industrial Base, Bantian, Longgang District 1029 Shenzhen 1031 Email: zhang.xian@huawei.com