idnits 2.17.1 draft-ietf-pce-enhanced-errors-09.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 (February 18, 2021) is 1157 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 654, 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. Pouyllau 3 Internet-Draft Alcatel-Lucent 4 Updates: 5440 (if approved) R. Theillaud 5 Intended status: Standards Track Marben Products 6 Expires: August 22, 2021 J. Meuric 7 Orange 8 H. Zheng (Editor) 9 X. Zhang 10 Huawei Technologies 11 February 18, 2021 13 Extensions to the Path Computation Element Communication Protocol for 14 Enhanced Errors and Notifications 15 draft-ietf-pce-enhanced-errors-09 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 August 22, 2021. 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 50 (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4 66 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5 68 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 69 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 70 5. PCEP Extensions for Error and Notification Handling . . . . . 6 71 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 73 5.3. Behaviors and TLV combinations . . . . . . . . . . . . . . 7 74 5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . . 8 75 5.4.1. Time-To-Live (TTL) TLV . . . . . . . . . . . . . . . . . 9 76 5.4.2. DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . . 9 77 5.4.3. Rules Applied to Existing Errors and Notifications . . . 10 78 6. Error Handling Guidelines for Future PCEP Extension . . . . . 14 79 7. Backward Compatibility Consideration . . . . . . . . . . . . 15 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 16 84 10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . 16 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 11.2. Informational References . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Terminology 92 PCE terminology is defined in [RFC4655]. 94 PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a 95 PCE). 97 Source PCC: the PCC, for a given path computation query, initiating 98 the first PCEP request, which may then trigger a chain of successive 99 requests. 101 Target PCE: the PCE that can compute a path to the destination 102 without having to query any other PCE. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Introduction 112 The PCE Communication Protocol [RFC5440] is designed to be flexible 113 and extensible in order to allow future evolutions or specific 114 constraint support such as proposed in [RFC7470]. Crossing different 115 PCE implementations (e.g. from different providers or due to 116 different releases), a PCEP request may encounter unknown errors or 117 notification messages. In such a case, the PCEP RFC [RFC5440] 118 specifies to send a specific error code to the PCEP peer. This 119 document updates [RFC5440] by introducing mechanism to propagate the 120 error message, with specifying error and notification TLVs. 122 In the context of path computation crossing different routing domains 123 or autonomous systems, the number of different PCE system 124 specificities is potentially high, thus possibly leading to divergent 125 and unstable situations. Such phenomenon can also occur in 126 homogeneous cases since PCE systems have their own policies that can 127 introduce differences in requests treatment even for requests having 128 the same destination. In order to generalize PCEP behaviors in the 129 case of heterogeneous PCE systems, new objects have to be defined. 130 Dealing with heterogeneity is a major challenge considering PCE 131 applicability, particularly in multi-layer, multi-domain and H-PCE 132 contexts [RFC8751]. Thus, extending such error codes and PCEP 133 behaviors accordingly would improve interoperability among different 134 PCEP implementations and would solve some of these issues. However, 135 some of them would still remain (e.g. the divergences in request 136 treatment introduced by different policies). 138 The purpose of this draft is to identify and specify new optional 139 TLVs and objects in order to generalize PCEP behaviors. 141 3.1. Examples 143 The two following scenarios underline the need for a normalization of 144 the PCEP behaviors according to existing error or notification types. 146 3.1.1. Error use-case 148 PCE(i-1) has sent a request to PCE(i) which has also sent a request 149 to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but 150 not PCE(i). If PCE(i+1) throws an error type and value unknown by 151 PCE(i). PCE(i) could then adopt any other behaviors and sends back 152 to PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown 153 Object) or 4 (Not supported Object) for instance. As a consequence, 154 the path request would be cancelled but the error has no meaning for 155 PCE(i-1) whereas if PCE(i) had simply forwarded the error sent by 156 PCE(i+1), it would have been understood by PCE(i-1). 158 3.1.2. Notification use-case 160 PCE(i-1) has sent a request to PCE(i) which has also sent a request 161 to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1) 162 should send a notification of type 2 and a value flag giving its 163 estimated congestion duration. PCE(i) can choose to stop the path 164 computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1) 165 ignores the congestion duration on PCE(i+1) and could seek it for 166 further requests. 168 4. PCEP Behaviors 170 One of the purposes of the PCE architecture is to compute paths 171 across networks, but an added value is to compute such paths in 172 inter-area/layer/domain environments. The PCE Communication Protocol 173 [RFC5440] is based on the Transport Communication Protocol (TCP). 174 Thus, to compute a path within the PCE architecture, several TCP/PCEP 175 sessions have to be set up, in a peer-to-peer manner, along a set of 176 identified PCEs. 178 When the PCEP session is up for two PCEP peers, the PCC of the first 179 PCE System (the source PCC) sends a PCReq message. If the PCC does 180 not receive any reply before the dead timer is out, then it goes back 181 to the idle state. A PCC can expect two kinds of replies: a PCRep 182 message containing one or more valid paths (EROs) or a negative PCRep 183 message containing a NO-PATH object. 185 Beside PCReq and PCRep messages, notification and error messages, 186 named respectively PCNtf and PCErr, can be sent. There are two types 187 of notification messages: type 1 is for cancelling pending requests 188 and type 2 for signaling a congestion of the PCE. Several error 189 values are described in [RFC5440]. The error types concerning the 190 session phase begin at 2, error type 1 values are dedicated to the 191 initialization phase. 193 As the PCE Communication Protocol is built to work in a peer-to-peer 194 manner (i.e. supported by a TCP Connection), it supposes that the 195 "deadtimer" of the source PCC is long enough to support the end-to- 196 end distributed path computation process. 198 The exchange of messages in the PCE Communication Protocol is 199 described in details when PCEP is in states OpenWait and KeepWait in 200 [RFC5440]. When the session is up, message exchange is defined in 201 [RFC5440]. [RFC5441] describes the Backward Recursive Path 202 Computation (BRPC) procedure, and, because it considers an inter- 203 domain path computation, gives a bigger picture of the possible 204 behaviors when the session is up. Detailed behavior is mostly let 205 free to any specific implementation. The following sections 206 identifies the PCEP behaviors in case of error or notification and 207 also introduce the requirement of PCEP peer identification in both 208 cases. 210 4.1. PCEP Behaviors in Case of Error 212 [RFC5440] specifies that "a PCEP Error message is sent in several 213 situations: when a protocol error condition is met or the request is 214 not compliant with the PCEP specification". On this basis, and 215 according to the other RFCs, the identified PCEP behaviors are the 216 followings: 218 o "Propagation": the received message requires to be propagated 219 forwardly or backwardly (depending on which PCEP peer has sent the 220 message) to a set of PCEP peers; 222 o "Criticality level": in different RFCs, error-types affects the 223 state of the PCEP request or session in different manners; hence, 224 different level of criticality can be observed: 226 o 228 * Low-level of criticality: the received message does not affect 229 the PCEP connection and further answer can still be expected; 231 * Medium-level of criticality: the received message does not 232 affect the PCEP connection but the request(s) is(are) 233 cancelled; 235 * High-level of criticality: the received message indicates that 236 the PCEP peer will close the session with its peer (and so 237 pending requests associated by the error, if any, are 238 cancelled.) 240 The high-level of criticality has been extracted from [RFC5440] which 241 associates such a behavior to error-type of 1 (errors raised during 242 the PCEP session establishment). Hence, such errors are quite 243 specific. For the sake of completeness, they have been included in 244 this document. 246 4.2. PCEP Behaviors in Case of Notification 248 Notification messages can be employed in two different manners: 249 during the treatment of a PCEP request, or independently from it to 250 advertise information (in [RFC5440], the request ID list within a 251 PCNtf message is optional). Hence, three different types of 252 behaviors can be identified: 254 o "Local": the notification does not imply any forward or backward 255 propagation of the message; 257 o "Request-specific propagation": the received message requires to 258 be propagated forwardly or backwardly (depending on which peer has 259 sent the message) to the PCEP peers; 261 o "Non request-specific propagation": the received message must be 262 propagated to any known peers (e.g. if PCE discovery is activated) 263 or to a list of identified peers. 265 4.3. PCE Peer Identification 267 The propagation of errors and notifications affects the state of the 268 PCEP peers along the chain. In some cases, for instance a 269 notification that a PCE is overloaded, the identification of the PCEP 270 peer - or that the sender PCE is not the direct neighbor - might be 271 an important information for the PCEP peers receiving the message. 272 The ID of sender PCE is not carried in the error TLVs, but can be 273 achieved via the speaker entity ID TLV during state synchronization. 274 An example can be found in [RFC8232]. 276 5. PCEP Extensions for Error and Notification Handling 278 This section describes extensions to support error and notification 279 with respect to the PCEP behavior description defined in Section 4. 280 This document does not intend to modify errors and notification types 281 previously defined in existing documents (e.g. [RFC5440], [RFC5441], 282 etc.). Error related TLVs have been specified in this section, while 283 the notification functionality can be achieved via using PCNtf 284 message with RP object with no need to extend further notification 285 type. 287 5.1. Propagation TLV 289 To support the propagation behavior mentioned in Section 4.1 and 290 Section 4.2, a new optional TLV is defined, which can be carried in 291 PCEP-ERROR and NOTIFICATION objects, to indicate whether a message 292 has to be propagateed or not. The allocation from the "PCEP TLV Type 293 Indicators" sub-registry will be assigned by IANA and the request is 294 documented in Section 10. 296 The description is "Propagation", the length value is 2 bytes and the 297 value field is 1 byte. The value field is set to 0 meaning that the 298 message MUST NOT be propagated. If the value field is set to 1, the 299 message MUST be propagated. Section 5.4 specifies the destination 300 and to limit the number of messages. 302 5.2. Error-criticality TLV 304 To support the shutdown behavior mentioned in Section 4.1, we extend 305 the PCEP-ERROR object by creating a new optional TLV to indicate 306 whether an error is recoverable or not. The allocation from the 307 "PCEP TLV Type Indicators" sub-registry will be assigned by IANA and 308 the request is documented in Section 10. 310 The description is "Error-criticality", the length value is 2 bytes 311 and the value field is 1 byte. The value field is set to 0 meaning 312 that the error has a low-level of criticality (so further messages 313 can be expected for this request). If the value field is set to 1, 314 the error has a medium-level of criticality and requests whose 315 identifiers appear in the same message MUST be cancelled (so no 316 further messages can be expected for these requests). If the value 317 field is set to 2, the error has a high-level of criticality, the 318 connection for this PCEP session is closed by the sender PCE peer. 320 5.3. Behaviors and TLV combinations 322 The propagation behavior MAY be combined with all criticality levels, 323 thus leading to 6 different behaviors. In the case of a criticality 324 level of 2, the session is closed by the PCE peer which sends the 325 message. Hence, the criticality level is purely informative for the 326 PCE peer which receives the message. If it is combined with a 327 propagation behavior, then the PCE propagating the message MUST 328 indicate the same level of criticality if it closes the session. 329 Otherwise, it MUST use a criticality level of 1 if it does not close 330 the session. 332 For a PCErr message, all the possible behaviors described in 333 Section 4.1 can be covered with TLVs included in a PCEP-ERROR object. 334 The following table captures all combinations of error behaviors: 336 | Error \Propogation| 0 | 1 | 337 | criticallity\ Value | ( No |(Propogation | 338 | value \ | Propagation) | Required) | 339 |------------------------------------------------------| 340 | 0 (low) | Type 1 | Type 4 | 341 | 1 (medium) | Type 2 | Type 5 | 342 | 2 (high) | Type 3 | Type 6 | 343 |------------------------------------------------------| 345 o "Error Behavior Type 1" : Local Error with a low level of 346 criticality; 348 o "Error Behavior Type 2": Local Error with a medium level of 349 criticality; 351 o "Error Behavior Type 3": Local Error with a high level of 352 criticality; 354 o "Error Behavior Type 4": Propagated Error with a low level of 355 criticality; 357 o "Error Behavior Type 5": Propagated Error with a medium level of 358 criticality; 360 o "Error Behavior Type 6": Propagated Error with a high level of 361 criticality; 363 5.4. Propagation Restrictions TLVs 365 In order to limit the propagation of errors and notifications, the 366 following mechanisms SHOULD be used: 368 A Time-To-Live(TTL) RLV: to limit the number of PCEP peers that 369 will recursively receive the message; 371 A DIFFUSION-LIST TLV: to specify the PCEP peer addresses or 372 domains of PCEP peers the message must be propagate to; 374 History mechanism: if a PCEP peer keeps track of the messages it 375 has relayed, it could avoid propagating an error or notification 376 it has already received. 378 Such mechanisms SHOULD be used jointly or independently depending the 379 error or notification behaviors they are associated to. The 380 conditions of use for the TTL and DIFFUSION-LIST TLVs are described 381 in sections below. 383 5.4.1. Time-To-Live (TTL) TLV 385 The TTL value is set to any integer value to indicate the number of 386 PCEP peers that will recursively receive the message. The TTL TLV 387 SHOULD be used with propagated errors or notifications ("Propagation" 388 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP 389 peer MUST decrement the TTL value before propagating the message. 390 When the TTL value becomes 0, the message is no more propagated. 392 If the message to be propagated is request-specific and there is no 393 TTL or DIFFUSION-LIST TLVs included, the message MUST reach the 394 source PCC (or alternatively the target PCE). 396 5.4.2. DIFFUSION-LIST TLV 398 The DIFFUSION-LIST TLV can be carried within either the error object 399 of a PCErr message, or the notification object of a PCNtf message. 400 It can either be used in a message sent by a PCC to a PCE or vice 401 versa. The DIFFUSION-LIST MAY be used with propagated errors (TLV 402 "Propagation"at value 1 in PCEP-ERROR object). 404 The format of the DIFFUSION-LIST object body is as follows: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 // (Sub-objects) // 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Type (16 bits): restricts the diffusion to certain peers. The 417 following values are currently defined: 419 0: Any PCEP peer indicated in the list must be reached. 421 1: Only PCEs must be reached (and not PCC). 423 2: All PCEP peers with which a session is still opened must be 424 reached. 426 The value of DIFFUSION-LIST is made of sub-objects similar to the IRO 427 defined in [RFC5440]. The following sub-object types are supported. 429 Type Sub-object 431 1 IPv4 address 432 2 IPv6 address 433 4 Unnumbered Interface ID 434 5 4-byte AS number 435 6 OSPF area ID 436 7 IS-IS Area ID 437 32 Autonomous System number 438 33 Explicit eXclusion Route Sub-object (EXRS) 440 If the error or notification codes target specific PCEP peers, a 441 DIFFUSION-LIST TLV avoids partially flooding all PCEP peers. Any 442 PCEP peer receiving a PCErr or PCNTf message containing a PCEP-ERROR 443 or a NOTIFICATION object with a TLV "Propagation" at value 1 and 444 where a DIFFUSION-LIST appears, MUST remove the addresses of the PCEP 445 peers from the DIFFUSION-LIST, before sending the message to any 446 other PCEP peers. This is performed by adding the PCEP peer 447 addresses to the Explicit eXclusion Route Sub-object of the 448 DIFFUSION-LIST. If a DIFFUSION-LIST value is empty, the PCEP peer 449 MUST NOT propagate the message to any peer. 451 Note that, a Diffusion-List could contain strict or loose addresses 452 to refer to a network domain (e.g. an Autonomous System number, an 453 OSPF area, an IP address). Hence, the PCEP peers targeted by the 454 message would be the PCEP peers covering the corresponding domain. 455 If an address is loose, each time a PCEP peer forwards a message to 456 another PCEP peer of this address, it MUST add it own address to the 457 Explicit eXclusion Route Sub-object (EXRS) of the Diffusion-List for 458 any forwarded messages. Hence, a PCE SHOULD avoid forwarding the 459 same message repeated to the same set of peers. Finally, when an 460 address is loose, the forwarding SHOULD be restrained indicating what 461 type of PCEP peers are targeted (i.e. PCE and/or PCC). 463 5.4.3. Rules Applied to Existing Errors and Notifications 465 Many existing normative references states on error definitions (see 466 for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], 467 [RFC5886], [RFC8231], [RFC8232],[RFC8253], [RFC8281], [RFC8306], 468 [RFC8408], [RFC8697]). This section provides processing rules for 469 existing error types handling, as a recommendation. According to the 470 definitions provided in this document, the follwoing rules are 471 applicable: 473 Error-type 1, described in [RFC5440], relates to PCEP session 474 establishement failures. All errors of this type are local and 475 not propagated. Hence, if a "Propagation" TLV is added to the 476 error message it is recommended to be set to value 0. Error- 477 values 1,2,6,7 have a high level of criticality. Hence, if the 478 "Error-criticality" TLV is included within a PCErr message of type 479 1 and value 1,2,6 or 7, it is recommended to have a value of 2. 481 Error-type 2,3,4, "Capability not supported", "Unknown object" and 482 "Not supported object" respectively, described in [RFC5440]: 483 errors of this type MAY be propagated using the TLV "Propagation". 484 Their level of criticality is defined as leading to cancel the 485 path computation request [RFC5440]. Hence, if the "Error- 486 criticality" TLV is included, it usually have a value of 1. The 487 error-value 4 of error-type 4 ("Unsupported parameter") associated 488 to the BRPC procedure [RFC5441] is suggested to contain the 489 "Propagation" TLV with a DIFFUSION-LIST requesting a propagation 490 to the PCC at the origin of the request. 492 Error-type 5 refers to "Policy violation", error values for this 493 type have been defined in [RFC5440], [RFC5541], [RFC5557], 494 [RFC5886] and [RFC8306]. In [RFC5440], it is specified that the 495 path computation request MUST be cancelled when an error of type 5 496 occurs. Hence, if the "Error-criticality" TLV is included, it 497 usually have a value of 1. As such errors might be conveyed to 498 several PCEs, the "Propagation" TLV MAY be used. 500 Error-type 6 described as "Mandatory object missing" in [RFC5440], 501 leads to the cancellation of the path computation request. Hence, 502 if the "Error-criticality" TLV is included, it usually have a 503 value of 1. The "Propagation" TLV MAY be used with such errors. 504 The error-value of 4 for Monitoring object missing defined in 505 [RFC5886] is no exception to the rule. 507 Error-type 7 is described as "synchronized path computation 508 request missing". In [RFC5440], it is specified that the reffered 509 synchronized path computation request MUST be cancelled when an 510 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 511 included, it usually have a value of 1. The "Propagation" TLV MAY 512 be used with such errors. 514 Error-type 8 is raised when a PCE receives a PCRep with an unknown 515 request reference. If the "Propagation" TLV is used with error- 516 type 8, it is recommended to be set at a value of 0. The "Error- 517 criticality" TLV is not particularly relevant for error-type 8. 518 Hence, it usually have the value of 0 if used. 520 Error-type 9 is raised when a PCE attempts to establish a second 521 PCEP session. The existing session must be preserved. Hence, if 522 the "Error-criticality" TLV is included, it usually have a value 523 of 0. By definition, such an error message SHOULD NOT be 524 propagated. Thus, if the "Propagation" TLV is used with error- 525 type 9, it is usually set to a value of 0. 527 Error-type 10 which refers to the reception of an invalid object 528 as described in [RFC5440] no indication is provided on the 529 cancellation of the path computation request. Hence, if the 530 "Error-criticality" TLV is included, it usually have a value of 0. 531 The "Propagation" TLV MAY be used with such errors with any value 532 depending on the expected behavior. 534 Error-type 11 relates to "Unrecognized EXRS subobject" and is 535 described in [RFC5521]. No path computation request cancellation 536 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 537 is included, it usually have a value of 0. The "Propagation" TLV 538 MAY be used with such errors with any value depending on the 539 expected behavior. 541 Error-type 12 refers to "Diffserv-aware TE error" and is described 542 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 543 a PCReq is recognized but not supported by a PCE. [RFC5455] does 544 not state about the path computation request when such errors are 545 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 546 be used within such error-types' messages and set to any specified 547 values. 549 Error-type 13 on "BRPC procedure completion failure" is described 550 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 551 message MUST be relayed to the PCC. Hence, such messages SHOULD 552 contain a "Propagation" TLV and a DIFFUSION-LIST with a Target- 553 Type of 0 and corresponding addresses or with a Target-Type of 2. 554 It is not specified in [RFC5441] whether the path computation 555 request should be canceled or not. If the procedure is not 556 supported, it does not necessarily imply to cancel the path 557 computation request if another procedure is able to read and write 558 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 559 any value depending on the expected behavior. 561 Error-type 15 refers to "Global Concurrent Optimization Error" 562 defined in [RFC5557]. [RFC5557] states that the corresponding 563 global concurrent path optimization MUST be cancelled at the PCC. 565 Hence, if the "Error-criticality" TLV is included, it usually have 566 a value of 1. The "Propagation" TLV MAY be used with such errors. 568 Error-type 16 relates to "P2MP Capability Error" defined in 569 [RFC8306]. Such errors lead to the cancellation of the path 570 computation request. Hence, if the "Error-criticality" TLV is 571 included, it usually have a value of 1. The "Propagation" TLV MAY 572 be used with such errors. 574 Error-type 17, titled "P2MP END-POINTS Error" is defined 575 [RFC8306]. Such errors are thrown when a PCE tries to add or 576 prune nodes to or from a P2MP Tree. [RFC8306] does not specify if 577 such errors lead to cancel the path computation request. Hence, 578 the "Error-criticality" and "Propagation" TLVs MAY be used with 579 this type of error with any value depending on the expected 580 behavior. 582 Error-type 18 of "P2MP Fragmentation Error" is described [RFC8306] 583 which does not specify whether the path computation request should 584 be cancelled. But, as messages are fragmented, it is natural to 585 think that the PCE should wait at least a bit for further 586 messages. The "Error-criticality" TLV MAY be included in such 587 error messages and is particularly adapted to differ the semantic 588 of the same error-type message: if it is included with a value of 589 0 then the PCE will still wait for further fragmented messages, 590 when this waiting time ends, the TLV can be included with a value 591 of 1 in order to finally cancel the request. The "Propagation" 592 TLV MAY also be used with such errors. 594 Error-type 19 of "Invalid Operation" is described in [RFC8231] and 595 [RFC8281], which implies a wrong capability description for PCEP 596 session. In this case, the PCErr message MUST be returned to PCC, 597 and this message usually contain a "Propagation" TLV and a 598 DIFFUSION-LIST with a Target-Type of 0 or 2. The "Error- 599 criticality" TLV is recommended be set to 2 in order to guanrantee 600 the termination of PCEP session. 602 Error-type 20 of "LSP State Synchronization Error" is described in 603 [RFC8231] and [RFC8232], which cannot successfully sync up the LSP 604 states. In this case, the "Error-criticality" TLV should be set 605 to 2 in order to guanrantee the termination of PCEP session. The 606 "Propagation" TLV MAY also be used with such errors. 608 Error-type 21 of "Invalid traffic engineering path setup type" is 609 described in [RFC8408] . Such errors failed to find a matched path 610 setup type and the PCEP sessions MUST be closed. In this case, 611 the "Error-criticality" TLV is usually set to 2 in order to 612 guanrantee the termination of PCEP session. The "Propagation" TLV 613 MAY also be used with such errors. 615 Error-type 23 of "Bad parameter value" is described in [RFC8281] . 616 Such errors occur when there is a conflict in path name of C flag 617 not set for PCE initiation. In this case, the "Error-criticality" 618 TLV may be set to either 0 or 1 to indicate whether the request is 619 still valid, with the PCEP session open. The "Propagation" TLV 620 MAY also be used with such errors. 622 Error-type 24 of "LSP instantiation error" is described in 623 [RFC8281] . Such errors occur when PCC detects problems when 624 establishing the path, the message MUST relay to the PCE, 625 therefore the "Propogation" TLV is usually contained. The "Error- 626 criticality" TLV may be set to either 0 or 1 to indicate whether 627 the request is still valid, with the PCEP session open. 629 Error-type 25 of "PCEP StartTLS failure" is described in 630 [RFC8253]. Such errors indicate the security issue in transport 631 layer. In this case, the "Error-criticality" TLV is usually set 632 to 2 in order to close the PCEP session. The "Propagation" TLV 633 MAY also be used with such errors, depending on the detailed 634 security conditions. 636 Error-type 26 of "Association Error " is described in [RFC8697] . 637 Such errors occur when there is problem for LSP association. In 638 this case, the "Error-criticality" TLV should be set to either 0 639 or 1 to indicate whether the request is still valid, with the PCEP 640 session open. The "Propagation" TLV MAY also be used with such 641 errors. 643 6. Error Handling Guidelines for Future PCEP Extension 645 Error and Notification handling in this document should be considered 646 in PCE documents that include new errors and notifications. A 647 requirement for the authors of these drafts is to evaluate the 648 applicability of the procedure in this document and provide details 649 about the "Error-criticality" TLV and "Propagation" TLV for errors 650 and notifications defined in the draft. Example text is provided as 651 follow. 653 Error-type XX (fill in value of the Error-type) of " XXXX " (fill in 654 name of the Error-type) is described in [RFCYYYY] (fill in the 655 document reference of the Error-type). Such errors occur when ZZZZ 656 (fill in typical scenario). In this case, the "Error-criticality" 657 TLV should be set to X (fill in the recommended value) to indicate 658 whether the request is still valid, with the PCEP session open. The 659 error messages SHOULD/MAY (select the mandatory level) contain a 660 "Propagation" TLV and a DIFFUSION-LIST with a Target-Type of A(fill 661 in the recommended value). 663 7. Backward Compatibility Consideration 665 There would be backward compatibility issue if there are multiple 666 PCEs with different level understanding of error message. In a 667 scenario that PCE(i) propagate the error message to PCE (i+1), it is 668 possible that PCE (i+1) is not capable to extract the message 669 correctly, then such error message would be ignored and not be 670 further propagated. 672 There can be potential approach to avoid these problem, such as 673 recognizing the incapable PCE and avoiding propagation. However, 674 these approach is not in the scope of this document. 676 8. Implementation Status 678 [NOTE TO RFC EDITOR : This whole section and the reference to 679 [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 734 Type Value Meaning Reference 735 0 Any PCEP peers this document 737 1 PCEs but excludes 738 PCC-only peers this document 740 2 PCEs and PCCs this document 741 with which a session 742 is still opened 744 Subobjects Reference 745 1: IPv4 prefix this document 746 2: IPv6 prefix this document 747 4: Unnumbered Interface ID this document 748 5: 4-byte AS number this document 749 6 OSPF area ID this document 750 7 IS-IS Area ID this document 751 32: Autonomous system number this document 752 33: Explicit Exclusion Route subobject (EXRS) this document 754 11. References 756 11.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, 760 DOI 10.17487/RFC2119, March 1997, 761 . 763 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 764 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 765 DOI 10.17487/RFC5440, March 2009, 766 . 768 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 769 "A Backward-Recursive PCE-Based Computation (BRPC) 770 Procedure to Compute Shortest Constrained Inter-Domain 771 Traffic Engineering Label Switched Paths", RFC 5441, 772 DOI 10.17487/RFC5441, April 2009, 773 . 775 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 776 Kumaki, "Diffserv-Aware Class-Type Object for the Path 777 Computation Element Communication Protocol", RFC 5455, 778 DOI 10.17487/RFC5455, March 2009, 779 . 781 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 782 Path Computation Element Communication Protocol (PCEP) for 783 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 784 2009, . 786 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 787 Objective Functions in the Path Computation Element 788 Communication Protocol (PCEP)", RFC 5541, 789 DOI 10.17487/RFC5541, June 2009, 790 . 792 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 793 Computation Element Communication Protocol (PCEP) 794 Requirements and Protocol Extensions in Support of Global 795 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 796 July 2009, . 798 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 799 Monitoring Tools for Path Computation Element (PCE)-Based 800 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 801 . 803 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 804 Computation Element Communication Protocol (PCEP) 805 Extensions for Stateful PCE", RFC 8231, 806 DOI 10.17487/RFC8231, September 2017, 807 . 809 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 810 and D. Dhody, "Optimizations of Label Switched Path State 811 Synchronization Procedures for a Stateful PCE", RFC 8232, 812 DOI 10.17487/RFC8232, September 2017, 813 . 815 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 816 "PCEPS: Usage of TLS to Provide a Secure Transport for the 817 Path Computation Element Communication Protocol (PCEP)", 818 RFC 8253, DOI 10.17487/RFC8253, October 2017, 819 . 821 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 822 Computation Element Communication Protocol (PCEP) 823 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 824 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 825 . 827 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 828 "Extensions to the Path Computation Element Communication 829 Protocol (PCEP) for Point-to-Multipoint Traffic 830 Engineering Label Switched Paths", RFC 8306, 831 DOI 10.17487/RFC8306, November 2017, 832 . 834 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 835 Hardwick, "Conveying Path Setup Type in PCE Communication 836 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 837 July 2018, . 839 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 840 Dhody, D., and Y. Tanaka, "Path Computation Element 841 Communication Protocol (PCEP) Extensions for Establishing 842 Relationships between Sets of Label Switched Paths 843 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 844 . 846 11.2. Informational References 848 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 849 Element (PCE)-Based Architecture", RFC 4655, 850 DOI 10.17487/RFC4655, August 2006, 851 . 853 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 854 Constraints in the Path Computation Element Communication 855 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 856 . 858 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 859 Code: The Implementation Status Section", BCP 205, 860 RFC 7942, DOI 10.17487/RFC7942, July 2016, 861 . 863 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 864 "Hierarchical Stateful Path Computation Element (PCE)", 865 RFC 8751, DOI 10.17487/RFC8751, March 2020, 866 . 868 Appendix A. Error and Notification Scenarios 870 This section provides some examples depicting how the error described 871 above can be used in a PCEP session. The origin of the errors or 872 notifications is only illustrative and has no normative purpose. 873 Sometimes the PCE features behind may be implementation-specific 874 (e.g. detection of flooding). This section does not provide 875 scenarios for errors with a high-level of critcity (i.e., Error 876 behaviors 3 and 6) since such errors are very specific and until now 877 have been normalized only during the session establishment (error- 878 type of 1). 880 A.1. Error Behavior Type 1 882 In this example, a PCC attempts to establish a second PCEP session 883 with the same PCE for another request. Consequently the PCE sends 884 back an error message with error-type 9. This error stays local and 885 does not affect the former session. The second session is ignored. 886 If the "Propagation" TLV and "Error-criticality" TLV are used, they 887 should be both set to value 0. 889 +-+-+ +-+-+ 890 |PCC| |PCE| 891 +-+-+ +-+-+ 892 1) Path computation | | 893 event | | 894 2) PCE selection |----- Open Message--->| 895 |<--- Open message ----| 896 3) Path computation |---- PCReq message--->| 897 request X sent to | |4) Path computation 898 the selected PCE | | request queued 899 | | 900 5) Path computation | | 901 event | | 902 6) PCE selection | | 903 |----- Open Message--->|8) Session already 904 | |opened 905 |<--- PCErr message----| Error-type=9 906 | | 908 A.2. Error Behavior Type 2 910 In this example, the PCC sends a DiffServ-aware path computation 911 request. If the PCE receiving the request does not support the 912 indicated class-type, it thus sends back a PCErr message with error- 913 type=12 and error-value=1. If the "Propagation" TLV and "Error- 914 criticality" TLV are present, they should carry value 0 and value 1 915 respectively. Consequently, the request is cancelled. 917 +-+-+ +-+-+ 918 |PCC| |PCE| 919 +-+-+ +-+-+ 920 1) Path computation | | 921 event | | 922 2) PCE selection | | 923 3) Path computation |---- PCReq message--->| 924 request X sent to | |4) Path computation 925 the selected PCE | | request queued 926 | | 927 | |5) DiffServ class-type 928 | | not supported 929 | |6) Path computation 930 | | request X 931 | | cancelled 932 |<--- PCErr message----| Error-type=12 933 | | 935 A.3. Error Behavior Type 4 937 In this example, a PCC sends a path computation requests with no P 938 flag set (e.g. END-POINT object with P-flag cleared). This is 939 detected by another PCE in the sequence. The path computation 940 request can thus be treated but the P-Flag will be ignored. Hence, 941 this error is not critical but the source PCC should be informed of 942 this fact. So, a PCErr message with error-type 10 ("Reception of an 943 invalid object"). The PCEP-ERROR object of the message contains a 944 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 945 0. It is hence propagated backwardly to the source PCC. 947 +-+-+ +-+-+-+-+ +-+-+ 948 |PCC| |PCE|PCC| |PCE| 949 +-+-+ +-+-+-+-+ +-+-+ 950 |---- PCReq message-->| | 951 | | | 952 | |---- PCReq message--->| 953 | | | 954 | | |1) Parameter is 955 | | | not supported 956 | | | 957 | |<--- PCErr message----| Error-type=10 958 |<--- PCErr message---| | 959 | | | 961 A.4. Error Behavior Type 5 963 In this example, PCEs are using the BRPC procedure to treat a path 964 computation request [RFC5441]. However, one of the PCEs does not 965 support a parameter of the request. Hence, a PCErr message with 966 error-type 4 and error-value 4 is sent by this PCE and has to be 967 forwarded to the source PCC. The PCEP-ERROR object includes a 968 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 969 and the message is propagated backwardly to the source PCC. 970 Consequently, the request is cancelled. 972 +-+-+ +-+-+-+-+ +-+-+ 973 |PCC| |PCE|PCC| |PCE| 974 +-+-+ +-+-+-+-+ +-+-+ 975 |---- PCReq message-->| | 976 | | | 977 | |---- PCReq message--->| 978 | | | 979 | | |1) Unsupported 980 | | | Parameter BRPC 981 | | |2) Path 982 | | | computation 983 | | | request X 984 | | | cancelled 985 | |<--- PCErr message----| Error-type=4 986 |<--- PCErr message---| | 987 | | | 989 Authors' Addresses 991 Helia Pouyllau 992 Alcatel-Lucent 993 Route de Villejust 994 NOZAY 91620 995 FRANCE 997 Phone: + 33 (0)1 30 77 63 11 998 Email: helia.pouyllau@alcatel-lucent.com 999 Remi Theillaud 1000 Marben Products 1001 176 rue Jean Jaures 1002 Puteaux 92800 1003 FRANCE 1005 Phone: + 33 (0)1 79 62 10 22 1006 Email: remi.theillaud@marben-products.com 1008 Julien Meuric 1009 Orange 1010 2, avenue Pierre Marzin 1011 Lannion 22307 1012 FRANCE 1014 Email: julien.meuric@orange.com 1016 Haomian Zheng (Editor) 1017 Huawei Technologies 1018 H1, Xiliu Beipo Village, Songshan Lake, 1019 Dongguan, Guangdong 523808 1020 China 1022 Email: zhenghaomian@huawei.com 1024 Xian Zhang 1025 Huawei Technologies 1026 A10, Huawei Industrial Base, Bantian, Longgang District 1027 Shenzhen, Guangdong 518129 1028 P.R.China 1030 Email: zhang.xian@huawei.com