idnits 2.17.1 draft-stone-pce-local-protection-enforcement-02.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (August 17, 2020) is 1342 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 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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: February 18, 2021 Cisco Systems, Inc. 7 S. Sivabalan 8 Ciena Coroporation 9 August 17, 2020 11 Local Protection Enforcement in PCEP 12 draft-stone-pce-local-protection-enforcement-02 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 February 18, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Implementation differences . . . . . . . . . . . . . . . 4 60 4.2. SLA Enforcement . . . . . . . . . . . . . . . . . . . . . 4 61 5. Protection Enforcement Flag (E-Flag) . . . . . . . . . . . . 5 62 5.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 63 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8 65 6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. LSP Attributes Protection Enforcement Flag . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Path Computation Element (PCE) Communication Protocol (PCEP) 78 [RFC5440] enables the communication between a Path Computation Client 79 (PCC) and a Path Control Element (PCE), or between two PCEs based on 80 the PCE architecture [RFC4655]. 82 PCEP [RFC5440] utilizes flags, values and concepts previously defined 83 in RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP- 84 TE [RFC4090]. One such concept in PCEP is the 'Local Protection 85 Desired' (L-flag in the LSPA Object in RFC5440), which was originally 86 defined in the SESSION-ATTRIBUTE Object in RFC3209. In RSVP, this 87 flag signals to downstream routers that local protection is desired, 88 which indicates to transit routers that they may use a local repair 89 mechanism. The headend router calculating the path does not know 90 whether a downstream router will or will not protect a hop during 91 it's calculation. Therefore, a local protection desired does not 92 require the transit router to satisfy protection in order to 93 establish the RSVP signalled path. This flag is signalled in PCEP as 94 an attribute of the LSP via the LSP Attributes object. 96 PCEP Extensions for Segment Routing (draft-ietf-pce-segment-routing) 97 extends support in PCEP for Segment Routed LSPs (SR-LSPs) as defined 98 in the Segment Routing Architecture [RFC8402]. As per the Segment 99 Routing Architecture, Adjacency Segment Identifiers(Adj-SID) may be 100 eligible for protection (using IPFRR or MPLS-FRR). The protection 101 eligibility is advertised into IGP (draft-ietf-ospf-segment-routing- 102 extensions and draft-ietf-isis-segment-routing-extensions) as the 103 B-Flag part of the Adjacency SID sub-tlv and can be discovered by a 104 PCE via BGP-LS [RFC7752] using the BGP-LS Segment Routing Extensions 105 (draft-ietf-idr-bgp-ls-segment-routing-ext). An Adjacency SID may or 106 may not have protection eligibility and for a given adjacency between 107 two routers there may be multiple Adjacency SIDs, some of which are 108 protected and some which are not. 110 A Segment Routed path calculated by PCE may contain various types of 111 segments, as defined in [RFC8402] such as Adjacency, Node or Binding. 112 The protection eligibility for Adjacency SIDs can be discovered by 113 PCE, so therefore the PCE can take the protection eligibility into 114 consideration as a path constraint. If a path is calculated to 115 include other segment identifiers which are not applicable to having 116 their protection state advertised, as they may only be locally 117 significant for each router processing the SID such as Node SIDs, it 118 may not be possible for PCE to include the protection constraint as 119 part of the path calculation. 121 It is desirable for an operator to define the enforcement, or 122 strictness of the protection requirement when it can be applied. 124 This document updates [RFC5440] by further describing the behaviour 125 with Local Protection Desired Flag (L-Flag) and extends on it with 126 the introduction of Enforcement Flag (E-Flag). 128 2. Requirements Language 130 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 131 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 132 and "OPTIONAL" are to be interpreted as described in BCP 14, 133 [RFC2119]. 135 3. Terminology 137 This document uses the following terminology: 139 PROTECTION MANDATORY: path MUST have protection eligibility on all 140 links. 142 UNPROTECTED MANDATORY: path MUST NOT have protection eligibility on 143 all links. 145 PROTECTION PREFERRED: path SHOULD have protection eligibility on all 146 links but MAY contain links which do not have protection eligibility. 148 UNPROTECTED PREFERRED: path SHOULD NOT have protection eligibility on 149 all links but MAY contain links which have protection eligibility. 151 PCC: Path Computation Client. Any client application requesting a 152 path computation to be performed by a Path Computation Element. 154 PCE: Path Computation Element. An entity (component, application, or 155 network node) that is capable of computing a network path or route 156 based on a network graph and applying computational constraints. 158 PCEP: Path Computation Element Protocol. 160 4. Motivation 162 4.1. Implementation differences 164 As defined in [RFC5440] the mechanism to signal protection 165 enforcement in PCEP is with the previously mentioned L-flag defined 166 in the LSPA Object. The name of the flag uses the term "Desired", 167 which by definition means "strongly wished for or intended" and is 168 rooted in the RSVP use case. For RSVP, this is not within control of 169 the PCE. However, [RFC5440] does state "When set, this means that 170 the computed path must include links protected with Fast Reroute as 171 defined in [RFC4090]." Implementations of [RFC5440] have either 172 interpreted the L-Flag as PROTECTION MANDATORY or PROTECTION 173 PREFERRED, leading to operational differences. 175 4.2. SLA Enforcement 177 The boolean bit flag is unable to distinguish between the different 178 options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION 179 PREFERRED and UNPROTECTED PREFERRED. The selection of the options 180 are typically dependent on the service level agreement the operator 181 wishes to impose on the LSP. When enforcement is used, the resulting 182 shortest path calculation is impacted. 184 For example, PROTECTION MANDATORY is for use cases where an operator 185 may need the LSP to follow a path which has local protection provided 186 along the full path, ensuring that if there is anywhere along the 187 path that traffic will be fast re-routed at the point of failure. 189 For another example, UNPROTECTED MANDATORY is when an operator may 190 intentionally prefer an LSP to not be locally protected, and thus 191 would rather local failures to cause the LSP to go down and/or rely 192 on other protection mechanisms such as a secondary diverse path. 194 There are also use cases where there is simply no requirement to 195 enforce protection or no protection along a path. This can be 196 considered as "do not care to enforce". This is a relaxation of the 197 protection constraint. The path calculation is permitted the use of 198 any SID which is available along the calculated path. The SID backup 199 availability does not impact the shortest path computation. Since 200 links may have both protected and unprotected SIDs available, the 201 option PROTECTION PREFERRED or UNPROTECTED PREFERRED is used to 202 instruction PCE a preference on which SID to select, as the behaviour 203 of the LSP would differ during a local failure depending on which SID 204 is selected. 206 5. Protection Enforcement Flag (E-Flag) 208 Section 7.11 in Path Computation Element Protocol [RFC5440] describes 209 the encoding of the Local Protection Desired (L-Flag). A new flag is 210 proposed in this document in the LSP Attributes Object which extends 211 the L-Flag to identify the protection enforcement. 213 The flag bit is to be allocated by IANA following IETF Consensus. 215 This draft version proposes using the next available bit: {TBD} 216 //Editor note, next available bit at time of writing is bit 6 218 Codespace of the Flag field (LSPA Object) 220 Bit Description Reference 222 7 Local Protection Desired RFC5440 224 Local Protection Enforcement This document 226 The format of the LSPA Object as defined in [RFC5440] is: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Exclude-any | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Include-any | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Include-all | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Setup Prio | Holding Prio | Flags |E|L| Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 // Optional TLVs // 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Flags (8 bits) 246 o L flag: As defined in [RFC5440] and further updated by this 247 document. When set, protection is desired. When not set, 248 protection is not desired. The enforcement of the protection is 249 identified via the E-Flag. 251 o E flag (Protection Enforcement): When set, the value of the L-Flag 252 MUST be treated as a MUST constraint where applicable, when 253 protection state of a SID is known. When E flag is not set, the 254 value of the L-Flag MUST be treated as a MAY constraint. 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 is known to PCE. A PCE 277 calculating a path that includes resources which does not support the 278 protection state being known to PCE (such as Node SID), then the 279 protection state MAY ignore the protection enforcement constraint. 281 5.1. Backwards Compatibility 283 Considerations in the message passing between PCC and PCE for the 284 E-Flag bit which are not supported by the entity are outlined in this 285 section, with requirements for PCE and PCC implementing this document 286 described at the end. 288 For a PCC or PCE which does not yet support this document, the E-flag 289 bit is ignored and set to zero in PCRpt and/or PCUpd as per [RFC5440] 290 for PCC-initiated or as per ([RFC8281]) for PCE-initiated LSPs. It's 291 important to note that [RFC8231] and [RFC8281] permit LSP Attribute 292 Object to be included in PCUpd messages for PCC-initiated and PCE- 293 initiated LSPs. For PCC-initiated LSPs, PCUpd E-Flag (and L-Flag) 294 are an echo from the previous PCRpt however the bit value is ignored 295 on PCE from the previous PCRpt, therefore the E-Flag value set in the 296 PCUpd is zero. A PCE which does not support this document sends 297 PCUpd messages with the E-Flag unset for PCC-initated LSPs even if 298 set in the prior PCReq or PCRpt. A PCC which does not support this 299 document sends PCRpt messages with the E-Flag unset for PCE-initiated 300 LSPs even if set in the prior PCInitiate or PCUpd. 302 For a PCC which does support this document, it MAY set E-Flag bit 303 depending on local configuration. If communicating with a PCE which 304 does not yet support this document, the PCE follows the behaviour 305 specified in [RFC5440] and will ignore the E-Flag bit thus it will 306 not compute a path respecting the enforcement constraint. 308 For PCC-initiated LSPs, PCC SHOULD ignore the E-Flag value received 309 from PCE in a PCUpd message. 311 For PCE-initiated LSPs, PCC MAY process the E-Flag value received 312 from PCE in a PCUpd message. PCE SHOULD ignore the E-Flag value 313 received from PCC in a PCRpt message. 315 6. Implementation Status 317 [Note to the RFC Editor - remove this section before publication, as 318 well as remove the reference to RFC 7942.] 320 This section records the status of known implementations of the 321 protocol defined by this specification at the time of posting of this 322 Internet-Draft, and is based on a proposal described in [RFC7942]. 324 The description of implementations in this section is intended to 325 assist the IETF in its decision processes in progressing drafts to 326 RFCs. Please note that the listing of any individual implementation 327 here does not imply endorsement by the IETF. Furthermore, no effort 328 has been spent to verify the information presented here that was 329 supplied by IETF contributors. This is not intended as, and must not 330 be construed to be, a catalogue of available implementations or their 331 features. Readers are advised to note that other implementations may 332 exist. 334 According to [RFC7942], "this will allow reviewers and working groups 335 to assign due consideration to documents that have the benefit of 336 running code, which may serve as evidence of valuable experimentation 337 and feedback that have made the implemented protocols more mature. 338 It is up to the individual working groups to use this information as 339 they see fit". 341 6.1. Nokia Implementation 343 o Organization: Nokia 345 o Implementation: NSP PCE and SROS PCC. 347 o Description: Implementation for calculation and conveying 348 intention described in this document 350 o Maturity Level: Demo 352 o Coverage: Full 354 o Contact: andrew.stone@nokia.com 356 6.2. Cisco Implementation 358 o Organization: Cisco Systems, Inc. 360 o Implementation: IOS-XR PCE and PCC. 362 o Description: Implementation for calculation and conveying 363 intention described in this document 365 o Maturity Level: Demo 367 o Coverage: Full 369 o Contact: ssidor@cisco.com 371 7. Security Considerations 373 This document clarifies the behaviour of an existing flag and 374 introduces a new flag to provide further control of that existing 375 behaviour. The introduction of this new flag and behaviour 376 clarification does not create any new sensitive information. No 377 additional security measure is required. 379 Securing the PCEP session using Transport Layer Security (TLS) 380 [RFC8253], as per the recommendations and best current practices in 381 [RFC7525] is RECOMMENDED. 383 8. IANA Considerations 385 8.1. LSP Attributes Protection Enforcement Flag 387 This document defines a new LSP Attribute Flag; IANA is requested to 388 make the following bit allocation from the "LSPA Object" sub registry 389 of the PCEP Numbers registry, as follows: 391 Value Name Reference 393 TBD PROTECTION-ENFORCEMENT This document 395 9. References 397 9.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 405 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 406 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 407 . 409 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 410 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 411 DOI 10.17487/RFC4090, May 2005, 412 . 414 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 415 Element (PCE)-Based Architecture", RFC 4655, 416 DOI 10.17487/RFC4655, August 2006, 417 . 419 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 420 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 421 DOI 10.17487/RFC5440, March 2009, 422 . 424 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 425 "Recommendations for Secure Use of Transport Layer 426 Security (TLS) and Datagram Transport Layer Security 427 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 428 2015, . 430 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 431 S. Ray, "North-Bound Distribution of Link-State and 432 Traffic Engineering (TE) Information Using BGP", RFC 7752, 433 DOI 10.17487/RFC7752, March 2016, 434 . 436 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 437 Computation Element Communication Protocol (PCEP) 438 Extensions for Stateful PCE", RFC 8231, 439 DOI 10.17487/RFC8231, September 2017, 440 . 442 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 443 "PCEPS: Usage of TLS to Provide a Secure Transport for the 444 Path Computation Element Communication Protocol (PCEP)", 445 RFC 8253, DOI 10.17487/RFC8253, October 2017, 446 . 448 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 449 Computation Element Communication Protocol (PCEP) 450 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 451 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 452 . 454 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 455 Decraene, B., Litkowski, S., and R. Shakir, "Segment 456 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 457 July 2018, . 459 9.2. Informative References 461 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 462 Code: The Implementation Status Section", BCP 205, 463 RFC 7942, DOI 10.17487/RFC7942, July 2016, 464 . 466 Acknowledgements 468 Thanks to Dhruv Dhody for comments and discussions on this document 469 and Mike Koldychev for reviews. 471 Authors' Addresses 473 Andrew Stone 474 Nokia 476 Email: andrew.stone@nokia.com 478 Mustapha Aissaoui 479 Nokia 481 Email: mustapha.aissaoui@nokia.com 483 Samuel Sidor 484 Cisco Systems, Inc. 486 Email: ssidor@cisco.com 488 Siva Sivabalan 489 Ciena Coroporation 491 Email: ssivabal@ciena.com