idnits 2.17.1 draft-ietf-pce-enhanced-errors-05.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 abstract seems to contain references ([RFC5440]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 15, 2019) is 1868 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 (-10) exists of draft-ietf-pce-association-group-07 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-stateful-hpce (ref. 'I-D.ietf-pce-stateful-hpce') ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 3 errors (**), 0 flaws (~~), 3 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 19, 2019 J. Meuric 7 France Telecom Orange 8 H. Zheng (Editor) 9 X. Zhang 10 Huawei Technologies 11 February 15, 2019 13 Extensions to the Path Computation Element Communication Protocol for 14 Enhanced Errors and Notifications 15 draft-ietf-pce-enhanced-errors-05.txt 17 Abstract 19 This document defines new error and notification TLVs for the PCE 20 Communication Protocol (PCEP) [RFC5440]. It identifies the possible 21 PCEP behaviors in case of error or notification. Thus, this draft 22 defines types of errors and how they are disclosed to other PCEs in 23 order to support predefined PCEP behaviors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 19, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4 65 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5 67 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 68 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 69 5. PCEP Extensions for Error and Notification Handling . . . . . 7 70 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 72 5.3. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 73 5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . . 9 74 5.4.1. Time-To-Live (TTL) TLV . . . . . . . . . . . . . . . . . 9 75 5.4.2. DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . . 9 76 5.4.3. Rules Applied to Existing Errors and Notifications . . . 11 77 6. Future Extension Consideration . . . . . . . . . . . . . . . 15 78 7. Backward Compatibility Consideration . . . . . . . . . . . . 15 79 8. Error and Notification Scenarios . . . . . . . . . . . . . . 15 80 8.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15 81 8.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16 82 8.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 17 83 8.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 18 87 10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 11.2. Informational References . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Terminology 95 PCE terminology is defined in [RFC4655]. 97 PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a 98 PCE). 100 Source PCC: the PCC, for a given path computation query, initiating 101 the first PCEP request, which may then trigger a chain of successive 102 requests. 104 Target PCE: the PCE that can compute a path to the destination 105 without having to query any other PCE. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Introduction 115 The PCE Communication Protocol [RFC5440] is designed to be flexible 116 and extensible in order to allow future evolutions or specific 117 constraint support such as proposed in [RFC7470]. Crossing different 118 PCE implementations (e.g. from different providers or due to 119 different releases), a PCEP request may encounter unknown errors or 120 notification messages. In such a case, the PCEP RFC [RFC5440] 121 specifies to send a specific error code to the PCEP peer. This 122 document updates [RFC5440] by introducing mechanism to propagate the 123 error message, with specifying error and notification TLVs. 125 In the context of path computation crossing different routing domains 126 or autonomous systems, the number of different PCE system 127 specificities is potentially high, thus possibly leading to divergent 128 and unstable situations. Such phenomenon can also occur in 129 homogeneous cases since PCE systems have their own policies that can 130 introduce differences in requests treatment even for requests having 131 the same destination. In order to generalize PCEP behaviors in the 132 case of heterogeneous PCE systems, new objects have to be defined. 133 Dealing with heterogeneity is a major challenge considering PCE 134 applicability, particularly in multi-layer, multi-domain and H-PCE 135 contexts [I-D.ietf-pce-stateful-hpce]. Thus, extending such error 136 codes and PCEP behaviors accordingly would improve interoperability 137 among different PCEP implementations and would solve some of these 138 issues. However, some of them would still remain (e.g. the 139 divergences in request treatment introduced by different policies). 141 The purpose of this draft is to identify and specify new optional 142 TLVs and objects in order to generalize PCEP behaviors. 144 3.1. Examples 146 The two following scenarios underline the need for a normalization of 147 the PCEP behaviors according to existing error or notification types. 149 3.1.1. Error use-case 151 PCE(i-1) has sent a request to PCE(i) which has also sent a request 152 to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but 153 not PCE(i). If PCE(i+1) throws an error type and value unknown by 154 PCE(i). PCE(i) could then adopt any other behaviors and sends back 155 to PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown 156 Object) or 4 (Not supported Object) for instance. As a consequence, 157 the path request would be cancelled but the error has no meaning for 158 PCE(i-1) whereas if PCE(i) had simply forwarded the error sent by 159 PCE(i+1), it would have been understood by PCE(i-1). 161 3.1.2. Notification use-case 163 PCE(i-1) has sent a request to PCE(i) which has also sent a request 164 to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1) 165 should send a notification of type 2 and a value flag giving its 166 estimated congestion duration. PCE(i) can choose to stop the path 167 computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1) 168 ignores the congestion duration on PCE(i+1) and could seek it for 169 further requests. 171 4. PCEP Behaviors 173 One of the purposes of the PCE architecture is to compute paths 174 across networks, but an added value is to compute such paths in 175 inter-area/layer/domain environments. The PCE Communication Protocol 176 [RFC5440] is based on the Transport Communication Protocol (TCP). 177 Thus, to compute a path within the PCE architecture, several TCP/PCEP 178 sessions have to be set up, in a peer-to-peer manner, along a set of 179 identified PCEs. 181 When the PCEP session is up for two PCEP peers, the PCC of the first 182 PCE System (the source PCC) sends a PCReq message. If the PCC does 183 not receive any reply before the dead timer is out, then it goes back 184 to the idle state. A PCC can expect two kinds of replies: a PCRep 185 message containing one or more valid paths (EROs) or a negative PCRep 186 message containing a NO-PATH object. 188 Beside PCReq and PCRep messages, notification and error messages, 189 named respectively PCNtf and PCErr, can be sent. There are two types 190 of notification messages: type 1 is for cancelling pending requests 191 and type 2 for signaling a congestion of the PCE. Several error 192 values are described in [RFC5440]. The error types concerning the 193 session phase begin at 2, error type 1 values are dedicated to the 194 initialization phase. 196 As the PCE Communication Protocol is built to work in a peer-to-peer 197 manner (i.e. supported by a TCP Connection), it supposes that the 198 "deadtimer" of the source PCC is long enough to support the end-to- 199 end distributed path computation process. 201 The exchange of messages in the PCE Communication Protocol is 202 described in details when PCEP is in states OpenWait and KeepWait in 203 [RFC5440]. When the session is up, message exchange is defined in 204 [RFC5440]. [RFC5441] describes the Backward Recursive Path 205 Computation (BRPC) procedure, and, because it considers an inter- 206 domain path computation, gives a bigger picture of the possible 207 behaviors when the session is up. Detailed behavior is mostly let 208 free to any specific implementation. The following sections 209 identifies the PCEP behaviors in case of error or notification and 210 also introduce the requirement of PCEP peer identification in both 211 cases. 213 4.1. PCEP Behaviors in Case of Error 215 [RFC5440] specifies that "a PCEP Error message is sent in several 216 situations: when a protocol error condition is met or the request is 217 not compliant with the PCEP specification". On this basis, and 218 according to the other RFCs, the identified PCEP behaviors are the 219 followings: 221 o "Propagation": the received message requires to be propagated 222 forwardly or backwardly (depending on which PCEP peer has sent the 223 message) to a set of PCEP peers; 225 o "Criticality level": in different RFCs, error-types affects the 226 state of the PCEP request or session in different manners; hence, 227 different level of criticality can be observed: 229 o 231 * Low-level of criticality: the received message does not affect 232 the PCEP connection and further answer can still be expected; 234 * Medium-level of criticality: the received message does not 235 affect the PCEP connection but the request(s) is(are) 236 cancelled; 238 * High-level of criticality: the received message indicates that 239 the PCEP peer will close the session with its peer (and so 240 pending requests associated by the error, if any, are 241 cancelled.) 243 The high-level of criticality has been extracted from [RFC5440] which 244 associates such a behavior to error-type of 1 (errors raised during 245 the PCEP session establishment). Hence, such errors are quite 246 specific. For the sake of completeness, they have been included in 247 this document. 249 4.2. PCEP Behaviors in Case of Notification 251 Notification messages can be employed in two different manners: 252 during the treatment of a PCEP request, or independently from it to 253 advertise information (in [RFC5440], the request ID list within a 254 PCNtf message is optional). Hence, three different types of 255 behaviors can be identified: 257 o "Local": the notification does not imply any forward or backward 258 propagation of the message; 260 o "Request-specific propagation": the received message requires to 261 be propagated forwardly or backwardly (depending on which peer has 262 sent the message) to the PCEP peers; 264 o "Non request-specific propagation": the received message must be 265 propagated to any known peers (e.g. if PCE discovery is activated) 266 or to a list of identified peers. 268 4.3. PCE Peer Identification 270 The propagation of errors and notifications affects the state of the 271 PCEP peers along the chain. In some cases, for instance a 272 notification that a PCE is overloaded, the identification of the PCEP 273 peer - or that the sender PCE is not the direct neighbor - might be 274 an important information for the PCEP peers receiving the message. 275 The ID of sender PCE is not carried in the error TLVs, but can be 276 achieved via the speaker entity ID TLV during state synchronization. 277 An example can be found in [RFC8232]. 279 5. PCEP Extensions for Error and Notification Handling 281 This section describes extensions to support error and notification 282 with respect to the PCEP behavior description defined in Section 4. 283 This document does not intend to modify errors and notification types 284 previously defined in existing documents (e.g. [RFC5440], [RFC5441], 285 etc.). Error related TLVs have been specified in this section, while 286 the notification functionality can be achieved via using PCNtf 287 message with RP object with no need to extend further notification 288 type. 290 5.1. Propagation TLV 292 To support the propagation behavior mentioned in Section 4.1 and 293 Section 4.2, a new optional TLV is defined, which can be carried in 294 PCEP-ERROR and NOTIFICATION objects, to indicate whether a message 295 has to be propagateed or not. The allocation from the "PCEP TLV Type 296 Indicators" sub-registry will be assigned by IANA and the request is 297 documented in Section 10. 299 The description is "Propagation", the length value is 2 bytes and the 300 value field is 1 byte. The value field is set to 0 meaning that the 301 message MUST NOT be propagated. If the value field is set to 1, the 302 message MUST be propagated. Section 5.4 specifies the destination 303 and to limit the number of messages. 305 5.2. Error-criticality TLV 307 To support the shutdown behavior mentioned in Section 4.1, we extend 308 the PCEP-ERROR object by creating a new optional TLV to indicate 309 whether an error is recoverable or not. The allocation from the 310 "PCEP TLV Type Indicators" sub-registry will be assigned by IANA and 311 the request is documented in Section 10. 313 The description is "Error-criticality", the length value is 2 bytes 314 and the value field is 1 byte. The value field is set to 0 meaning 315 that the error has a low-level of criticality (so further messages 316 can be expected for this request). If the value field is set to 1, 317 the error has a medium-level of criticality and requests whose 318 identifiers appear in the same message MUST be cancelled (so no 319 further messages can be expected for these requests). If the value 320 field is set to 2, the error has a high-level of criticality, the 321 connection for this PCEP session is closed by the sender PCE peer. 323 5.3. Behaviors and TLV combinations 325 The propagation behavior MAY be combined with all criticality levels, 326 thus leading to 6 different behaviors. In the case of a criticality 327 level of 2, the session is closed by the PCE peer which sends the 328 message. Hence, the criticality level is purely informative for the 329 PCE peer which receives the message. If it is combined with a 330 propagation behavior, then the PCE propagating the message MUST 331 indicate the same level of criticality if it closes the session. 332 Otherwise, it MUST use a criticality level of 1 if it does not close 333 the session. 335 For a PCErr message, all the possible behaviors described in 336 Section 4.1 can be covered with TLVs included in a PCEP-ERROR object. 337 The following table captures all combinations of error behaviors: 339 | Error \Propogation| 0 | 1 | 340 | criticallity\ Value | ( No |(Propogation | 341 | value \ | Propagation) | Required) | 342 |------------------------------------------------------| 343 | 0 (low) | Type 1 | Type 4 | 344 | 1 (medium) | Type 2 | Type 5 | 345 | 2 (high) | Type 3 | Type 6 | 346 |------------------------------------------------------| 348 o "Error Behavior Type 1" : Local Error with a low level of 349 criticality; 351 o "Error Behavior Type 2": Local Error with a medium level of 352 criticality; 354 o "Error Behavior Type 3": Local Error with a high level of 355 criticality; 357 o "Error Behavior Type 4": Propagated Error with a low level of 358 criticality; 360 o "Error Behavior Type 5": Propagated Error with a medium level of 361 criticality; 363 o "Error Behavior Type 6": Propagated Error with a high level of 364 criticality; 366 5.4. Propagation Restrictions TLVs 368 In order to limit the propagation of errors and notifications, the 369 following mechanisms SHOULD be used: 371 A Time-To-Live(TTL) RLV: to limit the number of PCEP peers that 372 will recursively receive the message; 374 A DIFFUSION-LIST TLV: to specify the PCEP peer addresses or 375 domains of PCEP peers the message must be propagate to; 377 History mechanism: if a PCEP peer keeps track of the messages it 378 has relayed, it could avoid propagating an error or notification 379 it has already received. 381 Such mechanisms SHOULD be used jointly or independently depending the 382 error or notification behaviors they are associated to. The 383 conditions of use for the TTL and DIFFUSION-LIST TLVs are described 384 in sections below. 386 5.4.1. Time-To-Live (TTL) TLV 388 The TTL value is set to any integer value to indicate the number of 389 PCEP peers that will recursively receive the message. The TTL TLV 390 SHOULD be used with propagated errors or notifications ("Propagation" 391 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP 392 peer MUST decrement the TTL value before propagating the message. 393 When the TTL value becomes 0, the message is no more propagated. 395 If the message to be propagated is request-specific and there is no 396 TTL or DIFFUSION-LIST TLVs included, the message MUST reach the 397 source PCC (or alternatively the target PCE). 399 5.4.2. DIFFUSION-LIST TLV 401 The DIFFUSION-LIST TLV can be carried within either the error object 402 of a PCErr message, or the notification object of a PCNtf message. 403 It can either be used in a message sent by a PCC to a PCE or vice 404 versa. The DIFFUSION-LIST MAY be used with propagated errors (TLV 405 "Propagation"at value 1 in PCEP-ERROR object). 407 The format of the DIFFUSION-LIST object body is as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 // (Sub-objects) // 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Type (16 bits): restricts the diffusion to certain peers. The 420 following values are currently defined: 422 0: Any PCEP peer indicated in the list must be reached. 424 1: Only PCEs must be reached (and not PCC). 426 2: All PCEP peers with which a session is still opened must be 427 reached. 429 The value of DIFFUSION-LIST is made of sub-objects similar to the IRO 430 defined in [RFC5440]. The following sub-object types are supported. 432 Type Sub-object 434 1 IPv4 address 435 2 IPv6 address 436 4 Unnumbered Interface ID 437 5 4-byte AS number 438 6 OSPF area ID 439 7 IS-IS Area ID 440 32 Autonomous System number 441 33 Explicit eXclusion Route Sub-object (EXRS) 443 If the error or notification codes target specific PCEP peers, a 444 DIFFUSION-LIST TLV avoids partially flooding all PCEP peers. Any 445 PCEP peer receiving a PCErr or PCNTf message containing a PCEP-ERROR 446 or a NOTIFICATION object with a TLV "Propagation" at value 1 and 447 where a DIFFUSION-LIST appears, MUST remove the addresses of the PCEP 448 peers from the DIFFUSION-LIST, before sending the message to any 449 other PCEP peers. This is performed by adding the PCEP peer 450 addresses to the Explicit eXclusion Route Sub-object of the 451 DIFFUSION-LIST. If a DIFFUSION-LIST value is empty, the PCEP peer 452 MUST NOT propagate the message to any peer. 454 Note that, a Diffusion-List could contain strict or loose addresses 455 to refer to a network domain (e.g. an Autonomous System number, an 456 OSPF area, an IP address). Hence, the PCEP peers targeted by the 457 message would be the PCEP peers covering the corresponding domain. 458 If an address is loose, each time a PCEP peer forwards a message to 459 another PCEP peer of this address, it MUST add it own address to the 460 Explicit eXclusion Route Sub-object (EXRS) of the Diffusion-List for 461 any forwarded messages. Hence, a PCE SHOULD avoid forwarding the 462 same message repeated to the same set of peers. Finally, when an 463 address is loose, the forwarding SHOULD be restrained indicating what 464 type of PCEP peers are targeted (i.e. PCE and/or PCC). 466 5.4.3. Rules Applied to Existing Errors and Notifications 468 Many existing normative references states on error definitions (see 469 for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], 470 [RFC5886], [RFC6006], [RFC8231], [RFC8232],[RFC8253], [RFC8281], 471 [RFC8306], [RFC8408], [I-D.ietf-pce-association-group]). This 472 section provides processing rules for existing error types handling, 473 as a recommendation. According to the definitions provided in this 474 document, the follwoing rules are applicable: 476 Error-type 1, described in [RFC5440], relates to PCEP session 477 establishement failures. All errors of this type are local and 478 not propagated. Hence, if a "Propagation" TLV is added to the 479 error message it is recommended to be set to value 0. Error- 480 values 1,2,6,7 have a high level of criticality. Hence, if the 481 "Error-criticality" TLV is included within a PCErr message of type 482 1 and value 1,2,6 or 7, it is recommended to have a value of 2. 484 Error-type 2,3,4, "Capability not supported", "Unknown object" and 485 "Not supported object" respectively, described in [RFC5440]: 486 errors of this type MAY be propagated using the TLV "Propagation". 487 Their level of criticality is defined as leading to cancel the 488 path computation request [RFC5440]. Hence, if the "Error- 489 criticality" TLV is included, it usually have a value of 1. The 490 error-value 4 of error-type 4 ("Unsupported parameter") associated 491 to the BRPC procedure [RFC5441] is suggested to contain the 492 "Propagation" TLV with a DIFFUSION-LIST requesting a propagation 493 to the PCC at the origin of the request. 495 Error-type 5 refers to "Policy violation", error values for this 496 type have been defined in [RFC5440], [RFC5541], [RFC5557], 497 [RFC5886] and [RFC6006]. In [RFC5440], it is specified that the 498 path computation request MUST be cancelled when an error of type 5 499 occurs. Hence, if the "Error-criticality" TLV is included, it 500 usually have a value of 1. As such errors might be conveyed to 501 several PCEs, the "Propagation" TLV MAY be used. 503 Error-type 6 described as "Mandatory object missing" in [RFC5440], 504 leads to the cancellation of the path computation request. Hence, 505 if the "Error-criticality" TLV is included, it usually have a 506 value of 1. The "Propagation" TLV MAY be used with such errors. 507 The error-value of 4 for Monitoring object missing defined in 508 [RFC5886] is no exception to the rule. 510 Error-type 7 is described as "synchronized path computation 511 request missing". In [RFC5440], it is specified that the reffered 512 synchronized path computation request MUST be cancelled when an 513 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 514 included, it usually have a value of 1. The "Propagation" TLV MAY 515 be used with such errors. 517 Error-type 8 is raised when a PCE receives a PCRep with an unknown 518 request reference. If the "Propagation" TLV is used with error- 519 type 8, it is recommended to be set at a value of 0. The "Error- 520 criticality" TLV is not particularly relevant for error-type 8. 521 Hence, it usually have the value of 0 if used. 523 Error-type 9 is raised when a PCE attempts to establish a second 524 PCEP session. The existing session must be preserved. Hence, if 525 the "Error-criticality" TLV is included, it usually have a value 526 of 0. By definition, such an error message SHOULD NOT be 527 propagated. Thus, if the "Propagation" TLV is used with error- 528 type 9, it is usually set to a value of 0. 530 Error-type 10 which refers to the reception of an invalid object 531 as described in [RFC5440] no indication is provided on the 532 cancellation of the path computation request. Hence, if the 533 "Error-criticality" TLV is included, it usually have a value of 0. 534 The "Propagation" TLV MAY be used with such errors with any value 535 depending on the expected behavior. 537 Error-type 11 relates to "Unrecognized EXRS subobject" and is 538 described in [RFC5521]. No path computation request cancellation 539 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 540 is included, it usually have a value of 0. The "Propagation" TLV 541 MAY be used with such errors with any value depending on the 542 expected behavior. 544 Error-type 12 refers to "Diffserv-aware TE error" and is described 545 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 546 a PCReq is recognized but not supported by a PCE. [RFC5455] does 547 not state about the path computation request when such errors are 548 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 549 be used within such error-types' messages and set to any specified 550 values. 552 Error-type 13 on "BRPC procedure completion failure" is described 553 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 554 message MUST be relayed to the PCC. Hence, such messages SHOULD 555 contain a "Propagation" TLV and a DIFFUSION-LIST with a Target- 556 Type of 0 and corresponding adresses or with a Target-Type of 2. 557 It is not specified in [RFC5441] whether the path computation 558 request should be canceled or not. If the procedure is not 559 supported, it does not necessarily imply to cancel the path 560 computation request if another procedure is able to read and write 561 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 562 any value depending on the expected behavior. 564 Error-type 15 refers to "Global Concurrent Optimization Error" 565 defined in [RFC5557]. [RFC5557] states that the corresponding 566 global concurrent path optimization MUST be cancelled at the PCC. 567 Hence, if the "Error-criticality" TLV is included, it usually have 568 a value of 1. The "Propagation" TLV MAY be used with such errors. 570 Error-type 16 relates to "P2MP Capability Error" defined in 571 [RFC6006]. Such errors lead to the cancellation of the path 572 computation request. Hence, if the "Error-criticality" TLV is 573 included, it usually have a value of 1. The "Propagation" TLV MAY 574 be used with such errors. 576 Error-type 17, titled "P2MP END-POINTS Error" is defined 577 [RFC6006]. Such errors are thrown when a PCE tries to add or 578 prune nodes to or from a P2MP Tree. [RFC6006] does not specify if 579 such errors lead to cancel the path computation request. Hence, 580 the "Error-criticality" and "Propagation" TLVs MAY be used with 581 this type of error with any value depending on the expected 582 behavior. 584 Error-type 18 of "P2MP Fragmentation Error" is described [RFC6006] 585 which does not specify whether the path computation request should 586 be cancelled. But, as messages are fragmented, it is natural to 587 think that the PCE should wait at least a bit for further 588 messages. The "Error-criticality" TLV MAY be included in such 589 error messages and is particularly adapted to differ the semantic 590 of the same error-type message: if it is included with a value of 591 0 then the PCE will still wait for further fragmented messages, 592 when this waiting time ends, the TLV can be included with a value 593 of 1 in order to finally cancel the request. The "Propagation" 594 TLV MAY also be used with such errors. 596 Error-type 19 of "Invalid Operation" is described in [RFC8231] and 597 [RFC8281], which implies a wrong capability description for PCEP 598 session. In this case, the PCErr message MUST be returned to PCC, 599 and this message usually contain a "Propagation" TLV and a 600 DIFFUSION-LIST with a Target-Type of 0 or 2. The "Error- 601 criticality" TLV is recommended be set to 2 in order to guanrantee 602 the termination of PCEP session. 604 Error-type 20 of "LSP State Synchronization Error" is described in 605 [RFC8231] and [RFC8232], which cannot successfully sync up the LSP 606 states. In this case, the "Error-criticality" TLV should be set 607 to 2 in order to guanrantee the termination of PCEP session. The 608 "Propagation" TLV MAY also be used with such errors. 610 Error-type 21 of "Invalid traffic engineering path setup type" is 611 described in [RFC8408] . Such errors failed to find a matched path 612 setup type and the PCEP sessions MUST be closed. In this case, 613 the "Error-criticality" TLV is usually set to 2 in order to 614 guanrantee the termination of PCEP session. The "Propagation" TLV 615 MAY also be used with such errors. 617 Error-type 23 of "Bad parameter value" is described in [RFC8281] . 618 Such errors occur when there is a conflict in path name of C flag 619 not set for PCE initiation. In this case, the "Error-criticality" 620 TLV may be set to either 0 or 1 to indicate whether the request is 621 still valid, with the PCEP session open. The "Propagation" TLV 622 MAY also be used with such errors. 624 Error-type 24 of "LSP instantiation error" is described in 625 [RFC8281] . Such errors occur when PCC detects problems when 626 establishing the path, the message MUST relay to the PCE, 627 therefore the "Propogation" TLV is usually contained. The "Error- 628 criticality" TLV may be set to either 0 or 1 to indicate whether 629 the request is still valid, with the PCEP session open. 631 Error-type 25 of "PCEP StartTLS failure" is described in 632 [RFC8253]. Such errors indicate the security issue in transport 633 layer. In this case, the "Error-criticality" TLV is usually set 634 to 2 in order to close the PCEP session. The "Propagation" TLV 635 MAY also be used with such errors, depending on the detailed 636 security conditions. 638 Error-type 26 of "Association Error " is described in 639 [I-D.ietf-pce-association-group] . Such errors occur when there is 640 problem for LSP association. In this case, the "Error- 641 criticality" TLV should be set to either 0 or 1 to indicate 642 whether the request is still valid, with the PCEP session open. 643 The "Propagation" TLV MAY also be used with such errors. 645 6. Future Extension Consideration 647 The procedures specified in this work applies to all the existing 648 error types. For future PCE protocol extension who gives new error 649 types, it is requested to provide description on the applicability of 650 "Propagation" TLV and "Error-criticality" TLV. 652 7. Backward Compatibility Consideration 654 There would be backward compatibility issue if there are multiple 655 PCEs with different level understanding of error message. In a 656 scenario that PCE(i) propagate the error message to PCE (i+1), it is 657 possible that PCE (i+1) is not capable to extract the message 658 correctly, then such error message would be ignored and not be 659 further propagated. 661 There can be potential approach to avoid these problem, such as 662 recognizing the incapable PCE and avoiding propagation. However, 663 these approach is not in the scope of this document. 665 8. Error and Notification Scenarios 667 [Editor Note] This section will be moved to appendix for publication. 669 This section provides some examples depicting how the error described 670 above can be used in a PCEP session. The origin of the errors or 671 notifications is only illustrative and has no normative purpose. 672 Sometimes the PCE features behind may be implementation-specific 673 (e.g. detection of flooding). This section does not provide 674 scenarios for errors with a high-level of critcity (i.e., Error 675 behaviors 3 and 6) since such errors are very specific and until now 676 have been normalized only during the session establishment (error- 677 type of 1). 679 8.1. Error Behavior Type 1 681 In this example, a PCC attempts to establish a second PCEP session 682 with the same PCE for another request. Consequently the PCE sends 683 back an error message with error-type 9. This error stays local and 684 does not affect the former session. The second session is ignored. 685 If the "Propagation" TLV and "Error-criticality" TLV are used, they 686 should be both set to value 0. 688 +-+-+ +-+-+ 689 |PCC| |PCE| 690 +-+-+ +-+-+ 691 1) Path computation | | 692 event | | 693 2) PCE selection |----- Open Message--->| 694 |<--- Open message ----| 695 3) Path computation |---- PCReq message--->| 696 request X sent to | |4) Path computation 697 the selected PCE | | request queued 698 | | 699 5) Path computation | | 700 event | | 701 6) PCE selection | | 702 |----- Open Message--->|8) Session already 703 | |opened 704 |<--- PCErr message----| Error-type=9 705 | | 707 8.2. Error Behavior Type 2 709 In this example, the PCC sends a DiffServ-aware path computation 710 request. If the PCE receiving the request does not support the 711 indicated class-type, it thus sends back a PCErr message with error- 712 type=12 and error-value=1. If the "Propagation" TLV and "Error- 713 criticality" TLV are present, they should carry value 0 and value 1 714 respectively. Consequently, the request is cancelled. 716 +-+-+ +-+-+ 717 |PCC| |PCE| 718 +-+-+ +-+-+ 719 1) Path computation | | 720 event | | 721 2) PCE selection | | 722 3) Path computation |---- PCReq message--->| 723 request X sent to | |4) Path computation 724 the selected PCE | | request queued 725 | | 726 | |5) DiffServ class-type 727 | | not supported 728 | |6) Path computation 729 | | request X 730 | | cancelled 731 |<--- PCErr message----| Error-type=12 732 | | 734 8.3. Error Behavior Type 4 736 In this example, a PCC sends a path computation requests with no P 737 flag set (e.g. END-POINT object with P-flag cleared). This is 738 detected by another PCE in the sequence. The path computation 739 request can thus be treated but the P-Flag will be ignored. Hence, 740 this error is not critical but the source PCC should be informed of 741 this fact. So, a PCErr message with error-type 10 ("Reception of an 742 invalid object"). The PCEP-ERROR object of the message contains a 743 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 744 0. It is hence propagated backwardly to the source PCC. 746 +-+-+ +-+-+-+-+ +-+-+ 747 |PCC| |PCE|PCC| |PCE| 748 +-+-+ +-+-+-+-+ +-+-+ 749 |---- PCReq message-->| | 750 | | | 751 | |---- PCReq message--->| 752 | | | 753 | | |1) Parameter is 754 | | | not supported 755 | | | 756 | |<--- PCErr message----| Error-type=10 757 |<--- PCErr message---| | 758 | | | 760 8.4. Error Behavior Type 5 762 In this example, PCEs are using the BRPC procedure to treat a path 763 computation request [RFC5441]. However, one of the PCEs does not 764 support a parameter of the request. Hence, a PCErr message with 765 error-type 4 and error-value 4 is sent by this PCE and has to be 766 forwarded to the source PCC. The PCEP-ERROR object includes a 767 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 768 and the message is propagated backwardly to the source PCC. 769 Consequently, the request is cancelled. 771 +-+-+ +-+-+-+-+ +-+-+ 772 |PCC| |PCE|PCC| |PCE| 773 +-+-+ +-+-+-+-+ +-+-+ 774 |---- PCReq message-->| | 775 | | | 776 | |---- PCReq message--->| 777 | | | 778 | | |1) Unsupported 779 | | | Parameter BRPC 780 | | |2) Path 781 | | | computation 782 | | | request X 783 | | | cancelled 784 | |<--- PCErr message----| Error-type=4 785 |<--- PCErr message---| | 786 | | | 788 9. Security Considerations 790 Within the introduced set of TLVs, the "Propagation" TLV affects PCEP 791 security considerations since it forces propagation behaviors. Thus, 792 a PCEP implementation SHOULD activate stateful mechanism when 793 receiving PCEP-ERROR or NOTIFICATION object including this TLV in 794 order to avoid DoS attacks. 796 10. IANA Considerations 798 IANA maintains a registry of PCEP parameters. This includes a sub- 799 registry for PCEP Objects. 801 IANA is requested to make an allocation from the sub-registry as 802 follows. The values here are suggested for use by IANA. 804 10.1. PCEP TLV Type Indicators 806 As described in Section 5.4 the newly defined TLVs allows a PCE to 807 enforce specific error and notification behaviors within PCEP-ERROR 808 and NOTIFICATION objects. IANA is requested to make the following 809 allocations from the "PCEP TLV Type Indicators" sub-registry. 811 Value Description Reference 812 TBD Propagation this document 813 TBD Error-criticality this document 815 10.2. New DIFFUSION-LIST TLV 817 Type Value Meaning Reference 818 0 Any PCEP peers this document 820 1 PCEs but excludes 821 PCC-only peers this document 823 2 PCEs and PCCs this document 824 with which a session 825 is still opened 827 Subobjects Reference 828 1: IPv4 prefix this document 829 2: IPv6 prefix this document 830 4: Unnumbered Interface ID this document 831 5: OSPF Area ID this document 832 6 OSPF area ID this document 833 7 IS-IS Area ID this document 834 32: Autonomous system number this document 835 33: Explicit Exclusion Route subobject (EXRS) this document 837 11. References 839 11.1. Normative References 841 [I-D.ietf-pce-association-group] 842 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 843 Dhody, D., and Y. Tanaka, "PCEP Extensions for 844 Establishing Relationships Between Sets of LSPs", draft- 845 ietf-pce-association-group-07 (work in progress), December 846 2018. 848 [I-D.ietf-pce-stateful-hpce] 849 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 850 and O. Dios, "Hierarchical Stateful Path Computation 851 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 852 progress), October 2018. 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 860 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 861 DOI 10.17487/RFC5440, March 2009, 862 . 864 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 865 "A Backward-Recursive PCE-Based Computation (BRPC) 866 Procedure to Compute Shortest Constrained Inter-Domain 867 Traffic Engineering Label Switched Paths", RFC 5441, 868 DOI 10.17487/RFC5441, April 2009, 869 . 871 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 872 Kumaki, "Diffserv-Aware Class-Type Object for the Path 873 Computation Element Communication Protocol", RFC 5455, 874 DOI 10.17487/RFC5455, March 2009, 875 . 877 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 878 Path Computation Element Communication Protocol (PCEP) for 879 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 880 2009, . 882 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 883 Objective Functions in the Path Computation Element 884 Communication Protocol (PCEP)", RFC 5541, 885 DOI 10.17487/RFC5541, June 2009, 886 . 888 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 889 Computation Element Communication Protocol (PCEP) 890 Requirements and Protocol Extensions in Support of Global 891 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 892 July 2009, . 894 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 895 Monitoring Tools for Path Computation Element (PCE)-Based 896 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 897 . 899 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 900 Ali, Z., and J. Meuric, "Extensions to the Path 901 Computation Element Communication Protocol (PCEP) for 902 Point-to-Multipoint Traffic Engineering Label Switched 903 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 904 . 906 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 907 Computation Element Communication Protocol (PCEP) 908 Extensions for Stateful PCE", RFC 8231, 909 DOI 10.17487/RFC8231, September 2017, 910 . 912 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 913 and D. Dhody, "Optimizations of Label Switched Path State 914 Synchronization Procedures for a Stateful PCE", RFC 8232, 915 DOI 10.17487/RFC8232, September 2017, 916 . 918 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 919 "PCEPS: Usage of TLS to Provide a Secure Transport for the 920 Path Computation Element Communication Protocol (PCEP)", 921 RFC 8253, DOI 10.17487/RFC8253, October 2017, 922 . 924 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 925 Computation Element Communication Protocol (PCEP) 926 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 927 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 928 . 930 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 931 "Extensions to the Path Computation Element Communication 932 Protocol (PCEP) for Point-to-Multipoint Traffic 933 Engineering Label Switched Paths", RFC 8306, 934 DOI 10.17487/RFC8306, November 2017, 935 . 937 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 938 Hardwick, "Conveying Path Setup Type in PCE Communication 939 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 940 July 2018, . 942 11.2. Informational References 944 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 945 Element (PCE)-Based Architecture", RFC 4655, 946 DOI 10.17487/RFC4655, August 2006, 947 . 949 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 950 Constraints in the Path Computation Element Communication 951 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 952 . 954 Authors' Addresses 956 Helia Pouyllau 957 Alcatel-Lucent 958 Route de Villejust 959 NOZAY 91620 960 FRANCE 962 Phone: + 33 (0)1 30 77 63 11 963 Email: helia.pouyllau@alcatel-lucent.com 965 Remi Theillaud 966 Marben Products 967 176 rue Jean Jaures 968 Puteaux 92800 969 FRANCE 971 Phone: + 33 (0)1 79 62 10 22 972 Email: remi.theillaud@marben-products.com 974 Julien Meuric 975 France Telecom Orange 976 2, avenue Pierre Marzin 977 Lannion 22307 978 FRANCE 980 Email: julien.meuric@orange-ftgroup.com 982 Haomian Zheng (Editor) 983 Huawei Technologies 984 H1-1-A043S Huawei Industrial Base, Songshanhu 985 Dongguan, Guangdong 523808 986 P.R.China 988 Email: zhenghaomian@huawei.com 990 Xian Zhang 991 Huawei Technologies 992 G1-2, Huawei Industrial Base, Bantian, Longgang District 993 Shenzhen, Guangdong 518129 994 P.R.China 996 Email: zhang.xian@huawei.com