idnits 2.17.1 draft-ietf-pce-association-bidir-08.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 15, 2020) is 1311 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 (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-13 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-14 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group R. Gandhi, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track C. Barth 5 Expires: March 19, 2021 Juniper Networks 6 B. Wen 7 Comcast 8 September 15, 2020 10 PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) 11 draft-ietf-pce-association-bidir-08 13 Abstract 15 The Path Computation Element Communication Protocol (PCEP) provides 16 mechanisms for Path Computation Elements (PCEs) to perform path 17 computations in response to Path Computation Clients (PCCs) requests. 18 The Stateful PCE extensions allow stateful control of Multiprotocol 19 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 20 (LSPs) using PCEP. 22 This document defines PCEP extensions for grouping two unidirectional 23 MPLS TE LSPs (one in each direction in the network) into an 24 Associated Bidirectional LSP. The mechanisms defined in this 25 document can be applied using a Stateful PCE for both PCE-Initiated 26 and PCC-Initiated LSPs, as well as when using a Stateless PCE. The 27 procedures defined are applicable to the LSPs using Resource 28 Reservation Protocol (RSVP) for signaling. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 19, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Summary of PCEP Extensions . . . . . . . . . . . . . . . 4 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 68 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 71 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 72 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 8 73 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 8 75 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 76 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 11 78 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 11 79 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 12 80 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 12 81 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 12 82 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 13 83 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 84 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 85 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 14 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 8. Manageability Considerations . . . . . . . . . . . . . . . . 14 88 8.1. Control of Function and Policy . . . . . . . . . . . . . 14 89 8.2. Information and Data Models . . . . . . . . . . . . . . . 14 90 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 91 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 92 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 93 8.6. Impact On Network Operations . . . . . . . . . . . . . . 15 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 96 9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 15 97 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 16 98 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 101 10.2. Informative References . . . . . . . . . . . . . . . . . 18 102 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 108 communication mechanism between a Path Computation Client (PCC) and a 109 Path Control Element (PCE), or between PCE and PCC, that enables 110 computation of Multiprotocol Label Switching (MPLS) Traffic 111 Engineering (TE) Label Switched Paths (LSPs). 113 [RFC8231] specifies extensions to PCEP to enable stateful control of 114 MPLS TE LSPs. It describes two modes of operation - Passive Stateful 115 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 116 Stateful PCE where LSPs are provisioned on the PCC and control over 117 them is delegated to a PCE. Further, [RFC8281] describes the setup, 118 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 119 model. 121 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 122 which can then be used to define associations between a set of LSPs 123 and/or a set of attributes, for example primary and secondary LSP 124 associations, and is equally applicable to the active and passive 125 modes of a Stateful PCE [RFC8231] or a stateless PCE [RFC5440]. 127 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 128 specifies that MPLS-TP MUST support associated bidirectional point- 129 to-point LSPs. [RFC7551] defines RSVP signaling extensions for 130 binding two reverse unidirectional LSPs [RFC3209] into an associated 131 bidirectional LSP. The fast reroute (FRR) procedures for associated 132 bidirectional LSPs are described in [RFC8537]. 134 This document defines PCEP extensions for grouping two unidirectional 135 MPLS-TE LSPs into an Associated Bidirectional LSP for both single- 136 sided and double-sided initiation cases when using a Stateful PCE for 137 both PCE-Initiated and PCC-Initiated LSPs as well as when using a 138 Stateless PCE. The procedures defined are applicable to the TE LSPs 139 using Resource Reservation Protocol (RSVP) for signaling [RFC3209]. 140 The procedure for associating two unidirectional Segment Routing (SR) 141 Paths to form an Associated Bidirectional SR Path is defined in 143 [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this 144 document. 146 1.1. Summary of PCEP Extensions 148 The PCEP extensions defined in this document cover the following 149 cases: 151 o A PCC initiates the forward and/ or reverse LSP of a single-sided 152 or double-sided bidirectional LSP and retains the control of the 153 LSP. The PCC computes the path itself or makes a request for path 154 computation to a PCE. After the path setup, it reports the 155 information and state of the path to the PCE. This includes the 156 association group identifying the bidirectional LSP. This is the 157 Passive Stateful mode defined in [RFC8051]. 159 o A PCC initiates the forward and/ or reverse LSP of a single-sided 160 or double-sided bidirectional LSP and delegates the control of the 161 LSP to a Stateful PCE. During delegation the association group 162 identifying the bidirectional LSP is included. The PCE computes 163 the path of the LSP and updates the PCC with the information about 164 the path as long as it controls the LSP. This is the Active 165 Stateful mode defined in [RFC8051]. 167 o A PCE initiates the forward and/ or reverse LSP of a single-sided 168 or double-sided bidirectional LSP on a PCC and retains the control 169 of the LSP. The PCE is responsible for computing the path of the 170 LSP and updating the PCC with the information about the path as 171 well as the association group identifying the bidirectional LSP. 172 This is the PCE-Initiated mode defined in [RFC8281]. 174 o A PCC requests co-routed or non-co-routed paths for forward and 175 reverse LSPs of a bidirectional LSP from a Stateless PCE 176 [RFC5440]. 178 2. Conventions Used in This Document 180 2.1. Key Word Definitions 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 2.2. Terminology 190 The reader is assumed to be familiar with the terminology defined in 191 [RFC5440], [RFC7551], [RFC8231], and [RFC8697]. 193 3. Overview 195 As shown in Figure 1, two reverse unidirectional LSPs can be grouped 196 to form an associated bidirectional LSP. There are two methods of 197 initiating the bidirectional LSP association, single-sided and 198 double-sided, as defined in [RFC7551] and described in the following 199 sections. 201 LSP1 --> LSP1 --> LSP1 --> 202 +-----+ +-----+ +-----+ +-----+ 203 | A +-----------+ B +-----------+ C +-----------+ D | 204 +-----+ +--+--+ +--+--+ +-----+ 205 <-- LSP2 | | <-- LSP2 206 | | 207 | | 208 +--+--+ +--+--+ 209 | E +-----------+ F | 210 +-----+ +-----+ 211 <-- LSP2 213 Figure 1: Example of Associated Bidirectional LSP 215 3.1. Single-sided Initiation 217 As specified in [RFC7551], in the single-sided case, the 218 bidirectional tunnel is provisioned only on one endpoint node (PCC) 219 of the tunnel. Both forward and reverse LSPs of this tunnel are 220 initiated with the Association Type set to "Single-sided 221 Bidirectional LSP Association" on the originating endpoint node. The 222 forward and reverse LSPs are identified in the Bidirectional LSP 223 Association Group TLV of their PCEP ASSOCIATION Objects. 225 The originating endpoint node signals the properties for the revere 226 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 227 message. The remote endpoint then creates the corresponding reverse 228 tunnel and signals the reverse LSP in response to the received RSVP 229 Path message. Similarly, the remote endpoint node deletes the 230 reverse LSP when it receives the RSVP Path delete message [RFC3209] 231 for the forward LSP. 233 The originating endpoint (PCC) node may report/ delegate the forward 234 and reverse direction LSPs to a PCE. The remote endpoint (PCC) node 235 may report its forward direction LSP to a PCE. 237 +-----+ 238 | PCE | 239 +-----+ 240 Initiates: | \ 241 Tunnel 1 (F) | \ 242 (LSP1 (F, 0), LSP2 (R, 0)) | \ 243 Association #1 v \ 244 +-----+ +-----+ 245 | A | | D | 246 +-----+ +-----+ 248 +-----+ 249 | PCE | 250 +-----+ 251 Reports: ^ ^ Reports: 252 Tunnel 1 (F) | \ Tunnel 2 (F) 253 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 254 Association #1 | \ Association #1 255 +-----+ +-----+ 256 | A | | D | 257 +-----+ +-----+ 259 Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP 261 +-----+ 262 | PCE | 263 +-----+ 264 Reports/Delegates: ^ ^ Reports: 265 Tunnel 1 (F) | \ Tunnel 2 (F) 266 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 267 Association #2 | \ Association #2 268 +-----+ +-----+ 269 | A | | D | 270 +-----+ +-----+ 272 Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP 274 As shown in Figures 2 and 3, the forward tunnel and both forward LSP1 275 and reverse LSP2 are initiated on the originating endpoint node A, 276 either by the PCE or the originating PCC, respectively. The 277 originating endpoint node A signals the properties of reverse LSP2 in 278 the RSVP REVERSE_LSP Object in the Path message of the forward LSP1. 279 The creation of reverse tunnel and reverse LSP2 on the remote 280 endpoint node D is triggered by the RSVP signaled forward LSP1. 281 PLSP-IDs used are shown in the Figures as P1, P2 and P3. 283 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 284 the LSP starting from the originating node is identified as the 285 forward LSP of the single-sided initiated bidirectional LSP. 287 3.2. Double-sided Initiation 289 As specified in [RFC7551], in the double-sided case, the 290 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 291 the tunnel. The forward and reverse LSPs of this tunnel are 292 initiated with the Association Type set to "Double-sided 293 Bidirectional LSP Association" on both endpoint nodes. The forward 294 and reverse LSPs are identified in the Bidirectional LSP Association 295 Group TLV of their ASSOCIATION Objects. 297 The endpoint (PCC) nodes may report/ delegate the forward and reverse 298 direction LSPs to a PCE. 300 +-----+ 301 | PCE | 302 +-----+ 303 Initiates: | \ Initiates: 304 Tunnel 1 (F) | \ Tunnel 2 (F) 305 (LSP1 (F, 0)) | \ (LSP2 (F, 0)) 306 Association #3 v v Association #3 307 +-----+ +-----+ 308 | A | | D | 309 +-----+ +-----+ 311 +-----+ 312 | PCE | 313 +-----+ 314 Reports: ^ ^ Reports: 315 Tunnel 1 (F) | \ Tunnel 2 (F) 316 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 317 Association #3 | \ Association #3 318 +-----+ +-----+ 319 | A | | D | 320 +-----+ +-----+ 322 Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP 323 +-----+ 324 | PCE | 325 +-----+ 326 Reports/Delegates: ^ ^ Reports/Delegates: 327 Tunnel 1 (F) | \ Tunnel 2 (F) 328 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 329 Association #4 | \ Association #4 330 +-----+ +-----+ 331 | A | | D | 332 +-----+ +-----+ 334 Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP 336 As shown in Figures 4 and 5, the forward tunnel and forward LSP1 are 337 initiated on the endpoint node A and the reverse tunnel and reverse 338 LSP2 are initiated on the endpoint node D, either by the PCE or the 339 PCCs, respectively. PLSP-IDs used are shown in the Figures as P4 and 340 P5. 342 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 343 the LSP with the higher Source Address [RFC3209] is identified as the 344 forward LSP of the double-sided initiated bidirectional LSP. 346 3.3. Co-routed Associated Bidirectional LSP 348 In both single-sided and double-sided initiation cases, forward and 349 reverse LSPs may be co-routed as shown in Figure 6, where both 350 forward and reverse LSPs of a bidirectional LSP follow the same 351 congruent path in the forward and reverse directions, respectively. 353 LSP3 --> LSP3 --> LSP3 --> 354 +-----+ +-----+ +-----+ +-----+ 355 | A +-----------+ B +-----------+ C +-----------+ D | 356 +-----+ +-----+ +-----+ +-----+ 357 <-- LSP4 <-- LSP4 <-- LSP4 359 Figure 6: Example of Co-routed Associated Bidirectional LSP 361 4. Protocol Extensions 363 4.1. ASSOCIATION Object 365 As per [RFC8697], LSPs are associated by adding them to a common 366 association group. This document defines two new Bidirectional LSP 367 Association Groups to be used by the associated bidirectional LSPs. 368 A member of the Bidirectional LSP Association Group can take the role 369 of a forward or reverse LSP and follows the following rules: 371 o An LSP (forward or reverse) cannot be part of more than one 372 Bidirectional LSP Association Group. More than one forward LSP 373 and/ or reverse LSP can be part of a Bidirectional LSP Association 374 Group. 376 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 377 of the Single-sided Bidirectional LSP Association on the 378 originating node MUST be the same. 380 This document defines two new Association Types for the ASSOCIATION 381 Object (Object-Class value 40) as follows: 383 o Association Type (TBD1) = Single-sided Bidirectional LSP 384 Association Group 386 o Association Type (TBD2) = Double-sided Bidirectional LSP 387 Association Group 389 These Association Types are operator-configured associations in 390 nature and statically created by the operator on the PCEP peers. 391 'Operator-configured Association Range' TLV (Value 29) [RFC8697] MUST 392 NOT be sent for these Association Types, and MUST be ignored, so that 393 the entire range of association ID can be used for them. 395 The Association ID, Association Source, optional Global Association 396 Source and optional Extended Association ID in the Bidirectional LSP 397 Association Group Object are initialized using the procedures defined 398 in [RFC8697] and [RFC7551]. 400 4.2. Bidirectional LSP Association Group TLV 402 The Bidirectional LSP Association Group TLV is defined for use with 403 the Single-sided and Double-sided Bidirectional LSP Association Group 404 Object Types. 406 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 407 format from [RFC5440]. 409 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 411 o The Length is 4 Bytes. 413 o The value comprises of a single field, the Bidirectional LSP 414 Association Flag (32 bits), where each bit represents a flag 415 option. 417 o If the Bidirectional LSP Association Group TLV is missing, it 418 means the LSP is the forward LSP and it is not co-routed LSP. 420 o For co-routed LSPs, this TLV MUST be present. 422 o For reverse LSPs, this TLV MUST be present. 424 o The Bidirectional LSP Association Group TLV MUST NOT be present 425 more than once. If it appears more than once, only the first 426 occurrence is processed and any others MUST be ignored. 428 The format of the Bidirectional LSP Association Group TLV is shown in 429 Figure 7: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type = TBD3 | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Reserved |C|R|F| 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Figure 7: Bidirectional LSP Association Group TLV format 441 Flags for Bidirectional LSP Association Group TLV are defined as 442 following. 444 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 445 forward LSP of the bidirectional LSP. If this flag is set, the LSP 446 is a forward LSP. 448 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 449 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 450 is a reverse LSP. 452 C (Co-routed Path, 1 bit) - Indicates whether the bidirectional LSP 453 is co-routed. This flag MUST be set for both the forward and reverse 454 LSPs of a co-routed bidirectional LSP. 456 The C flag is used by the PCE (for both Stateful and Stateless) to 457 compute bidirectional paths of the forward and reverse LSPs of a co- 458 routed bidirectional LSP. 460 The Reserved flags MUST be set to 0 when sent and MUST be ignored 461 when received. 463 5. PCEP Procedure 464 5.1. PCE Initiated LSPs 466 As specified in [RFC8697], the Bidirectional LSP Association Groups 467 can be created by a Stateful PCE. 469 o Stateful PCE can create and update the forward and reverse LSPs 470 independently for both Single-sided and Double-sided Bidirectional 471 LSP Association Groups. 473 o Stateful PCE can establish and remove the association relationship 474 on a per LSP basis. 476 o Stateful PCE can create and update the LSP and the association on 477 a PCC via PCInitiate and PCUpd messages, respectively, using the 478 procedures described in [RFC8697]. 480 5.2. PCC Initiated LSPs 482 As specified in [RFC8697], Bidirectional LSP Association Groups can 483 also be created by a PCC. 485 o PCC can create and update the forward and reverse LSPs 486 independently for both Single-sided and Double-sided Bidirectional 487 LSP Association Groups. 489 o PCC can establish and remove the association relationship on a per 490 LSP basis. 492 o PCC MUST report the change in the association group of an LSP to 493 PCE(s) via PCRpt message. 495 o PCC can report the forward and reverse LSPs independently to 496 PCE(s) via PCRpt message. 498 o PCC can delegate the forward and reverse LSPs independently to a 499 Stateful PCE, where PCE would control the LSPs. For single-sided 500 case, originating (PCC) node can delegate both forward and reverse 501 LSPs of a tunnel together to a Stateful PCE in order to avoid any 502 race condition. 504 o Stateful PCE can update the LSPs in the Bidirectional LSP 505 Association Group via PCUpd message, using the procedures 506 described in [RFC8697]. 508 5.3. Stateless PCE 510 For a stateless PCE, it might be useful to associate a path 511 computation request to an association group, thus enabling it to 512 associate a common set of configuration parameters or behaviors with 513 the request. A PCC can request co-routed or non-co-routed forward 514 and reverse direction paths from a stateless PCE for a Bidirectional 515 LSP Association Group. 517 5.4. Bidirectional (B) Flag 519 As defined in [RFC5440], the Bidirectional (B) flag in the Request 520 Parameters (RP) object is set when the PCC specifies that the path 521 computation request is for a bidirectional TE LSP with the same TE 522 requirements in each direction. For an associated bidirectional LSP, 523 the B-flag is also set when the PCC makes the path computation 524 request for the same TE requirements for the forward and reverse 525 direction LSPs. 527 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 528 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate 529 'bidirectional co-routed LSP' is used for GMPLS signaled 530 bidirectional LSPs and is not applicable to the associated 531 bidirectional LSPs. 533 5.5. PLSP-ID Usage 535 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 536 created by a PCC to uniquely identify an LSP and it remains the same 537 for the lifetime of a PCEP session. 539 In case of Single-sided Bidirectional LSP Association, the reverse 540 LSP of a bidirectional LSP created on the originating node is 541 identified by the PCE using 2 different PLSP-IDs based on the PCEP 542 session on the ingress or egress nodes for the LSP. In other words, 543 the reverse LSP will have a PLSP-ID P1 at the ingress node while it 544 will have a PLSP-ID P3 at the egress node. There is no change in the 545 PLSP-ID allocation procedure for the forward LSP of the Single-sided 546 Bidirectional LSP on the originating node. In case of Double-sided 547 Bidirectional LSP Association, there is no change in the PLSP-ID 548 allocation procedure. 550 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 551 MUST be included in all forward and reverse LSPs. 553 5.6. State Synchronization 555 During state synchronization, a PCC MUST report all the existing 556 Bidirectional LSP Association Groups to the Stateful PCE as per 557 [RFC8697]. After the state synchronization, the PCE MUST remove all 558 stale Bidirectional LSP Associations. 560 5.7. Error Handling 562 An LSP (forward or reverse) cannot be part of more than one 563 Bidirectional LSP Association Group. If a PCE attempts to add an LSP 564 not complying to this rule, the PCC MUST send PCErr with Error-Type = 565 26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP 566 Association - Group Mismatch). Similarly, if a PCC attempts to add 567 an LSP at PCE not complying to this rule, the PCE MUST send this 568 PCErr. 570 The LSPs (forward or reverse) in a Single-sided Bidirectional 571 Association Group MUST belong to the same TE Tunnel (as defined in 572 [RFC3209]). If a PCE attempts to add an LSP in a Single-sided 573 Bidirectional LSP Association Group for a different Tunnel, the PCC 574 MUST send PCErr with Error-Type = 26 (Association Error) and Error- 575 Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 576 Similarly, if a PCC attempts to add an LSP to a Single-sided 577 Bidirectional LSP Association Group at PCE not complying to this 578 rule, the PCE MUST send this PCErr. 580 The PCEP Path Setup Type (PST) for RSVP is set to 'Path is set up 581 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP 582 speaker receives a different PST value for the Bidirectional LSP 583 Association Groups defined in this document and it does not support; 584 it MUST return a PCErr message with Error-Type = 26 (Association 585 Error) and Error-Value = TBD6 (Bidirectional LSP Association - Path 586 Setup Type Not Supported). 588 The processing rules as specified in Section 6.4 of [RFC8697] 589 continue to apply to the Association Types defined in this document. 591 6. Implementation Status 593 [Note to the RFC Editor - remove this section before publication, as 594 well as remove the reference to RFC 7942.] 596 This section records the status of known implementations of the 597 protocol defined by this specification at the time of posting of this 598 Internet-Draft, and is based on a proposal described in [RFC7942]. 599 The description of implementations in this section is intended to 600 assist the IETF in its decision processes in progressing drafts to 601 RFCs. Please note that the listing of any individual implementation 602 here does not imply endorsement by the IETF. Furthermore, no effort 603 has been spent to verify the information presented here that was 604 supplied by IETF contributors. This is not intended as, and must not 605 be construed to be, a catalog of available implementations or their 606 features. Readers are advised to note that other implementations may 607 exist. 609 According to [RFC7942], "this will allow reviewers and working groups 610 to assign due consideration to documents that have the benefit of 611 running code, which may serve as evidence of valuable experimentation 612 and feedback that have made the implemented protocols more mature. 613 It is up to the individual working groups to use this information as 614 they see fit". 616 6.1. Implementation 618 The PCEP extensions defined in this document has been implemented by 619 a vendor on their product. No further information is available at 620 this time. 622 7. Security Considerations 624 The security considerations described in [RFC5440], [RFC8231], and 625 [RFC8281] apply to the extensions defined in this document as well. 627 Two new Association Types for the ASSOCIATION Object, Single-sided 628 Bidirectional LSP Association Group and Double-sided Bidirectional 629 LSP Association Group are introduced in this document. Additional 630 security considerations related to LSP associations due to a 631 malicious PCEP speaker is described in [RFC8697] and apply to these 632 Association Types. Hence, securing the PCEP session using Transport 633 Layer Security (TLS) [RFC8253] is recommended. 635 8. Manageability Considerations 637 8.1. Control of Function and Policy 639 The mechanisms defined in this document do not imply any control or 640 policy requirements in addition to those already listed in [RFC5440], 641 [RFC8231], and [RFC8281]. 643 8.2. Information and Data Models 645 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 646 defined for LSP associations. 648 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 649 LSP associations. 651 8.3. Liveness Detection and Monitoring 653 The mechanisms defined in this document do not imply any new liveness 654 detection and monitoring requirements in addition to those already 655 listed in [RFC5440], [RFC8231], and [RFC8281]. 657 8.4. Verify Correct Operations 659 The mechanisms defined in this document do not imply any new 660 operation verification requirements in addition to those already 661 listed in [RFC5440], [RFC8231], and [RFC8281]. 663 8.5. Requirements On Other Protocols 665 The mechanisms defined in this document do not add any new 666 requirements on other protocols. 668 8.6. Impact On Network Operations 670 The mechanisms defined in this document do not have any impact on 671 network operations in addition to those already listed in [RFC5440], 672 [RFC8231], and [RFC8281]. 674 9. IANA Considerations 676 9.1. Association Types 678 This document adds new Association Types for the ASSOCIATION Object 679 (Object-class value 40) defined [RFC8697]. IANA is requested to make 680 the assignment of values for the sub-registry "ASSOCIATION Type" 681 [RFC8697], as follows: 683 Type Name Reference 684 --------------------------------------------------------------------- 685 TBD1 Single-sided Bidirectional LSP Association Group [This document] 686 TBD2 Double-sided Bidirectional LSP Association Group [This document] 688 9.2. Bidirectional LSP Association Group TLV 690 This document defines a new TLV for carrying additional information 691 of LSPs within a Bidirectional LSP Association Group. IANA is 692 requested to add the assignment of a new value in the existing "PCEP 693 TLV Type Indicators" registry as follows: 695 Value Meaning Reference 696 ------------------------------------------------------------------- 697 TBD3 Bidirectional LSP Association Group TLV [This document] 699 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 701 This document requests that a new sub-registry, named "Bidirectional 702 LSP Association Group TLV Flag Field", is created within the "Path 703 Computation Element Protocol (PCEP) Numbers" registry to manage the 704 Flag field in the Bidirectional LSP Association Group TLV. New 705 values are to be assigned by Standards Action [RFC8126]. Each bit 706 should be tracked with the following qualities: 708 o Bit number (count from 0 as the most significant bit) 710 o Description 712 o Reference 714 The following values are defined in this document for the Flag field. 716 Bit No. Description Reference 717 --------------------------------------------------------- 718 31 F - Forward LSP [This document] 719 30 R - Reverse LSP [This document] 720 29 C - Co-routed Path [This document] 722 9.3. PCEP Errors 724 This document defines new Error value for Error Type 26 (Association 725 Error). IANA is requested to allocate new Error value within the 726 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 727 Numbers registry, as follows: 729 Error Type Description Reference 730 --------------------------------------------------------- 731 26 Association Error 733 Error value: TBD4 [This document] 734 Bidirectional LSP Association - Group Mismatch 736 Error value: TBD5 [This document] 737 Bidirectional LSP Association - Tunnel Mismatch 739 Error value: TBD6 [This document] 740 Bidirectional LSP Association - Path Setup Type 741 Not Supported 743 10. References 745 10.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, 749 DOI 10.17487/RFC2119, March 1997, 750 . 752 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 753 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 754 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 755 . 757 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 758 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 759 DOI 10.17487/RFC5440, March 2009, 760 . 762 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 763 Extensions for Associated Bidirectional Label Switched 764 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 765 . 767 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 768 Writing an IANA Considerations Section in RFCs", BCP 26, 769 RFC 8126, DOI 10.17487/RFC8126, June 2017, 770 . 772 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 773 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 774 May 2017, . 776 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 777 Computation Element Communication Protocol (PCEP) 778 Extensions for Stateful PCE", RFC 8231, 779 DOI 10.17487/RFC8231, September 2017, 780 . 782 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 783 Computation Element Communication Protocol (PCEP) 784 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 785 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 786 . 788 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 789 the Fast Reroute Procedures for Co-routed Associated 790 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 791 DOI 10.17487/RFC8537, February 2019, 792 . 794 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 795 Dhody, D., and Y. Tanaka, "Path Computation Element 796 Communication Protocol (PCEP) Extensions for Establishing 797 Relationships between Sets of Label Switched Paths 798 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 799 . 801 10.2. Informative References 803 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 804 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 805 Ali, "Path Computation Element (PCE) Protocol Extensions 806 for Stateful PCE Usage in GMPLS-controlled Networks", 807 draft-ietf-pce-pcep-stateful-pce-gmpls-13 (work in 808 progress), April 2020. 810 [I-D.ietf-pce-pcep-yang] 811 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 812 YANG Data Model for Path Computation Element 813 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 814 yang-14 (work in progress), July 2020. 816 [I-D.ietf-pce-sr-bidir-path] 817 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 818 "PCEP Extensions for Associated Bidirectional Segment 819 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 820 in progress), March 2020. 822 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 823 Sprecher, N., and S. Ueno, "Requirements of an MPLS 824 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 825 September 2009, . 827 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 828 Hardwick, "Path Computation Element Communication Protocol 829 (PCEP) Management Information Base (MIB) Module", 830 RFC 7420, DOI 10.17487/RFC7420, December 2014, 831 . 833 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 834 Code: The Implementation Status Section", BCP 205, 835 RFC 7942, DOI 10.17487/RFC7942, July 2016, 836 . 838 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 839 Stateful Path Computation Element (PCE)", RFC 8051, 840 DOI 10.17487/RFC8051, January 2017, 841 . 843 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 844 "PCEPS: Usage of TLS to Provide a Secure Transport for the 845 Path Computation Element Communication Protocol (PCEP)", 846 RFC 8253, DOI 10.17487/RFC8253, October 2017, 847 . 849 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 850 Hardwick, "Conveying Path Setup Type in PCE Communication 851 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 852 July 2018, . 854 Acknowledgments 856 The authors would like to thank Dhruv Dhody for various discussions 857 on association groups and inputs to this document. The authors would 858 also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for 859 reviewing this document and providing valuable comments. 861 Authors' Addresses 863 Rakesh Gandhi (editor) 864 Cisco Systems, Inc. 865 Canada 867 Email: rgandhi@cisco.com 868 Colby Barth 869 Juniper Networks 871 Email: cbarth@juniper.net 873 Bin Wen 874 Comcast 876 Email: Bin_Wen@cable.comcast.com