idnits 2.17.1 draft-ietf-pce-enhanced-errors-06.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 (August 15, 2019) is 1715 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) == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-11 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: February 16, 2020 J. Meuric 7 Orange 8 H. Zheng (Editor) 9 X. Zhang 10 Huawei Technologies 11 August 15, 2019 13 Extensions to the Path Computation Element Communication Protocol for 14 Enhanced Errors and Notifications 15 draft-ietf-pce-enhanced-errors-06.txt 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 February 16, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . 7 71 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 73 5.3. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 74 5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . . 9 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 . . . 11 78 6. Future Extension Guidelines . . . . . . . . . . . . . . . . . 15 79 7. Backward Compatibility Consideration . . . . . . . . . . . . 15 80 8. Error and Notification Scenarios . . . . . . . . . . . . . . 15 81 8.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15 82 8.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16 83 8.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 17 84 8.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 18 88 10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . 19 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 11.2. Informational References . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 [I-D.ietf-pce-stateful-hpce]. Thus, extending such error 137 codes and PCEP behaviors accordingly would improve interoperability 138 among different PCEP implementations and would solve some of these 139 issues. However, some of them would still remain (e.g. the 140 divergences in request 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 o "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 o "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 o 232 * Low-level of criticality: the received message does not affect 233 the PCEP connection and further answer can still be expected; 235 * Medium-level of criticality: the received message does not 236 affect the PCEP connection but the request(s) is(are) 237 cancelled; 239 * High-level of criticality: the received message indicates that 240 the PCEP peer will close the session with its peer (and so 241 pending requests associated by the error, if any, are 242 cancelled.) 244 The high-level of criticality has been extracted from [RFC5440] which 245 associates such a behavior to error-type of 1 (errors raised during 246 the PCEP session establishment). Hence, such errors are quite 247 specific. For the sake of completeness, they have been included in 248 this document. 250 4.2. PCEP Behaviors in Case of Notification 252 Notification messages can be employed in two different manners: 253 during the treatment of a PCEP request, or independently from it to 254 advertise information (in [RFC5440], the request ID list within a 255 PCNtf message is optional). Hence, three different types of 256 behaviors can be identified: 258 o "Local": the notification does not imply any forward or backward 259 propagation of the message; 261 o "Request-specific propagation": the received message requires to 262 be propagated forwardly or backwardly (depending on which peer has 263 sent the message) to the PCEP peers; 265 o "Non request-specific propagation": the received message must be 266 propagated to any known peers (e.g. if PCE discovery is activated) 267 or to a list of identified peers. 269 4.3. PCE Peer Identification 271 The propagation of errors and notifications affects the state of the 272 PCEP peers along the chain. In some cases, for instance a 273 notification that a PCE is overloaded, the identification of the PCEP 274 peer - or that the sender PCE is not the direct neighbor - might be 275 an important information for the PCEP peers receiving the message. 276 The ID of sender PCE is not carried in the error TLVs, but can be 277 achieved via the speaker entity ID TLV during state synchronization. 278 An example can be found in [RFC8232]. 280 5. PCEP Extensions for Error and Notification Handling 282 This section describes extensions to support error and notification 283 with respect to the PCEP behavior description defined in Section 4. 284 This document does not intend to modify errors and notification types 285 previously defined in existing documents (e.g. [RFC5440], [RFC5441], 286 etc.). Error related TLVs have been specified in this section, while 287 the notification functionality can be achieved via using PCNtf 288 message with RP object with no need to extend further notification 289 type. 291 5.1. Propagation TLV 293 To support the propagation behavior mentioned in Section 4.1 and 294 Section 4.2, a new optional TLV is defined, which can be carried in 295 PCEP-ERROR and NOTIFICATION objects, to indicate whether a message 296 has to be propagateed or not. The allocation from the "PCEP TLV Type 297 Indicators" sub-registry will be assigned by IANA and the request is 298 documented in Section 10. 300 The description is "Propagation", the length value is 2 bytes and the 301 value field is 1 byte. The value field is set to 0 meaning that the 302 message MUST NOT be propagated. If the value field is set to 1, the 303 message MUST be propagated. Section 5.4 specifies the destination 304 and to limit the number of messages. 306 5.2. Error-criticality TLV 308 To support the shutdown behavior mentioned in Section 4.1, we extend 309 the PCEP-ERROR object by creating a new optional TLV to indicate 310 whether an error is recoverable or not. The allocation from the 311 "PCEP TLV Type Indicators" sub-registry will be assigned by IANA and 312 the request is documented in Section 10. 314 The description is "Error-criticality", the length value is 2 bytes 315 and the value field is 1 byte. The value field is set to 0 meaning 316 that the error has a low-level of criticality (so further messages 317 can be expected for this request). If the value field is set to 1, 318 the error has a medium-level of criticality and requests whose 319 identifiers appear in the same message MUST be cancelled (so no 320 further messages can be expected for these requests). If the value 321 field is set to 2, the error has a high-level of criticality, the 322 connection for this PCEP session is closed by the sender PCE peer. 324 5.3. Behaviors and TLV combinations 326 The propagation behavior MAY be combined with all criticality levels, 327 thus leading to 6 different behaviors. In the case of a criticality 328 level of 2, the session is closed by the PCE peer which sends the 329 message. Hence, the criticality level is purely informative for the 330 PCE peer which receives the message. If it is combined with a 331 propagation behavior, then the PCE propagating the message MUST 332 indicate the same level of criticality if it closes the session. 333 Otherwise, it MUST use a criticality level of 1 if it does not close 334 the session. 336 For a PCErr message, all the possible behaviors described in 337 Section 4.1 can be covered with TLVs included in a PCEP-ERROR object. 338 The following table captures all combinations of error behaviors: 340 | Error \Propogation| 0 | 1 | 341 | criticallity\ Value | ( No |(Propogation | 342 | value \ | Propagation) | Required) | 343 |------------------------------------------------------| 344 | 0 (low) | Type 1 | Type 4 | 345 | 1 (medium) | Type 2 | Type 5 | 346 | 2 (high) | Type 3 | Type 6 | 347 |------------------------------------------------------| 349 o "Error Behavior Type 1" : Local Error with a low level of 350 criticality; 352 o "Error Behavior Type 2": Local Error with a medium level of 353 criticality; 355 o "Error Behavior Type 3": Local Error with a high level of 356 criticality; 358 o "Error Behavior Type 4": Propagated Error with a low level of 359 criticality; 361 o "Error Behavior Type 5": Propagated Error with a medium level of 362 criticality; 364 o "Error Behavior Type 6": Propagated Error with a high level of 365 criticality; 367 5.4. Propagation Restrictions TLVs 369 In order to limit the propagation of errors and notifications, the 370 following mechanisms SHOULD be used: 372 A Time-To-Live(TTL) RLV: to limit the number of PCEP peers that 373 will recursively receive the message; 375 A DIFFUSION-LIST TLV: to specify the PCEP peer addresses or 376 domains of PCEP peers the message must be propagate to; 378 History mechanism: if a PCEP peer keeps track of the messages it 379 has relayed, it could avoid propagating an error or notification 380 it has already received. 382 Such mechanisms SHOULD be used jointly or independently depending the 383 error or notification behaviors they are associated to. The 384 conditions of use for the TTL and DIFFUSION-LIST TLVs are described 385 in sections below. 387 5.4.1. Time-To-Live (TTL) TLV 389 The TTL value is set to any integer value to indicate the number of 390 PCEP peers that will recursively receive the message. The TTL TLV 391 SHOULD be used with propagated errors or notifications ("Propagation" 392 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP 393 peer MUST decrement the TTL value before propagating the message. 394 When the TTL value becomes 0, the message is no more propagated. 396 If the message to be propagated is request-specific and there is no 397 TTL or DIFFUSION-LIST TLVs included, the message MUST reach the 398 source PCC (or alternatively the target PCE). 400 5.4.2. DIFFUSION-LIST TLV 402 The DIFFUSION-LIST TLV can be carried within either the error object 403 of a PCErr message, or the notification object of a PCNtf message. 404 It can either be used in a message sent by a PCC to a PCE or vice 405 versa. The DIFFUSION-LIST MAY be used with propagated errors (TLV 406 "Propagation"at value 1 in PCEP-ERROR object). 408 The format of the DIFFUSION-LIST object body is as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 // (Sub-objects) // 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type (16 bits): restricts the diffusion to certain peers. The 421 following values are currently defined: 423 0: Any PCEP peer indicated in the list must be reached. 425 1: Only PCEs must be reached (and not PCC). 427 2: All PCEP peers with which a session is still opened must be 428 reached. 430 The value of DIFFUSION-LIST is made of sub-objects similar to the IRO 431 defined in [RFC5440]. The following sub-object types are supported. 433 Type Sub-object 435 1 IPv4 address 436 2 IPv6 address 437 4 Unnumbered Interface ID 438 5 4-byte AS number 439 6 OSPF area ID 440 7 IS-IS Area ID 441 32 Autonomous System number 442 33 Explicit eXclusion Route Sub-object (EXRS) 444 If the error or notification codes target specific PCEP peers, a 445 DIFFUSION-LIST TLV avoids partially flooding all PCEP peers. Any 446 PCEP peer receiving a PCErr or PCNTf message containing a PCEP-ERROR 447 or a NOTIFICATION object with a TLV "Propagation" at value 1 and 448 where a DIFFUSION-LIST appears, MUST remove the addresses of the PCEP 449 peers from the DIFFUSION-LIST, before sending the message to any 450 other PCEP peers. This is performed by adding the PCEP peer 451 addresses to the Explicit eXclusion Route Sub-object of the 452 DIFFUSION-LIST. If a DIFFUSION-LIST value is empty, the PCEP peer 453 MUST NOT propagate the message to any peer. 455 Note that, a Diffusion-List could contain strict or loose addresses 456 to refer to a network domain (e.g. an Autonomous System number, an 457 OSPF area, an IP address). Hence, the PCEP peers targeted by the 458 message would be the PCEP peers covering the corresponding domain. 459 If an address is loose, each time a PCEP peer forwards a message to 460 another PCEP peer of this address, it MUST add it own address to the 461 Explicit eXclusion Route Sub-object (EXRS) of the Diffusion-List for 462 any forwarded messages. Hence, a PCE SHOULD avoid forwarding the 463 same message repeated to the same set of peers. Finally, when an 464 address is loose, the forwarding SHOULD be restrained indicating what 465 type of PCEP peers are targeted (i.e. PCE and/or PCC). 467 5.4.3. Rules Applied to Existing Errors and Notifications 469 Many existing normative references states on error definitions (see 470 for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], 471 [RFC5886], [RFC8231], [RFC8232],[RFC8253], [RFC8281], [RFC8306], 472 [RFC8408], [I-D.ietf-pce-association-group]). This section provides 473 processing rules for existing error types handling, as a 474 recommendation. According to the definitions provided in this 475 document, the follwoing rules are applicable: 477 Error-type 1, described in [RFC5440], relates to PCEP session 478 establishement failures. All errors of this type are local and 479 not propagated. Hence, if a "Propagation" TLV is added to the 480 error message it is recommended to be set to value 0. Error- 481 values 1,2,6,7 have a high level of criticality. Hence, if the 482 "Error-criticality" TLV is included within a PCErr message of type 483 1 and value 1,2,6 or 7, it is recommended to have a value of 2. 485 Error-type 2,3,4, "Capability not supported", "Unknown object" and 486 "Not supported object" respectively, described in [RFC5440]: 487 errors of this type MAY be propagated using the TLV "Propagation". 488 Their level of criticality is defined as leading to cancel the 489 path computation request [RFC5440]. Hence, if the "Error- 490 criticality" TLV is included, it usually have a value of 1. The 491 error-value 4 of error-type 4 ("Unsupported parameter") associated 492 to the BRPC procedure [RFC5441] is suggested to contain the 493 "Propagation" TLV with a DIFFUSION-LIST requesting a propagation 494 to the PCC at the origin of the request. 496 Error-type 5 refers to "Policy violation", error values for this 497 type have been defined in [RFC5440], [RFC5541], [RFC5557], 498 [RFC5886] and [RFC8306]. In [RFC5440], it is specified that the 499 path computation request MUST be cancelled when an error of type 5 500 occurs. Hence, if the "Error-criticality" TLV is included, it 501 usually have a value of 1. As such errors might be conveyed to 502 several PCEs, the "Propagation" TLV MAY be used. 504 Error-type 6 described as "Mandatory object missing" in [RFC5440], 505 leads to the cancellation of the path computation request. Hence, 506 if the "Error-criticality" TLV is included, it usually have a 507 value of 1. The "Propagation" TLV MAY be used with such errors. 508 The error-value of 4 for Monitoring object missing defined in 509 [RFC5886] is no exception to the rule. 511 Error-type 7 is described as "synchronized path computation 512 request missing". In [RFC5440], it is specified that the reffered 513 synchronized path computation request MUST be cancelled when an 514 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 515 included, it usually have a value of 1. The "Propagation" TLV MAY 516 be used with such errors. 518 Error-type 8 is raised when a PCE receives a PCRep with an unknown 519 request reference. If the "Propagation" TLV is used with error- 520 type 8, it is recommended to be set at a value of 0. The "Error- 521 criticality" TLV is not particularly relevant for error-type 8. 522 Hence, it usually have the value of 0 if used. 524 Error-type 9 is raised when a PCE attempts to establish a second 525 PCEP session. The existing session must be preserved. Hence, if 526 the "Error-criticality" TLV is included, it usually have a value 527 of 0. By definition, such an error message SHOULD NOT be 528 propagated. Thus, if the "Propagation" TLV is used with error- 529 type 9, it is usually set to a value of 0. 531 Error-type 10 which refers to the reception of an invalid object 532 as described in [RFC5440] no indication is provided on the 533 cancellation of the path computation request. Hence, if the 534 "Error-criticality" TLV is included, it usually have a value of 0. 535 The "Propagation" TLV MAY be used with such errors with any value 536 depending on the expected behavior. 538 Error-type 11 relates to "Unrecognized EXRS subobject" and is 539 described in [RFC5521]. No path computation request cancellation 540 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 541 is included, it usually have a value of 0. The "Propagation" TLV 542 MAY be used with such errors with any value depending on the 543 expected behavior. 545 Error-type 12 refers to "Diffserv-aware TE error" and is described 546 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 547 a PCReq is recognized but not supported by a PCE. [RFC5455] does 548 not state about the path computation request when such errors are 549 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 550 be used within such error-types' messages and set to any specified 551 values. 553 Error-type 13 on "BRPC procedure completion failure" is described 554 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 555 message MUST be relayed to the PCC. Hence, such messages SHOULD 556 contain a "Propagation" TLV and a DIFFUSION-LIST with a Target- 557 Type of 0 and corresponding adresses or with a Target-Type of 2. 558 It is not specified in [RFC5441] whether the path computation 559 request should be canceled or not. If the procedure is not 560 supported, it does not necessarily imply to cancel the path 561 computation request if another procedure is able to read and write 562 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 563 any value depending on the expected behavior. 565 Error-type 15 refers to "Global Concurrent Optimization Error" 566 defined in [RFC5557]. [RFC5557] states that the corresponding 567 global concurrent path optimization MUST be cancelled at the PCC. 568 Hence, if the "Error-criticality" TLV is included, it usually have 569 a value of 1. The "Propagation" TLV MAY be used with such errors. 571 Error-type 16 relates to "P2MP Capability Error" defined in 572 [RFC8306]. Such errors lead to the cancellation of the path 573 computation request. Hence, if the "Error-criticality" TLV is 574 included, it usually have a value of 1. The "Propagation" TLV MAY 575 be used with such errors. 577 Error-type 17, titled "P2MP END-POINTS Error" is defined 578 [RFC8306]. Such errors are thrown when a PCE tries to add or 579 prune nodes to or from a P2MP Tree. [RFC8306] does not specify if 580 such errors lead to cancel the path computation request. Hence, 581 the "Error-criticality" and "Propagation" TLVs MAY be used with 582 this type of error with any value depending on the expected 583 behavior. 585 Error-type 18 of "P2MP Fragmentation Error" is described [RFC8306] 586 which does not specify whether the path computation request should 587 be cancelled. But, as messages are fragmented, it is natural to 588 think that the PCE should wait at least a bit for further 589 messages. The "Error-criticality" TLV MAY be included in such 590 error messages and is particularly adapted to differ the semantic 591 of the same error-type message: if it is included with a value of 592 0 then the PCE will still wait for further fragmented messages, 593 when this waiting time ends, the TLV can be included with a value 594 of 1 in order to finally cancel the request. The "Propagation" 595 TLV MAY also be used with such errors. 597 Error-type 19 of "Invalid Operation" is described in [RFC8231] and 598 [RFC8281], which implies a wrong capability description for PCEP 599 session. In this case, the PCErr message MUST be returned to PCC, 600 and this message usually contain a "Propagation" TLV and a 601 DIFFUSION-LIST with a Target-Type of 0 or 2. The "Error- 602 criticality" TLV is recommended be set to 2 in order to guanrantee 603 the termination of PCEP session. 605 Error-type 20 of "LSP State Synchronization Error" is described in 606 [RFC8231] and [RFC8232], which cannot successfully sync up the LSP 607 states. In this case, the "Error-criticality" TLV should be set 608 to 2 in order to guanrantee the termination of PCEP session. The 609 "Propagation" TLV MAY also be used with such errors. 611 Error-type 21 of "Invalid traffic engineering path setup type" is 612 described in [RFC8408] . Such errors failed to find a matched path 613 setup type and the PCEP sessions MUST be closed. In this case, 614 the "Error-criticality" TLV is usually set to 2 in order to 615 guanrantee the termination of PCEP session. The "Propagation" TLV 616 MAY also be used with such errors. 618 Error-type 23 of "Bad parameter value" is described in [RFC8281] . 619 Such errors occur when there is a conflict in path name of C flag 620 not set for PCE initiation. In this case, the "Error-criticality" 621 TLV may be set to either 0 or 1 to indicate whether the request is 622 still valid, with the PCEP session open. The "Propagation" TLV 623 MAY also be used with such errors. 625 Error-type 24 of "LSP instantiation error" is described in 626 [RFC8281] . Such errors occur when PCC detects problems when 627 establishing the path, the message MUST relay to the PCE, 628 therefore the "Propogation" TLV is usually contained. The "Error- 629 criticality" TLV may be set to either 0 or 1 to indicate whether 630 the request is still valid, with the PCEP session open. 632 Error-type 25 of "PCEP StartTLS failure" is described in 633 [RFC8253]. Such errors indicate the security issue in transport 634 layer. In this case, the "Error-criticality" TLV is usually set 635 to 2 in order to close the PCEP session. The "Propagation" TLV 636 MAY also be used with such errors, depending on the detailed 637 security conditions. 639 Error-type 26 of "Association Error " is described in 640 [I-D.ietf-pce-association-group] . Such errors occur when there is 641 problem for LSP association. In this case, the "Error- 642 criticality" TLV should be set to either 0 or 1 to indicate 643 whether the request is still valid, with the PCEP session open. 644 The "Propagation" TLV MAY also be used with such errors. 646 6. Future Extension Guidelines 648 Error and Notification handling in this document should be considered 649 in PCE documents that include new errors and notifications. A 650 requirement for the authors of these drafts is to evaluate the 651 applicability of the procedure in this document and provide details 652 about the "Error-criticality" TLV and "Propagation" TLV for errors 653 and notifications defined in the draft. Examples of this can be 654 found in section 5.4.3 of this document. 656 7. Backward Compatibility Consideration 658 There would be backward compatibility issue if there are multiple 659 PCEs with different level understanding of error message. In a 660 scenario that PCE(i) propagate the error message to PCE (i+1), it is 661 possible that PCE (i+1) is not capable to extract the message 662 correctly, then such error message would be ignored and not be 663 further propagated. 665 There can be potential approach to avoid these problem, such as 666 recognizing the incapable PCE and avoiding propagation. However, 667 these approach is not in the scope of this document. 669 8. Error and Notification Scenarios 671 [Editor Note] This section will be moved to appendix for publication. 673 This section provides some examples depicting how the error described 674 above can be used in a PCEP session. The origin of the errors or 675 notifications is only illustrative and has no normative purpose. 676 Sometimes the PCE features behind may be implementation-specific 677 (e.g. detection of flooding). This section does not provide 678 scenarios for errors with a high-level of critcity (i.e., Error 679 behaviors 3 and 6) since such errors are very specific and until now 680 have been normalized only during the session establishment (error- 681 type of 1). 683 8.1. Error Behavior Type 1 685 In this example, a PCC attempts to establish a second PCEP session 686 with the same PCE for another request. Consequently the PCE sends 687 back an error message with error-type 9. This error stays local and 688 does not affect the former session. The second session is ignored. 689 If the "Propagation" TLV and "Error-criticality" TLV are used, they 690 should be both set to value 0. 692 +-+-+ +-+-+ 693 |PCC| |PCE| 694 +-+-+ +-+-+ 695 1) Path computation | | 696 event | | 697 2) PCE selection |----- Open Message--->| 698 |<--- Open message ----| 699 3) Path computation |---- PCReq message--->| 700 request X sent to | |4) Path computation 701 the selected PCE | | request queued 702 | | 703 5) Path computation | | 704 event | | 705 6) PCE selection | | 706 |----- Open Message--->|8) Session already 707 | |opened 708 |<--- PCErr message----| Error-type=9 709 | | 711 8.2. Error Behavior Type 2 713 In this example, the PCC sends a DiffServ-aware path computation 714 request. If the PCE receiving the request does not support the 715 indicated class-type, it thus sends back a PCErr message with error- 716 type=12 and error-value=1. If the "Propagation" TLV and "Error- 717 criticality" TLV are present, they should carry value 0 and value 1 718 respectively. Consequently, the request is cancelled. 720 +-+-+ +-+-+ 721 |PCC| |PCE| 722 +-+-+ +-+-+ 723 1) Path computation | | 724 event | | 725 2) PCE selection | | 726 3) Path computation |---- PCReq message--->| 727 request X sent to | |4) Path computation 728 the selected PCE | | request queued 729 | | 730 | |5) DiffServ class-type 731 | | not supported 732 | |6) Path computation 733 | | request X 734 | | cancelled 735 |<--- PCErr message----| Error-type=12 736 | | 738 8.3. Error Behavior Type 4 740 In this example, a PCC sends a path computation requests with no P 741 flag set (e.g. END-POINT object with P-flag cleared). This is 742 detected by another PCE in the sequence. The path computation 743 request can thus be treated but the P-Flag will be ignored. Hence, 744 this error is not critical but the source PCC should be informed of 745 this fact. So, a PCErr message with error-type 10 ("Reception of an 746 invalid object"). The PCEP-ERROR object of the message contains a 747 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 748 0. It is hence propagated backwardly to the source PCC. 750 +-+-+ +-+-+-+-+ +-+-+ 751 |PCC| |PCE|PCC| |PCE| 752 +-+-+ +-+-+-+-+ +-+-+ 753 |---- PCReq message-->| | 754 | | | 755 | |---- PCReq message--->| 756 | | | 757 | | |1) Parameter is 758 | | | not supported 759 | | | 760 | |<--- PCErr message----| Error-type=10 761 |<--- PCErr message---| | 762 | | | 764 8.4. Error Behavior Type 5 766 In this example, PCEs are using the BRPC procedure to treat a path 767 computation request [RFC5441]. However, one of the PCEs does not 768 support a parameter of the request. Hence, a PCErr message with 769 error-type 4 and error-value 4 is sent by this PCE and has to be 770 forwarded to the source PCC. The PCEP-ERROR object includes a 771 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 772 and the message is propagated backwardly to the source PCC. 773 Consequently, the request is cancelled. 775 +-+-+ +-+-+-+-+ +-+-+ 776 |PCC| |PCE|PCC| |PCE| 777 +-+-+ +-+-+-+-+ +-+-+ 778 |---- PCReq message-->| | 779 | | | 780 | |---- PCReq message--->| 781 | | | 782 | | |1) Unsupported 783 | | | Parameter BRPC 784 | | |2) Path 785 | | | computation 786 | | | request X 787 | | | cancelled 788 | |<--- PCErr message----| Error-type=4 789 |<--- PCErr message---| | 790 | | | 792 9. Security Considerations 794 Within the introduced set of TLVs, the "Propagation" TLV affects PCEP 795 security considerations since it forces propagation behaviors. Thus, 796 a PCEP implementation SHOULD activate stateful mechanism when 797 receiving PCEP-ERROR or NOTIFICATION object including this TLV in 798 order to avoid DoS attacks. 800 10. IANA Considerations 802 IANA maintains a registry of PCEP parameters. This includes a sub- 803 registry for PCEP Objects. 805 IANA is requested to make an allocation from the sub-registry as 806 follows. The values here are suggested for use by IANA. 808 10.1. PCEP TLV Type Indicators 810 As described in Section 5.4 the newly defined TLVs allows a PCE to 811 enforce specific error and notification behaviors within PCEP-ERROR 812 and NOTIFICATION objects. IANA is requested to make the following 813 allocations from the "PCEP TLV Type Indicators" sub-registry. 815 Value Description Reference 816 TBD Propagation this document 817 TBD Error-criticality this document 819 10.2. New DIFFUSION-LIST TLV 821 Type Value Meaning Reference 822 0 Any PCEP peers this document 824 1 PCEs but excludes 825 PCC-only peers this document 827 2 PCEs and PCCs this document 828 with which a session 829 is still opened 831 Subobjects Reference 832 1: IPv4 prefix this document 833 2: IPv6 prefix this document 834 4: Unnumbered Interface ID this document 835 5: OSPF Area ID this document 836 6 OSPF area ID this document 837 7 IS-IS Area ID this document 838 32: Autonomous system number this document 839 33: Explicit Exclusion Route subobject (EXRS) this document 841 11. References 843 11.1. Normative References 845 [I-D.ietf-pce-association-group] 846 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 847 Dhody, D., and Y. Tanaka, "Path Computation Element 848 Communication Protocol (PCEP) Extensions for Establishing 849 Relationships Between Sets of Label Switched Paths 850 (LSPs)", draft-ietf-pce-association-group-10 (work in 851 progress), August 2019. 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, 855 DOI 10.17487/RFC2119, March 1997, 856 . 858 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 859 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 860 DOI 10.17487/RFC5440, March 2009, 861 . 863 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 864 "A Backward-Recursive PCE-Based Computation (BRPC) 865 Procedure to Compute Shortest Constrained Inter-Domain 866 Traffic Engineering Label Switched Paths", RFC 5441, 867 DOI 10.17487/RFC5441, April 2009, 868 . 870 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 871 Kumaki, "Diffserv-Aware Class-Type Object for the Path 872 Computation Element Communication Protocol", RFC 5455, 873 DOI 10.17487/RFC5455, March 2009, 874 . 876 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 877 Path Computation Element Communication Protocol (PCEP) for 878 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 879 2009, . 881 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 882 Objective Functions in the Path Computation Element 883 Communication Protocol (PCEP)", RFC 5541, 884 DOI 10.17487/RFC5541, June 2009, 885 . 887 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 888 Computation Element Communication Protocol (PCEP) 889 Requirements and Protocol Extensions in Support of Global 890 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 891 July 2009, . 893 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 894 Monitoring Tools for Path Computation Element (PCE)-Based 895 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 896 . 898 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 899 Computation Element Communication Protocol (PCEP) 900 Extensions for Stateful PCE", RFC 8231, 901 DOI 10.17487/RFC8231, September 2017, 902 . 904 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 905 and D. Dhody, "Optimizations of Label Switched Path State 906 Synchronization Procedures for a Stateful PCE", RFC 8232, 907 DOI 10.17487/RFC8232, September 2017, 908 . 910 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 911 "PCEPS: Usage of TLS to Provide a Secure Transport for the 912 Path Computation Element Communication Protocol (PCEP)", 913 RFC 8253, DOI 10.17487/RFC8253, October 2017, 914 . 916 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 917 Computation Element Communication Protocol (PCEP) 918 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 919 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 920 . 922 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 923 "Extensions to the Path Computation Element Communication 924 Protocol (PCEP) for Point-to-Multipoint Traffic 925 Engineering Label Switched Paths", RFC 8306, 926 DOI 10.17487/RFC8306, November 2017, 927 . 929 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 930 Hardwick, "Conveying Path Setup Type in PCE Communication 931 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 932 July 2018, . 934 11.2. Informational References 936 [I-D.ietf-pce-stateful-hpce] 937 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 938 "Hierarchical Stateful Path Computation Element (PCE).", 939 draft-ietf-pce-stateful-hpce-11 (work in progress), July 940 2019. 942 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 943 Element (PCE)-Based Architecture", RFC 4655, 944 DOI 10.17487/RFC4655, August 2006, 945 . 947 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 948 Constraints in the Path Computation Element Communication 949 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 950 . 952 Authors' Addresses 953 Helia Pouyllau 954 Alcatel-Lucent 955 Route de Villejust 956 NOZAY 91620 957 FRANCE 959 Phone: + 33 (0)1 30 77 63 11 960 Email: helia.pouyllau@alcatel-lucent.com 962 Remi Theillaud 963 Marben Products 964 176 rue Jean Jaures 965 Puteaux 92800 966 FRANCE 968 Phone: + 33 (0)1 79 62 10 22 969 Email: remi.theillaud@marben-products.com 971 Julien Meuric 972 Orange 973 2, avenue Pierre Marzin 974 Lannion 22307 975 FRANCE 977 Email: julien.meuric@orange.com 979 Haomian Zheng (Editor) 980 Huawei Technologies 981 H1-1-A043S Huawei Industrial Base, Songshanhu 982 Dongguan, Guangdong 523808 983 P.R.China 985 Email: zhenghaomian@huawei.com 987 Xian Zhang 988 Huawei Technologies 989 G1-2, Huawei Industrial Base, Bantian, Longgang District 990 Shenzhen, Guangdong 518129 991 P.R.China 993 Email: zhang.xian@huawei.com