idnits 2.17.1 draft-ietf-pce-stateful-path-protection-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2019) is 1674 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-15) exists of draft-ietf-pce-association-diversity-10 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Ananthakrishnan 3 Internet-Draft Netflix 4 Intended status: Standards Track S. Sivabalan 5 Expires: March 28, 2020 Cisco 6 C. Barth 7 Juniper Networks 8 I. Minei 9 Google, Inc 10 M. Negi 11 Huawei Technologies 12 September 25, 2019 14 PCEP Extensions for Associating Working and Protection LSPs with 15 Stateful PCE 16 draft-ietf-pce-stateful-path-protection-11 18 Abstract 20 An active stateful Path Computation Element (PCE) is capable of 21 computing as well as controlling via Path Computation Element 22 Communication Protocol (PCEP) Multiprotocol Label Switching Traffic 23 Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it 24 is also possible for an active stateful PCE to create, maintain, and 25 delete LSPs. This document defines the PCEP extension to associate 26 two or more LSPs to provide end-to-end path protection. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 28, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Path Protection Association Type . . . . . . . . . . . . 5 67 3.2. Path Protection Association TLV . . . . . . . . . . . . . 6 68 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 70 4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 71 4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 72 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 8 73 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 74 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 10 77 6.2. Path Protection Association TLV . . . . . . . . . . . . . 10 78 6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 81 8.1. Control of Function and Policy . . . . . . . . . . . . . 12 82 8.2. Information and Data Models . . . . . . . . . . . . . . . 12 83 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 84 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 85 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 86 8.6. Impact On Network Operations . . . . . . . . . . . . . . 13 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 10.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 [RFC5440] describes Path Computation Element Communication Protocol 97 for communication between a Path Computation Client (PCC) and a PCE 98 or between a pair of PCEs as per [RFC4655]. A PCE computes paths for 99 MPLS-TE Label Switched Paths (LSPs) based on various constraints and 100 optimization criteria. 102 Stateful PCE [RFC8231] specifies a set of extensions to PCEP to 103 enable stateful control of paths such as MPLS-TE LSPs between and 104 across PCEP sessions in compliance with [RFC4657]. It includes 105 mechanisms to affect LSP state synchronization between PCCs and PCEs, 106 delegation of control of LSPs to PCEs, and PCE control of timing and 107 sequence of path computations within and across PCEP sessions. The 108 focus is on a model where LSPs are configured on the PCC and control 109 over them is delegated to the Stateful PCE. Furthermore, [RFC8281] 110 specifies a mechanism to dynamically instantiate LSPs on a PCC based 111 on the requests from a stateful PCE or a controller using stateful 112 PCE. 114 Path protection [RFC4427] refers to a paradigm in which the working 115 LSP is protected by one or more protection LSP(s). When the working 116 LSP fails, protection LSP(s) is/are activated. When the working LSPs 117 are computed and controlled by the PCE, there is benefit in a mode of 118 operation where protection LSPs are also computed and controlled by 119 the same PCE. [RFC8051] describes applicability of path protection 120 in PCE deployments. 122 This document specifies a stateful PCEP extension to associate two or 123 more LSPs for the purpose of setting up path protection. The 124 extension defined in this document covers the following scenarios: 126 o A PCC initiates a protection LSP and retains the control of the 127 LSP. The PCC computes the path itself or makes a request for path 128 computation to a PCE. After the path setup, it reports the 129 information and state of the path to the PCE. This includes the 130 association group identifying the working and protection LSPs. 131 This is the passive stateful mode [RFC8051]. 133 o A PCC initiates a protection LSP and delegates the control of the 134 LSP to a stateful PCE. During delegation the association group 135 identifying the working and protection LSPs is included. The PCE 136 computes the path for the protection LSP and updates the PCC with 137 the information about the path as long as it controls the LSP. 138 This is the active stateful mode [RFC8051]. 140 o A protection LSP could be initiated by a stateful PCE, which 141 retains the control of the LSP. The PCE is responsible for 142 computing the path of the LSP and updating to the PCC with the 143 information about the path. This is the PCE-Initiated mode 144 [RFC8281]. 146 Note that a protection LSP can be established (signaled) before the 147 failure (in which case the LSP is said to be in standby mode 148 [RFC4427] or a Primary LSP [RFC4872]) or after failure of the 149 corresponding working LSP (known as a secondary LSP [RFC4872]). 150 Whether to establish it before or after failure is according to 151 operator choice or policy. 153 [I-D.ietf-pce-association-group] introduces a generic mechanism to 154 create a grouping of LSPs, which can then be used to define 155 associations between a set of LSPs. The mechanism is equally 156 applicable to stateful PCE (active and passive modes) and stateless 157 PCE. 159 This document specifies a PCEP extension to associate one working LSP 160 with one or more protection LSPs using the generic association 161 mechanism. 163 This document describes a PCEP extension to associate protection LSPs 164 by creating Path Protection Association Group (PPAG) and encoding 165 this association in PCEP messages for stateful PCEP sessions. 167 1.1. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 2. Terminology 177 The following terminologies are used in this document: 179 ERO: Explicit Route Object. 181 LSP: Label Switched Path. 183 PCC: Path Computation Client. 185 PCE: Path Computation Element 187 PCEP: Path Computation Element Communication Protocol. 189 PPAG: Path Protection Association Group. 191 TLV: Type, Length, and Value. 193 3. PCEP Extensions 195 3.1. Path Protection Association Type 197 As per [I-D.ietf-pce-association-group], LSPs are not associated by 198 listing the other LSPs with which they interact, but rather by making 199 them belong to an association groups. All LSPs join an association 200 group individually. The generic ASSOCIATION object is used to 201 associate two or more LSPs as specified in 202 [I-D.ietf-pce-association-group]. This document defines a new 203 Association type called "Path Protection Association Type" of value 204 TBD1 and a "Path Protection Association Group" (PPAG). A member LSP 205 of a PPAG can take the role of working or protection LSP. A PPAG can 206 have one working LSP and/or one or more protection LSPs. The source, 207 destination, Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], 208 with description as per [RFC3209]), and Protection Type (PT) (in Path 209 Protection Association TLV) of all LSPs within a PPAG MUST be the 210 same. As per [RFC3209], TE tunnel is used to associate a set of LSPs 211 during reroute or to spread a traffic trunk over multiple paths. 213 The format of the Association object used for PPAG is specified in 214 [I-D.ietf-pce-association-group]. 216 [I-D.ietf-pce-association-group] specifies the mechanism for the 217 capability advertisement of the Association types supported by a PCEP 218 speaker by defining a ASSOC-Type-List TLV to be carried within an 219 OPEN object. This capability exchange for the Association type 220 described in this document (i.e. Path Protection Association Type) 221 MAY be done before using this association, i.e., the PCEP speaker MAY 222 include the Path Protection Association Type (TBD1) in the ASSOC- 223 Type-List TLV before using the PPAG in the PCEP messages. 225 This Association type is dynamic in nature and created by the PCC or 226 PCE for the LSPs belonging to the same TE tunnel (as described in 227 [RFC3209]) originating at the same head node and terminating at the 228 same destination. These associations are conveyed via PCEP messages 229 to the PCEP peer. As per [I-D.ietf-pce-association-group], the 230 association source is set to the local PCEP speaker address that 231 created the association, unless local policy dictates otherwise. 232 Operator-configured Association Range MUST NOT be set for this 233 Association type and MUST be ignored. 235 3.2. Path Protection Association TLV 237 The Path Protection Association TLV is an optional TLV for use in the 238 ASSOCIATION Object with the Path Protection Association Type. The 239 Path Protection Association TLV MUST NOT be present more than once. 240 If it appears more than once, only the first occurrence is processed 241 and any others MUST be ignored. 243 The Path Protection Association TLV follows the PCEP TLV format of 244 [RFC5440]. 246 The type (16 bits) of the TLV is TBD2. The length field (16 bit) has 247 a fixed value of 4. 249 The value comprises of a single field, the Path Protection 250 Association Flags (32 bits), where each bit represents a flag option. 252 The format of the Path Protection Association TLV (Figure 1) is as 253 follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type = TBD2 | Length = 4 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | PT | Unassigned Flags |S|P| 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 1: Path Protection Association TLV format 265 Path Protection Association Flags (32 bits) - The following flags are 266 currently defined - 268 Protecting (P): 1 bit - This bit is as defined in Section 14.1 of 269 [RFC4872] to indicate if the LSP is a working (0) or protection 270 (1) LSP. 272 Secondary (S): 1 bit - This bit is as defined in Section 14.1 of 273 [RFC4872] to indicate if the LSP is a primary (0) or secondary (1) 274 LSP. The S flag is ignored if the P flag is not set. 276 Protection Type (PT): 6 bits - This field is as defined in 277 Section 14.1 of [RFC4872] to indicate the LSP protection type in 278 use. Any type already defined or that could be defined in the 279 future for use in the RSVP-TE PROTECTION object is acceptable in 280 this TLV unless explicitly stated otherwise. 282 Unassigned bits are considered reserved. They MUST be set to 0 on 283 transmission and MUST be ignored on receipt. 285 If the TLV is missing in PPAG ASSOCIATION object, it is considered 286 that the LSP is a working LSP (i.e. as if the P bit is unset). 288 4. Operation 290 An LSP is associated with other LSPs with which it interacts by 291 adding them to a common association group via the ASSOCIATION object. 292 All procedures and error-handling for the ASSOCIATION object is as 293 per [I-D.ietf-pce-association-group]. 295 4.1. State Synchronization 297 During state synchronization, a PCC reports all the existing LSP 298 states as described in [RFC8231]. The association group membership 299 pertaining to an LSP is also reported as per 300 [I-D.ietf-pce-association-group]. This includes PPAGs. 302 4.2. PCC-Initiated LSPs 304 A PCC can associate a set of LSPs under its control for path 305 protection purposes. Similarly, the PCC can remove one or more LSPs 306 under its control from the corresponding PPAG. In both cases, the 307 PCC reports the change in association to PCE(s) via Path Computation 308 Report (PCRpt) messages. A PCC can also delegate the working and 309 protection LSPs to an active stateful PCE, where the PCE would 310 control the LSPs. The stateful PCE could update the paths and 311 attributes of the LSPs in the association group via Path Computation 312 Update (PCUpd) message. A PCE could also update the association to 313 the PCC via PCUpd message. These procedures are described in 314 [I-D.ietf-pce-association-group]. 316 It is expected that both working and protection LSPs are delegated 317 together (and to the same PCE) to avoid any race conditions. Refer 318 to [I-D.litkowski-pce-state-sync] for the problem description. 320 4.3. PCE-Initiated LSPs 322 A PCE can create/update working and protection LSPs independently. 323 As specified in [I-D.ietf-pce-association-group], Association Groups 324 can be created by both the PCE and the PCC. Further, a PCE can 325 remove a protection LSP from a PPAG as specified in 326 [I-D.ietf-pce-association-group]. The PCE uses PCUpd or Path 327 Computation Initiate (PCInitiate) messages to communicate the 328 association information to the PCC. 330 4.4. Session Termination 332 As per [I-D.ietf-pce-association-group] the association information 333 is cleared along with the LSP state information. When a PCEP session 334 is terminated, after expiry of State Timeout Interval at the PCC, the 335 LSP state associated with that PCEP session is reverted to operator- 336 defined default parameters or behaviors as per [RFC8231]. The same 337 procedure is also followed for the association information. On 338 session termination at the PCE, when the LSP state reported by PCC is 339 cleared, the association information is also cleared as per 340 [I-D.ietf-pce-association-group]. Where there are no LSPs in a 341 association group, the association is considered to be deleted. 343 4.5. Error Handling 345 As per the processing rules specified in section 6.4 of 346 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 347 this Path Protection Association Type, it would return a PCErr 348 message with Error-Type 26 "Association Error" and Error-Value 1 349 "Association type is not supported". 351 All LSPs (working or protection) within a PPAG MUST belong to the 352 same TE Tunnel (as described in [RFC3209]) and have the same source 353 and destination. If a PCEP speaker attempts to add or update an LSP 354 to a PPAG and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV 355 [RFC8231], with description as per [RFC3209]) or source or 356 destination of the LSP is different from the LSP(s) in the PPAG, the 357 PCEP speaker MUST send PCErr with Error-Type 26 (Association Error) 358 [I-D.ietf-pce-association-group] and Error-Value TBD3 (Tunnel ID or 359 End points mismatch for Path Protection Association). In case of 360 Path Protection, LSP-IDENTIFIERS TLV SHOULD be included for all LSPs 361 (including Segment Routing (SR) [I-D.ietf-pce-segment-routing]). If 362 the Protection Type (PT) (in Path Protection Association TLV) is 363 different from the LSPs in the PPAG, the PCEP speaker MUST send PCErr 364 with Error-Type 26 (Association Error) 365 [I-D.ietf-pce-association-group] and Error-Value 6 (Association 366 information mismatch) as per [I-D.ietf-pce-association-group]. 368 When the PCEP peer does not support the protection type set in PPAG, 369 the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) 370 [I-D.ietf-pce-association-group] and Error-Value TBD5 (Protection 371 type is not supported). 373 A given LSP MAY belong to more than one PPAG. If there is a conflict 374 between any of the two PPAGs, the PCEP peer MUST send PCErr with 375 Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] 376 and Error-Value 6 (Association information mismatch) as per 377 [I-D.ietf-pce-association-group]. 379 When the protection type is set to 1+1 (i.e., protection type=0x08 or 380 0x10), there MUST be at maximum, only one working LSP and one 381 protection LSP within a PPAG. If a PCEP speaker attempts to add 382 another working/protection LSP, the PCEP peer MUST send PCErr with 383 Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] 384 and Error-Value TBD4 (Attempt to add another working/protection LSP 385 for Path Protection Association). 387 When the protection type is set to 1:N (i.e., protection type=0x04), 388 there MUST be at maximum, only one working LSP and number of 389 protection LSPs MUST NOT be more than N within a PPAG. If a PCEP 390 speaker attempts to add another working/protection LSP, the PCEP peer 391 MUST send PCErr with Error-Type 26 (Association Error) 392 [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add 393 another working/protection LSP for Path Protection Association). 395 During the make-before-break (MBB) procedure, two paths will briefly 396 coexist. The error handling related to number of LSPs allowed in a 397 PPAG MUST NOT be applied during MBB. 399 All processing as per [I-D.ietf-pce-association-group] continues to 400 apply. 402 5. Other Considerations 404 The working and protection LSPs are typically resource disjoint 405 (e.g., node, SRLG disjoint). This ensures that a single failure will 406 not affect both the working and protection LSPs. The disjoint 407 requirement for a group of LSPs is handled via another Association 408 type called "Disjointness Association", as described in 409 [I-D.ietf-pce-association-diversity]. The diversity requirements for 410 the protection LSP are also handled by including both ASSOCIATION 411 objects identifying both the protection association group and the 412 disjoint association group for the group of LSPs. The relationship 413 between the Synchronization VECtor (SVEC) object and the Disjointness 414 Association is described in section 5.3 of 415 [I-D.ietf-pce-association-diversity]. 417 [RFC4872] introduces the concept and mechanisms to support the 418 association of one LSP to another LSP across different RSVP Traffic 419 Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION 420 object. The information in the Path Protection Association TLV in 421 PCEP as received from the PCE is used to trigger the signaling of 422 working LSP and protection LSP, with the Path Protection Association 423 Flags mapped to the corresponding fields in the PROTECTION Object in 424 RSVP-TE. 426 6. IANA Considerations 428 [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain 429 "TBD1" through "TBD5" those should be replaced by the values that 430 IANA assigns.] 432 6.1. Association Type 434 This document defines a new Association type, originally defined in 435 [I-D.ietf-pce-association-group], for path protection. IANA is 436 requested to make the assignment of a new value for the sub-registry 437 "ASSOCIATION Type Field" (request to be created in 438 [I-D.ietf-pce-association-group]), as follows: 440 +----------------------+-------------------------+------------------+ 441 | Association type | Association Name | Reference | 442 | Value | | | 443 +----------------------+-------------------------+------------------+ 444 | TBD1 | Path Protection | This | 445 | | Association | document | 446 +----------------------+-------------------------+------------------+ 448 6.2. Path Protection Association TLV 450 This document defines a new TLV for carrying additional information 451 of LSPs within a path protection association group. IANA is 452 requested to make the assignment of a new value for the existing 453 "PCEP TLV Type Indicators" registry as follows: 455 +---------------+-----------------------------------+---------------+ 456 | TLV Type | TLV Name | Reference | 457 | Value | | | 458 +---------------+-----------------------------------+---------------+ 459 | TBD2 | Path Protection Association Group | This document | 460 | | TLV | | 461 +---------------+-----------------------------------+---------------+ 463 This document requests that a new sub-registry, named "Path 464 protection Association Group TLV Flag Field", is created within the 465 "Path Computation Element Protocol (PCEP) Numbers" registry to manage 466 the Flag field in the Path Protection Association Group TLV. New 467 values are to be assigned by Standards Action [RFC8126]. Each bit 468 should be tracked with the following qualities: 470 o Bit number (count from 0 as the most significant bit) 472 o Name flag 473 o Reference 475 +------------+-----------------------+----------------+ 476 | Bit Number | Name | Reference | 477 +------------+-----------------------+----------------+ 478 | 31 | P - PROTECTION-LSP | This document | 479 | 30 | S - SECONDARY-LSP | This document | 480 | 6-29 | Unassigned | This document | 481 | 0-5 | Protection Type Flags | This document | 482 +------------+-----------------------+----------------+ 484 Table 1: Path Protection Association TLV Flag Field 486 6.3. PCEP Errors 488 This document defines new Error-Values related to path protection 489 association for Error-type 26 "Association Error" defined in 490 [I-D.ietf-pce-association-group]. IANA is requested to allocate new 491 error values within the "PCEP-ERROR Object Error Types and Values" 492 sub-registry of the PCEP Numbers registry, as follows: 494 +---------+----------+-----------------+----------------------------+ 495 | Error- | Error- | Meaning | Reference | 496 | type | value | | | 497 +---------+----------+-----------------+----------------------------+ 498 | 26 | | Association | [I-D.ietf-pce-association- | 499 | | | Error | group] | 500 | | | | | 501 | | TBD3 | Tunnel ID or | This document | 502 | | | End points | | 503 | | | mismatch for | | 504 | | | Path Protection | | 505 | | | Association | | 506 | | TBD4 | Attempt to add | This document | 507 | | | another working | | 508 | | | /protection LSP | | 509 | | | for Path | | 510 | | | Protection | | 511 | | | Association | | 512 | | TBD5 | Protection type | This document | 513 | | | is not | | 514 | | | supported | | 515 +---------+----------+-----------------+----------------------------+ 517 7. Security Considerations 519 The security considerations described in [RFC8231], [RFC8281], and 520 [RFC5440] apply to the extensions described in this document as well. 521 Additional considerations related to associations where a malicious 522 PCEP speaker could be spoofed and could be used as an attack vector 523 by creating associations as described in 524 [I-D.ietf-pce-association-group]. Adding a spurious protection LSP 525 to the Path Protection Association group could give false sense of 526 network reliability, which leads to issues when the working LSP is 527 down and the protection LSP fails as well. Thus securing the PCEP 528 session using Transport Layer Security (TLS) [RFC8253], as per the 529 recommendations and best current practices in BCP 195 [RFC7525], is 530 RECOMMENDED. 532 8. Manageability Considerations 534 8.1. Control of Function and Policy 536 Mechanisms defined in this document do not imply any control or 537 policy requirements in addition to those already listed in [RFC5440], 538 [RFC8231], and [RFC8281]. 540 8.2. Information and Data Models 542 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 543 this document. 545 The PCEP YANG module [I-D.ietf-pce-pcep-yang] supports associations. 547 8.3. Liveness Detection and Monitoring 549 Mechanisms defined in this document do not imply any new liveness 550 detection and monitoring requirements in addition to those already 551 listed in [RFC5440], [RFC8231], and [RFC8281]. 553 8.4. Verify Correct Operations 555 Mechanisms defined in this document do not imply any new operation 556 verification requirements in addition to those already listed in 557 [RFC5440], [RFC8231], and [RFC8281]. 559 8.5. Requirements On Other Protocols 561 Mechanisms defined in this document do not imply any new requirements 562 on other protocols. 564 8.6. Impact On Network Operations 566 Mechanisms defined in this document do not have any impact on network 567 operations in addition to those already listed in [RFC5440], 568 [RFC8231], and [RFC8281]. 570 9. Acknowledgments 572 We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for 573 their contributions to this document. 575 Thanks to Ines Robles for the RTGDIR review. 577 Thanks to Pete Resnick for the GENART review. 579 Thanks to Donald Eastlake for the SECDIR review. 581 Thanks to Barry Leiba, Benjamin Kaduk, Eric Vyncke, and Roman Danyliw 582 for the IESG review. 584 10. References 586 10.1. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 594 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 595 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 596 . 598 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 599 Ed., "RSVP-TE Extensions in Support of End-to-End 600 Generalized Multi-Protocol Label Switching (GMPLS) 601 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 602 . 604 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 605 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 606 DOI 10.17487/RFC5440, March 2009, 607 . 609 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 610 "Recommendations for Secure Use of Transport Layer 611 Security (TLS) and Datagram Transport Layer Security 612 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 613 2015, . 615 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 616 Writing an IANA Considerations Section in RFCs", BCP 26, 617 RFC 8126, DOI 10.17487/RFC8126, June 2017, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 625 Computation Element Communication Protocol (PCEP) 626 Extensions for Stateful PCE", RFC 8231, 627 DOI 10.17487/RFC8231, September 2017, 628 . 630 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 631 "PCEPS: Usage of TLS to Provide a Secure Transport for the 632 Path Computation Element Communication Protocol (PCEP)", 633 RFC 8253, DOI 10.17487/RFC8253, October 2017, 634 . 636 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 637 Computation Element Communication Protocol (PCEP) 638 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 639 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 640 . 642 [I-D.ietf-pce-association-group] 643 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 644 Dhody, D., and Y. Tanaka, "Path Computation Element 645 Communication Protocol (PCEP) Extensions for Establishing 646 Relationships Between Sets of Label Switched Paths 647 (LSPs)", draft-ietf-pce-association-group-10 (work in 648 progress), August 2019. 650 10.2. Informative References 652 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 653 (Protection and Restoration) Terminology for Generalized 654 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 655 DOI 10.17487/RFC4427, March 2006, 656 . 658 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 659 Element (PCE)-Based Architecture", RFC 4655, 660 DOI 10.17487/RFC4655, August 2006, 661 . 663 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 664 Element (PCE) Communication Protocol Generic 665 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 666 2006, . 668 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 669 Hardwick, "Path Computation Element Communication Protocol 670 (PCEP) Management Information Base (MIB) Module", 671 RFC 7420, DOI 10.17487/RFC7420, December 2014, 672 . 674 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 675 Stateful Path Computation Element (PCE)", RFC 8051, 676 DOI 10.17487/RFC8051, January 2017, 677 . 679 [I-D.ietf-pce-pcep-yang] 680 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 681 YANG Data Model for Path Computation Element 682 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 683 yang-12 (work in progress), July 2019. 685 [I-D.ietf-pce-association-diversity] 686 Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 687 "Path Computation Element Communication Protocol (PCEP) 688 Extension for LSP Diversity Constraint Signaling", draft- 689 ietf-pce-association-diversity-10 (work in progress), 690 August 2019. 692 [I-D.ietf-pce-segment-routing] 693 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 694 and J. Hardwick, "PCEP Extensions for Segment Routing", 695 draft-ietf-pce-segment-routing-16 (work in progress), 696 March 2019. 698 [I-D.litkowski-pce-state-sync] 699 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 700 Stateful Path Computation Element (PCE) Communication 701 Procedures.", draft-litkowski-pce-state-sync-06 (work in 702 progress), July 2019. 704 Appendix A. Contributor Addresses 706 Dhruv Dhody 707 Huawei Technologies 708 Divyashree Techno Park, Whitefield 709 Bangalore, Karnataka 560066 710 India 712 EMail: dhruv.ietf@gmail.com 714 Raveendra Torvi 715 Juniper Networks 716 1194 N Mathilda Ave, 717 Sunnyvale, CA, 94086 718 USA 720 EMail: rtorvi@juniper.net 722 Edward Crabbe 723 Individual Contributor 725 EMail: edward.crabbe@gmail.com 727 Authors' Addresses 729 Hariharan Ananthakrishnan 730 Netflix 731 USA 733 Email: hari@netflix.com 735 Siva Sivabalan 736 Cisco 737 2000 Innovation Drive 738 Kananta, Ontaria K2K 3E8 739 Canada 741 Email: msiva@cisco.com 742 Colby Barth 743 Juniper Networks 744 1194 N Mathilda Ave, 745 Sunnyvale, CA, 94086 746 USA 748 Email: cbarth@juniper.net 750 Ina Minei 751 Google, Inc 752 1600 Amphitheatre Parkway 753 Mountain View, CA, 94043 754 USA 756 Email: inaminei@google.com 758 Mahendra Singh Negi 759 Huawei Technologies 760 Divyashree Techno Park, Whitefield 761 Bangalore, Karnataka 560066 762 India 764 Email: mahend.ietf@gmail.com