idnits 2.17.00 (12 Aug 2021) /tmp/idnits61834/draft-ietf-pce-local-protection-enforcement-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (4 May 2022) is 10 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Stone 3 Internet-Draft M. Aissaoui 4 Updates: 5440 (if approved) Nokia 5 Intended status: Standards Track S. Sidor 6 Expires: 5 November 2022 Cisco Systems, Inc. 7 S. Sivabalan 8 Ciena Coroporation 9 4 May 2022 11 Local Protection Enforcement in PCEP 12 draft-ietf-pce-local-protection-enforcement-05 14 Abstract 16 This document updates [RFC5440] to clarify usage of the local 17 protection desired bit signalled in Path Computation Element Protocol 18 (PCEP). This document also introduces a new flag for signalling 19 protection strictness in PCEP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 5 November 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Implementation differences . . . . . . . . . . . . . . . 4 59 4.2. SLA Enforcement . . . . . . . . . . . . . . . . . . . . . 4 60 5. Protection Enforcement Flag (E flag) . . . . . . . . . . . . 5 61 5.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 62 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8 64 6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Path Computation Element (PCE) Communication Protocol (PCEP) 77 [RFC5440] enables the communication between a Path Computation Client 78 (PCC) and a Path Control Element (PCE), or between two PCEs based on 79 the PCE architecture [RFC4655]. 81 PCEP [RFC5440] utilizes flags, values and concepts previously defined 82 in RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP- 83 TE [RFC4090]. One such concept in PCEP is the 'Local Protection 84 Desired' (L flag in the LSPA Object in [RFC5440]), which was 85 originally defined in the SESSION-ATTRIBUTE Object in RFC3209. In 86 RSVP, this flag signals to downstream routers that local protection 87 is desired, which indicates to transit routers that they may use a 88 local repair mechanism. The headend router calculating the path does 89 not know whether a downstream router will or will not protect a hop 90 during it's calculation. Therefore, a local protection desired does 91 not require the transit router to satisfy protection in order to 92 establish the RSVP signalled path. This flag is signalled in PCEP as 93 an attribute of the LSP via the LSP Attributes object. 95 PCEP Extensions for Segment Routing ([RFC8664]) extends support in 96 PCEP for Segment Routed LSPs (SR-LSPs) as defined in the Segment 97 Routing Architecture [RFC8402]. As per the Segment Routing 98 Architecture, Adjacency Segment Identifiers(Adj-SID) may be eligible 99 for protection (using IPFRR or MPLS-FRR). The protection eligibility 100 is advertised into IGP ([RFC8665] and [RFC8667]) as the B-Flag part 101 of the Adjacency SID sub-tlv and can be discovered by a PCE via BGP- 102 LS [RFC7752] using the BGP-LS Segment Routing Extensions ([RFC9085]). 103 An Adjacency SID may or may not have protection eligibility and for a 104 given adjacency between two routers there may be multiple Adjacency 105 SIDs, some of which are protected and some which are not. 107 A Segment Routed path calculated by PCE may contain various types of 108 segments, as defined in [RFC8402] such as Adjacency, Node or Binding. 109 The protection eligibility for Adjacency SIDs can be discovered by 110 PCE, so therefore the PCE can take the protection eligibility into 111 consideration as a path constraint. If a path is calculated to 112 include other segment identifiers which are not applicable to having 113 their protection state advertised, as they may only be locally 114 significant for each router processing the SID such as Node SIDs, it 115 may not be possible for PCE to include the protection constraint as 116 part of the path calculation. 118 It is desirable for an operator to define the enforcement, or 119 strictness of the protection requirement when it can be applied. 121 This document updates [RFC5440] by further describing the behaviour 122 with Local Protection Desired Flag (L flag) and extends on it with 123 the introduction of Enforcement Flag (E flag). 125 2. Requirements Language 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in BCP 14, 130 [RFC2119]. 132 3. Terminology 134 This document uses the following terminology: 136 PROTECTION MANDATORY: path MUST have protection eligibility on all 137 links. 139 UNPROTECTED MANDATORY: path MUST NOT have protection eligibility on 140 all links. 142 PROTECTION PREFERRED: path SHOULD have protection eligibility on all 143 links but MAY contain links which do not have protection eligibility. 145 UNPROTECTED PREFERRED: path SHOULD NOT have protection eligibility on 146 all links but MAY contain links which have protection eligibility. 148 PCC: Path Computation Client. Any client application requesting a 149 path computation to be performed by a Path Computation Element. 151 PCE: Path Computation Element. An entity (component, application, or 152 network node) that is capable of computing a network path or route 153 based on a network graph and applying computational constraints. 155 PCEP: Path Computation Element Protocol. 157 4. Motivation 159 4.1. Implementation differences 161 As defined in [RFC5440] the mechanism to signal protection 162 enforcement in PCEP is with the previously mentioned L flag defined 163 in the LSPA Object. The name of the flag uses the term "Desired", 164 which by definition means "strongly wished for or intended" and the 165 use case originated from the RSVP. For RSVP signalled paths, local 166 protection is not within control of the PCE. However, [RFC5440] does 167 state "When set, this means that the computed path must include links 168 protected with Fast Reroute as defined in [RFC4090]." 169 Implementations of [RFC5440] have either interpreted the L flag as 170 PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational 171 differences. 173 4.2. SLA Enforcement 175 The boolean bit flag is unable to distinguish between the different 176 options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION 177 PREFERRED and UNPROTECTED PREFERRED. The selection of the options 178 are typically dependent on the service level agreement the operator 179 wishes to impose on the LSP. When enforcement is used, the resulting 180 shortest path calculation is impacted. 182 For example, PROTECTION MANDATORY is for use cases where an operator 183 may need the LSP to follow a path which has local protection provided 184 along the full path, ensuring that if there is anywhere along the 185 path that traffic will be fast re-routed at the point of failure. 187 For another example, UNPROTECTED MANDATORY is when an operator may 188 intentionally prefer an LSP to not be locally protected, and thus 189 would rather local failures to cause the LSP to go down and/or rely 190 on other protection mechanisms such as a secondary diverse path. 192 There are also use cases where there is simply no requirement to 193 enforce protection or no protection along a path. This can be 194 considered as "do not care to enforce". This is a relaxation of the 195 protection constraint. The path calculation is permitted the use of 196 any SID which is available along the calculated path. The SID backup 197 availability does not impact the shortest path computation. Since 198 links may have both protected and unprotected SIDs available, the 199 option PROTECTION PREFERRED or UNPROTECTED PREFERRED is used to 200 instruction PCE a preference on which SID to select, as the behaviour 201 of the LSP would differ during a local failure depending on which SID 202 is selected. 204 5. Protection Enforcement Flag (E flag) 206 Section 7.11 in Path Computation Element Protocol [RFC5440] describes 207 the encoding of the Local Protection Desired (L flag). A new flag is 208 proposed in this document in the LSP Attributes Object which extends 209 the L flag to identify the protection enforcement. 211 Bit 6 has been early allocated by IANA as the Protection Enforcement 212 flag. 214 Codespace of the Flag field (LSPA Object) 216 Bit Description Reference 218 7 Local Protection Desired RFC5440 220 6 Local Protection Enforcement This I-D 222 The format of the LSPA Object as defined in [RFC5440] is: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Exclude-any | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Include-any | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Include-all | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Setup Prio | Holding Prio | Flags |E|L| Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 // Optional TLVs // 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Flags (8 bits) 242 * L Flag: As defined in [RFC5440] and further updated by this 243 document. When set, protection is desired. When not set, 244 protection is not desired. The enforcement of the protection is 245 identified via the E flag. 247 * E Flag (Protection Enforcement): This flag controls the strictness 248 in which PCE must apply the L flag. When set, the value of the L 249 flag MUST be respected during SID selection by PCE. When E flag 250 is not set, the value of the L flag SHOULD be respected as 251 selection criteria however PCE is permitted to relax or ignore L 252 flag when computing a path. The statements below indicate 253 preference when E flag is unset in combination with the L flag 254 value. 256 When L flag is set and E flag is set then PCE MUST consider the 257 protection eligibility as PROTECTION MANDATORY constraint. 259 When L flag is set and E flag is not set then PCE MUST consider the 260 protection eligibility as PROTECTION PREFERRED constraint. 262 When L flag is not set and E flag is not set then PCE SHOULD consider 263 the protection eligibility as UNPROTECTED PREFERRED but MAY consider 264 protection eligibility as UNPROTECTED MANDATORY constraint. 266 When L flag is not set and E flag is set then PCE MUST consider the 267 protection eligibility as UNPROTECTED MANDATORY constraint. 269 UNPROTECTED PREFERRED and PROTECTED PREFERRED may seem similar but 270 they indicate the preference of selection of a SID if PCE has an 271 option of either protected or unprotected available on a link. When 272 presented with either option, PCE SHOULD select the SID which has a 273 protection state matching the state of the L flag. 275 The protection enforcement constraint can only be applied to resource 276 selection in which the protection state or eligibility for protection 277 is known to PCE. It is RECOMMENDED for a PCE to assume a Node SID is 278 protected. It is RECOMMENDED for a PCE to assume an Adjacency SID is 279 protected if the backup flag advertised with the Adjacency SID is 280 set. If a PCE is unable to infer protection status of a resource, 281 PCE MAY use local policy to define protected status assumptions. 283 5.1. Backwards Compatibility 285 Considerations in the message passing between PCC and PCE for the E 286 flag bit which are not supported by the entity are outlined in this 287 section, with requirements for PCE and PCC implementing this document 288 described at the end. 290 For a PCC or PCE which does not yet support this document, the E flag 291 bit is ignored and set to zero in PCRpt and/or PCUpd as per [RFC5440] 292 for PCC-initiated or as per ([RFC8281]) for PCE-initiated LSPs. It's 293 important to note that [RFC8231] and [RFC8281] permit LSP Attribute 294 Object to be included in PCUpd messages for PCC-initiated and PCE- 295 initiated LSPs. For PCC-initiated LSPs, PCUpd E flag (and L flag) 296 are an echo from the previous PCRpt however the bit value is ignored 297 on PCE from the previous PCRpt, therefore the E flag value set in the 298 PCUpd is zero. A PCE which does not support this document sends 299 PCUpd messages with the E flag unset for PCC-initated LSPs even if 300 set in the prior PCReq or PCRpt. A PCC which does not support this 301 document sends PCRpt messages with the E flag unset for PCE-initiated 302 LSPs even if set in the prior PCInitiate or PCUpd. 304 For a PCC which does support this document, it MAY set E flag bit 305 depending on local configuration. If communicating with a PCE which 306 does not yet support this document, the PCE follows the behaviour 307 specified in [RFC5440] and will ignore the E flag bit thus it will 308 not compute a path respecting the enforcement constraint. 310 For PCC-initiated LSPs, PCC SHOULD ignore the E flag value received 311 from PCE in a PCUpd message. 313 For PCE-initiated LSPs, PCC MAY process the E flag value received 314 from PCE in a PCUpd message. PCE SHOULD ignore the E flag value 315 received from PCC in a PCRpt message. 317 6. Implementation Status 319 [Note to the RFC Editor - remove this section before publication, as 320 well as remove the reference to RFC 7942.] 322 This section records the status of known implementations of the 323 protocol defined by this specification at the time of posting of this 324 Internet-Draft, and is based on a proposal described in [RFC7942]. 325 The description of implementations in this section is intended to 326 assist the IETF in its decision processes in progressing drafts to 327 RFCs. Please note that the listing of any individual implementation 328 here does not imply endorsement by the IETF. Furthermore, no effort 329 has been spent to verify the information presented here that was 330 supplied by IETF contributors. This is not intended as, and must not 331 be construed to be, a catalogue of available implementations or their 332 features. Readers are advised to note that other implementations may 333 exist. 335 According to [RFC7942], "this will allow reviewers and working groups 336 to assign due consideration to documents that have the benefit of 337 running code, which may serve as evidence of valuable experimentation 338 and feedback that have made the implemented protocols more mature. 339 It is up to the individual working groups to use this information as 340 they see fit". 342 6.1. Nokia Implementation 344 * Organization: Nokia 346 * Implementation: NSP PCE and SROS PCC. 348 * Description: Implementation for calculation and conveying 349 intention described in this document 351 * Maturity Level: Demo 353 * Coverage: Full 355 * Contact: andrew.stone@nokia.com 357 6.2. Cisco Implementation 359 * Organization: Cisco Systems, Inc. 361 * Implementation: IOS-XR PCE and PCC. 363 * Description: Implementation for calculation and conveying 364 intention described in this document 366 * Maturity Level: Demo 368 * Coverage: Full 370 * Contact: ssidor@cisco.com 372 7. Security Considerations 374 This document clarifies the behaviour of an existing flag and 375 introduces a new flag to provide further control of that existing 376 behaviour. The introduction of this new flag and behaviour 377 clarification does not create any new sensitive information. No 378 additional security measure is required. 380 Securing the PCEP session using Transport Layer Security (TLS) 381 [RFC8253], as per the recommendations and best current practices in 382 [RFC7525] is RECOMMENDED. 384 8. IANA Considerations 386 8.1. LSPA Object 388 This document defines a new bit value in the sub-registry "LSPA 389 Object Flag Field" in the "Path Computation Element Protocol (PCEP) 390 Numbers" registry. IANA is requested to confirm the early-allocated 391 codepoint. 393 Bit Name Reference 395 6 Protection Enforcement This I-D 397 9. References 399 9.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 407 Computation Element (PCE)-Based Architecture", RFC 4655, 408 DOI 10.17487/RFC4655, August 2006, 409 . 411 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 412 Decraene, B., Litkowski, S., and R. Shakir, "Segment 413 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 414 July 2018, . 416 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 417 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 418 DOI 10.17487/RFC5440, March 2009, 419 . 421 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 422 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 423 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 424 . 426 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 427 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 428 DOI 10.17487/RFC4090, May 2005, 429 . 431 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 432 S. Ray, "North-Bound Distribution of Link-State and 433 Traffic Engineering (TE) Information Using BGP", RFC 7752, 434 DOI 10.17487/RFC7752, March 2016, 435 . 437 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 438 "PCEPS: Usage of TLS to Provide a Secure Transport for the 439 Path Computation Element Communication Protocol (PCEP)", 440 RFC 8253, DOI 10.17487/RFC8253, October 2017, 441 . 443 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 444 Computation Element Communication Protocol (PCEP) 445 Extensions for Stateful PCE", RFC 8231, 446 DOI 10.17487/RFC8231, September 2017, 447 . 449 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 450 Computation Element Communication Protocol (PCEP) 451 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 452 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 453 . 455 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 456 "Recommendations for Secure Use of Transport Layer 457 Security (TLS) and Datagram Transport Layer Security 458 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 459 2015, . 461 9.2. Informative References 463 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 464 Code: The Implementation Status Section", BCP 205, 465 RFC 7942, DOI 10.17487/RFC7942, July 2016, 466 . 468 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 469 and J. Hardwick, "Path Computation Element Communication 470 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 471 DOI 10.17487/RFC8664, December 2019, 472 . 474 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 475 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 476 Extensions for Segment Routing", RFC 8665, 477 DOI 10.17487/RFC8665, December 2019, 478 . 480 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 481 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 482 Extensions for Segment Routing", RFC 8667, 483 DOI 10.17487/RFC8667, December 2019, 484 . 486 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 487 H., and M. Chen, "Border Gateway Protocol - Link State 488 (BGP-LS) Extensions for Segment Routing", RFC 9085, 489 DOI 10.17487/RFC9085, August 2021, 490 . 492 Acknowledgements 494 Thanks to Dhruv Dhody and Mike Koldychev for reviewing and providing 495 very valuable feedback and discussions on this document. 497 Authors' Addresses 498 Andrew Stone 499 Nokia 500 600 March Road 501 Kanata Ontario K2K 2T6 502 Canada 503 Email: andrew.stone@nokia.com 505 Mustapha Aissaoui 506 Nokia 507 600 March Road 508 Kanata Ontario K2K 2T6 509 Canada 510 Email: mustapha.aissaoui@nokia.com 512 Samuel Sidor 513 Cisco Systems, Inc. 514 Eurovea Central 3. 515 Pribinova 10 516 811 09 Bratislava 517 Slovakia 518 Email: ssidor@cisco.com 520 Siva Sivabalan 521 Ciena Coroporation 522 385 Terry Fox Drive 523 Kanata Ontario K2K 0L1 524 Canada 525 Email: ssivabal@ciena.com