idnits 2.17.1 draft-ietf-pce-association-bidir-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 (January 29, 2021) is 1177 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-14 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-05 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: August 2, 2021 Juniper Networks 6 B. Wen 7 Comcast 8 January 29, 2021 10 Path Computation Element Communication Protocol (PCEP) Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-11 14 Abstract 16 The Path Computation Element Communication Protocol (PCEP) provides 17 mechanisms for Path Computation Elements (PCEs) to perform path 18 computations in response to Path Computation Clients (PCCs) requests. 19 The Stateful PCE extensions allow stateful control of Multiprotocol 20 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 21 (LSPs) using PCEP. 23 This document defines PCEP extensions for grouping two unidirectional 24 MPLS TE LSPs (one in each direction in the network) into an 25 Associated Bidirectional LSP. The mechanisms defined in this 26 document can be applied using a Stateful PCE for both PCE-Initiated 27 and PCC-Initiated LSPs, as well as when using a Stateless PCE. The 28 procedures defined are applicable to the LSPs using Resource 29 Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 2, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 68 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 71 3.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5 72 3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6 73 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 74 3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7 75 3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8 76 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9 77 3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 10 78 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10 80 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 12 81 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 13 83 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14 84 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15 85 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15 86 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 15 87 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16 88 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 89 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 90 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 93 8.1. Control of Function and Policy . . . . . . . . . . . . . 18 94 8.2. Information and Data Models . . . . . . . . . . . . . . . 18 95 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 96 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 97 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 98 8.6. Impact On Network Operations . . . . . . . . . . . . . . 18 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 9.1. Association Types . . . . . . . . . . . . . . . . . . . . 19 101 9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 19 102 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 19 103 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 20 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 106 10.2. Informative References . . . . . . . . . . . . . . . . . 22 107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 110 1. Introduction 112 [RFC5440] describes the Path Computation Element Communication 113 Protocol (PCEP) as a communication mechanism between a Path 114 Computation Client (PCC) and a Path Control Element (PCE), or between 115 PCE and PCC, that enables computation of Multiprotocol Label 116 Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 117 (LSPs). 119 [RFC8231] specifies extensions to PCEP to enable stateful control of 120 MPLS TE LSPs. It describes two modes of operation - Passive Stateful 121 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 122 Stateful PCE where LSPs are provisioned on the PCC and control over 123 them is delegated to a PCE. Further, [RFC8281] describes the setup, 124 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 125 model. 127 [RFC8697] introduces a generic mechanism to create a grouping of 128 LSPs. This grouping can then be used to define associations between 129 sets of LSPs or between a set of LSPs and a set of attributes, and it 130 is equally applicable to the stateful PCE (active and passive modes) 131 and the stateless PCE. 133 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 134 specifies that "MPLS-TP MUST support unidirectional, co-routed 135 bidirectional, and associated bidirectional point-to-point transport 136 paths". [RFC7551] defines RSVP signaling extensions for binding 137 forward and reverse unidirectional LSPs into an associated 138 bidirectional LSP. The fast reroute (FRR) procedures for associated 139 bidirectional LSPs are described in [RFC8537]. 141 This document defines PCEP extensions for grouping two unidirectional 142 MPLS-TE LSPs into an Associated Bidirectional LSP for both single- 143 sided and double-sided initiation cases when using a Stateful PCE for 144 both PCE-Initiated and PCC-Initiated LSPs as well as when using a 145 Stateless PCE. The procedures defined are applicable to the LSPs 146 using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 147 for signaling [RFC3209]. Specifically, this document defines two new 148 Association Types, "Single-sided Bidirectional LSP Association" and 149 "Double-sided Bidirectional LSP Association", as well as 150 "Bidirectional LSP Association Group TLV" to carry additional 151 information for the association. 153 The procedure for associating two unidirectional Segment Routing (SR) 154 Paths to form an Associated Bidirectional SR Path is defined in 155 [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this 156 document. 158 2. Conventions Used in This Document 160 2.1. Key Word Definitions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 2.2. Terminology 170 The reader is assumed to be familiar with the terminology defined in 171 [RFC5440], [RFC7551], [RFC8231], and [RFC8697]. 173 3. Overview 175 As shown in Figure 1, forward and reverse unidirectional LSPs can be 176 grouped to form an associated bidirectional LSP. The node A is 177 ingress node for LSP1 and egress node for LSP2, whereas node D is 178 ingress node for LSP2 and egress node for LSP1. There are two 179 methods of initiating the bidirectional LSP association, single-sided 180 and double-sided, as defined in [RFC7551] and described in the 181 following sections. 183 LSP1 --> LSP1 --> LSP1 --> 184 +-----+ +-----+ +-----+ +-----+ 185 | A +-----------+ B +-----------+ C +-----------+ D | 186 +-----+ +--+--+ +--+--+ +-----+ 187 <-- LSP2 | | <-- LSP2 188 | | 189 | | 190 +--+--+ +--+--+ 191 | E +-----------+ F | 192 +-----+ +-----+ 193 <-- LSP2 195 Figure 1: Example of Associated Bidirectional LSP 197 3.1. Single-sided Initiation 199 As specified in [RFC7551], in the single-sided case, the 200 bidirectional tunnel is provisioned only on one endpoint node (PCC) 201 of the tunnel. Both endpoint nodes act as a PCC. Both forward and 202 reverse LSPs of this tunnel are initiated with the Association Type 203 set to "Single-sided Bidirectional LSP Association" on the 204 originating endpoint node. The forward and reverse LSPs are 205 identified in the "Bidirectional LSP Association Group TLV" of their 206 PCEP ASSOCIATION Objects. 208 The originating endpoint node signals the properties for the reverse 209 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 210 message. The remote endpoint node then creates the corresponding 211 reverse tunnel and reverse LSP, and signals the reverse LSP in 212 response to the received RSVP-TE Path message. Similarly, the remote 213 endpoint node deletes the reverse LSP when it receives the RSVP-TE 214 message to delete the forward LSP [RFC3209]. 216 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 217 the LSP starting from the originating endpoint node is identified as 218 the forward LSP of the single-sided initiated bidirectional LSP. 220 3.1.1. PCE-Initiated Single-sided Bidirectional LSP 221 +-----+ 222 | PCE | 223 +-----+ 224 Initiates: | \ 225 Tunnel 1 (F) | \ 226 (LSP1 (F, 0), LSP2 (R, 0)) | \ 227 Association #1 v \ 228 +-----+ +-----+ 229 | A | | D | 230 +-----+ +-----+ 232 +-----+ 233 | PCE | 234 +-----+ 235 Reports: ^ ^ Reports: 236 Tunnel 1 (F) | \ Tunnel 2 (F) 237 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 238 Association #1 | \ Association #1 239 +-----+ +-----+ 240 | A | | D | 241 +-----+ +-----+ 243 Legends: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs 245 Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP 247 As shown in Figure 2, the forward tunnel 1 and both forward LSP1 and 248 reverse LSP2 are initiated on the originating endpoint node A by the 249 PCE. The PLSP-IDs used are P1 and P2 on the originating endpoint 250 node A and P3 on the remote endpoint node D. The originating 251 endpoint node A reports tunnels 1 and forward LSP1 and reverse LSP2 252 to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to 253 the PCE. The endpoint (PCC) node D also reports the reverse LSP1 254 (not shown for simplicity) to the PCE. 256 3.1.2. PCC-Initiated Single-sided Bidirectional LSP 257 +-----+ 258 | PCE | 259 +-----+ 260 Reports/Delegates: ^ ^ Reports: 261 Tunnel 1 (F) | \ Tunnel 2 (F) 262 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 263 Association #2 | \ Association #2 264 +-----+ +-----+ 265 | A | | D | 266 +-----+ +-----+ 268 Legends: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs 270 Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP 272 As shown in Figure 3, the forward tunnel 1 and both forward LSP1 and 273 reverse LSP2 are initiated on the originating endpoint node A (the 274 originating PCC). The PLSP-IDs used are P1 and P2 on the originating 275 endpoint node A and P3 on the remote endpoint node D. The 276 originating endpoint (PCC) node A may delegate the forward LSP1 and 277 reverse LSP2 to the PCE. The originating endpoint node A reports 278 tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint 279 (PCC) node D reports tunnel 2 and LSP2 to the PCE. The endpoint 280 (PCC) node D also reports the reverse LSP1 (not shown for simplicity) 281 to the PCE. 283 3.2. Double-sided Initiation 285 As specified in [RFC7551], in the double-sided case, the 286 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 287 the tunnel. The forward and reverse LSPs of this tunnel are 288 initiated with the Association Type set to "Double-sided 289 Bidirectional LSP Association" on both endpoint nodes. The forward 290 and reverse LSPs are identified in the "Bidirectional LSP Association 291 Group TLV" of their ASSOCIATION Objects. 293 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 294 the LSP with the higher Source Address [RFC3209] is identified as the 295 forward LSP of the double-sided initiated bidirectional LSP. 297 3.2.1. PCE-Initiated Double-sided Bidirectional LSP 298 +-----+ 299 | PCE | 300 +-----+ 301 Initiates: | \ Initiates: 302 Tunnel 1 (F) | \ Tunnel 2 (F) 303 (LSP1 (F, 0)) | \ (LSP2 (F, 0)) 304 Association #3 v v Association #3 305 +-----+ +-----+ 306 | A | | D | 307 +-----+ +-----+ 309 +-----+ 310 | PCE | 311 +-----+ 312 Reports: ^ ^ Reports: 313 Tunnel 1 (F) | \ Tunnel 2 (F) 314 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 315 Association #3 | \ Association #3 316 +-----+ +-----+ 317 | A | | D | 318 +-----+ +-----+ 320 Legends: F = Forward LSP, (0,P4,P5) = PLSP-IDs 322 Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP 324 As shown in Figure 4, the forward tunnel 1 and forward LSP1 are 325 initiated on the endpoint node A and the reverse tunnel 2 and reverse 326 LSP2 are initiated on the endpoint node D by the PCE. The PLSP-IDs 327 used are P4 on the endpoint node A and P5 on the endpoint node D. 328 The endpoint node A (PCC) reports the forward LSP1 and endpoint node 329 D reports the forward LSP2 to the PCE. Both endpoint (PCC) nodes 330 also report the reverse LSPs (not shown for simplicity) to the PCE. 332 3.2.2. PCC-Initiated Double-sided Bidirectional LSP 333 +-----+ 334 | PCE | 335 +-----+ 336 Reports/Delegates: ^ ^ Reports/Delegates: 337 Tunnel 1 (F) | \ Tunnel 2 (F) 338 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 339 Association #4 | \ Association #4 340 +-----+ +-----+ 341 | A | | D | 342 +-----+ +-----+ 344 Legends: F = Forward LSP, (P4,P5) = PLSP-IDs 346 Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP 348 As shown in Figure 5, the forward tunnel 1 and forward LSP1 are 349 initiated on the endpoint node A and the reverse tunnel 2 and reverse 350 LSP2 are initiated on the endpoint node D (the PCCs). The PLSP-IDs 351 used are P4 on the endpoint node A and P5 on the endpoint node D. 352 Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to 353 the PCE. The endpoint node A (PCC) reports the forward LSP1 and 354 endpoint node D reports the forward LSP2 to the PCE. Both endpoint 355 (PCC) nodes also report the reverse LSPs (not shown for simplicity) 356 to the PCE. 358 3.3. Co-routed Associated Bidirectional LSP 360 In both single-sided and double-sided initiation cases, forward and 361 reverse LSPs can be co-routed as shown in Figure 6, where both 362 forward and reverse LSPs of a bidirectional LSP follow the same 363 congruent path in the forward and reverse directions, respectively. 365 LSP3 --> LSP3 --> LSP3 --> 366 +-----+ +-----+ +-----+ +-----+ 367 | A +-----------+ B +-----------+ C +-----------+ D | 368 +-----+ +-----+ +-----+ +-----+ 369 <-- LSP4 <-- LSP4 <-- LSP4 371 Figure 6: Example of Co-routed Associated Bidirectional LSP 373 The procedure specified in [RFC8537] for fast reroute bypass tunnel 374 assignment is also applicable to the Co-routed Associated 375 Bidirectional LSPs. 377 3.4. Summary of PCEP Extensions 379 The PCEP extensions defined in this document cover the following 380 modes of operations under the stateful PCE model: 382 o A PCC initiates the forward and reverse LSP of a Single-sided 383 Bidirectional LSP and retains the control of the LSPs. Similarly, 384 both PCCs initiate the forward LSPs of a Double-sided 385 Bidirectional LSP and retain the control of the LSPs. The PCC 386 computes the path itself or makes a request for path computation 387 to a PCE. After the path setup, it reports the information and 388 state of the path to the PCE. This includes the association group 389 identifying the bidirectional LSP. This is the Passive Stateful 390 mode defined in [RFC8051]. 392 o A PCC initiates the forward and reverse LSP of a Single-sided 393 Bidirectional LSP and delegates the control of the LSPs to a 394 Stateful PCE. Similarly, both PCCs initiate the forward LSPs of a 395 Double-sided Bidirectional LSP and delegate the control of the 396 LSPs to a Stateful PCE. During delegation the association group 397 identifying the bidirectional LSP is included. The PCE computes 398 the path of the LSP and updates the PCC with the information about 399 the path as long as it controls the LSP. This is the Active 400 Stateful mode defined in [RFC8051]. 402 o A PCE initiates the forward and reverse LSP of a Single-sided 403 Bidirectional LSP on a PCC and retains the control of the LSP. 404 Similarly, a PCE initiates the forward LSPs of a Double-sided 405 Bidirectional LSP on both PCCs and retains the control of the 406 LSPs. The PCE is responsible for computing the path of the LSP 407 and updating the PCC with the information about the path as well 408 as the association group identifying the bidirectional LSP. This 409 is the PCE-Initiated mode defined in [RFC8281]. 411 o A PCC requests co-routed or non-co-routed paths for forward and 412 reverse LSPs of a bidirectional LSP including when using a 413 Stateless PCE [RFC5440]. 415 4. Protocol Extensions 417 4.1. ASSOCIATION Object 419 As per [RFC8697], LSPs are associated by adding them to a common 420 association group. This document defines two new Association Types, 421 called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided 422 Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object 423 ((Object-Class value 40). A member of the Bidirectional LSP 424 Association can take the role of a forward or reverse LSP and follows 425 the following rules: 427 o An LSP (forward or reverse) MUST NOT be part of more than one 428 Bidirectional LSP Association. 430 o The LSPs in a Bidirectional LSP Association MUST have matching 431 endpoint nodes in the reverse directions. 433 o The Tunnel (as defined in [RFC3209]) containing the forward and 434 reverse LSPs of the Single-sided Bidirectional LSP Association on 435 the originating node MUST have the same LSP parameters (as 436 described in section 3.1.1 of [RFC3209]), albeit both LSPs have 437 reversed endpoint nodes. 439 The Bidirectional LSP Association types are considered to be both 440 dynamic and operator-configured in nature. As per [RFC8697], the 441 association group could be manually created by the operator on the 442 PCEP peers, and the LSPs belonging to this association are conveyed 443 via PCEP messages to the PCEP peer; alternately, the association 444 group could be created dynamically by the PCEP speaker, and both the 445 association group information and the LSPs belonging to the 446 association group are conveyed to the PCEP peer. The Operator- 447 configured Association Range MUST be set for this association-type to 448 mark a range of Association Identifiers that are used for operator- 449 configured associations to avoid any Association Identifier clash 450 within the scope of the Association Source (Refer to [RFC8697]). 452 Specifically, for the PCE Initiated Bidirectional LSPs, these 453 Associations are dynamically created by the PCE on the PCE peers. 454 Similarly, for both PCE Initiated and PCC Initiated single-sided 455 case, these associations are also dynamically created on the remote 456 endpoint node using the information received from the RSVP message 457 from the originating node. 459 The Association ID, Association Source, optional Global Association 460 Source and optional Extended Association ID in the Bidirectional LSP 461 Association Object are initialized using the procedures defined in 462 [RFC8697] and [RFC7551]. 464 [RFC8697] specifies the mechanism for the capability advertisement of 465 the Association Types supported by a PCEP speaker by defining an 466 ASSOC-Type-List TLV to be carried within an OPEN Object. This 467 capability exchange for the Bidirectional LSP Association Types MUST 468 be done before using the Bidirectional LSP Association. Thus, the 469 PCEP speaker MUST include the Bidirectional LSP Association Types in 470 the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 471 before using the Bidirectional LSP Association in PCEP messages. 473 4.2. Bidirectional LSP Association Group TLV 475 The "Bidirectional LSP Association Group TLV" is an OPTIONAL TLV for 476 use with the Bidirectional LSP Associations (ASSOCIATION Object with 477 Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for 478 Double-sided Bidirectional LSP). 480 o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV 481 format from [RFC5440]. 483 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 485 o The Length is 4 Bytes. 487 o The value comprises of a single field, the Bidirectional LSP 488 Association Flag (32 bits), where each bit represents a flag 489 option. 491 o If the "Bidirectional LSP Association Group TLV" is missing, it 492 means the LSP is the forward LSP and it is not co-routed LSP. 494 o When "Bidirectional LSP Association Group TLV" is present, the F 495 flag MUST be set for the forward LSP for both co-routed and non 496 co-routed LSPs. 498 o For co-routed LSPs, this TLV MUST be present and C flag set. 500 o For reverse LSPs, this TLV MUST be present and R flag set. 502 o The "Bidirectional LSP Association Group TLV" MUST NOT be present 503 more than once. If it appears more than once, only the first 504 occurrence is processed and any others MUST be ignored. 506 The format of the "Bidirectional LSP Association Group TLV" is shown 507 in Figure 7: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type = TBD3 | Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Flags |C|R|F| 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 7: Bidirectional LSP Association Group TLV format 519 Flags for "Bidirectional LSP Association Group TLV" are defined as 520 following. 522 F (Forward LSP, 1 bit, Bit number 31) - Indicates whether the LSP 523 associated is the forward LSP of the bidirectional LSP. If this flag 524 is set, the LSP is a forward LSP. 526 R (Reverse LSP, 1 bit, Bit number 30) - Indicates whether the LSP 527 associated is the reverse LSP of the bidirectional LSP. If this flag 528 is set, the LSP is a reverse LSP. 530 C (Co-routed Path, 1 bit, Bit number 29) - Indicates whether the 531 bidirectional LSP is co-routed. This flag MUST be set for both the 532 forward and reverse LSPs of a co-routed bidirectional LSP. 534 The C flag is used by the PCE (for both Stateful and Stateless) to 535 compute bidirectional paths of the forward and reverse LSPs of a co- 536 routed bidirectional LSP. 538 The unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and 539 MUST be ignored when received. 541 5. PCEP Procedure 543 The PCEP procedure defined in this document is applicable to the 544 following three scenarios: 546 o Neither unidirectional LSP exists, and both must be established. 548 o Both unidirectional LSPs exist, but the association must be 549 established. 551 o One LSP exists, but the reverse associated LSP must be 552 established. 554 5.1. PCE Initiated LSPs 556 As specified in [RFC8697], the Bidirectional LSP Associations can be 557 created and updated by a Stateful PCE. 559 o For Single-sided Bidirectional LSP Association initiated by the 560 PCE, it MUST send PCInitiate message to the originating endpoint 561 node with both direction LSPs. For Double-sided Bidirectional LSP 562 Association initiated by the PCE, it MUST send PCInitiate message 563 to both endpoint nodes with forward direction LSPs. 565 o Both PCCs MUST report the forward and reverse LSPs in the 566 Bidirectional LSP Association to the PCE. PCC reports via PCRpt 567 message. 569 o Stateful PCE MAY create and update the forward and reverse LSPs 570 independently for the Single-sided Bidirectional LSP Association 571 on the originating endpoint node. 573 o Stateful PCE MAY create and update the forward LSP independently 574 for the Double-sided Bidirectional LSP Association on the endpoint 575 nodes. 577 o Stateful PCE establishes and removes the association relationship 578 on a per LSP basis. 580 o Stateful PCE creates and updates the LSP and the association on a 581 PCC via PCInitiate and PCUpd messages, respectively, using the 582 procedures described in [RFC8697]. 584 5.2. PCC Initiated LSPs 586 As specified in [RFC8697], the Bidirectional LSP Associations can 587 also be created and updated by a PCC. 589 o For Single-sided Bidirectional LSP Association initiated at a PCC, 590 it MUST send PCRpt message to the PCE with both direction LSPs. 591 For Double-sided Bidirectional LSP Association initiated at the 592 PCCs, both PCCs MUST send PCRpt message to the PCE with forward 593 direction LSPs. 595 o PCC on the originating endpoint node MAY create and update the 596 forward and reverse LSPs independently for the Single-sided 597 Bidirectional LSP Association. 599 o PCC on the endpoint nodes MAY create and update the forward LSP 600 independently for the Double-sided Bidirectional LSP Association. 602 o PCC establishes and removes the association group on a per LSP 603 basis. PCC MUST report the change in the association group of an 604 LSP to PCE(s) via PCRpt message. 606 o PCC reports the forward and reverse LSPs in the Bidirectional LSP 607 Association independently to PCE(s) via PCRpt message. 609 o PCC for the single-sided case MAY delegate the forward and reverse 610 LSPs independently to a Stateful PCE, where PCE would control the 611 LSPs. In this case, the originating (PCC) endpoint node SHOULD 612 delegate both forward and reverse LSPs of a tunnel together to a 613 Stateful PCE in order to avoid any race condition. 615 o PCCs for the double-sided case MAY delegate the forward LSPs to a 616 Stateful PCE, where PCE would control the LSPs. 618 o Stateful PCE updates the LSPs in the Bidirectional LSP Association 619 via PCUpd message, using the procedures described in [RFC8697]. 621 5.3. Stateless PCE 623 For a stateless PCE, it might be useful to associate a path 624 computation request to an association group, thus enabling it to 625 associate a common set of configuration parameters or behaviors with 626 the request [RFC8697]. A PCC can request co-routed or non-co-routed 627 forward and reverse direction paths from a stateless PCE for a 628 Bidirectional LSP Association. 630 5.4. Bidirectional (B) Flag 632 As defined in [RFC5440], the Bidirectional (B) flag in the Request 633 Parameters (RP) Object is set when the PCC specifies that the path 634 computation request is for a bidirectional TE LSP with the same TE 635 requirements in each direction. For an associated bidirectional LSP, 636 the B-flag is also set when the PCC makes the path computation 637 request for the same TE requirements for the forward and reverse 638 direction LSPs. 640 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 641 Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate 642 'bidirectional co-routed LSP' is used for GMPLS signaled 643 bidirectional LSPs and is not applicable to the associated 644 bidirectional LSPs. 646 5.5. PLSP-ID Usage 648 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 649 created by a PCC to uniquely identify an LSP and it remains the same 650 for the lifetime of a PCEP session. 652 In case of Single-sided Bidirectional LSP Association, the reverse 653 LSP of a bidirectional LSP created on the originating endpoint node 654 is identified by the PCE using 2 different PLSP-IDs based on the PCEP 655 session on the ingress or egress nodes for the LSP. In other words, 656 the reverse LSP will have a PLSP-ID P1 at the ingress node while it 657 will have a PLSP-ID P3 at the egress node. There is no change in the 658 PLSP-ID allocation procedure for the forward LSP of the Single-sided 659 Bidirectional LSP on the originating endpoint node. In case of 660 Double-sided Bidirectional LSP Association, there is no change in the 661 PLSP-ID allocation procedure. 663 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 664 MUST be included in all forward and reverse LSPs. 666 5.6. State Synchronization 668 During state synchronization, a PCC MUST report all the existing 669 Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. 670 After the state synchronization, the PCE MUST remove all previous 671 Bidirectional LSP Associations absent in the report. 673 5.7. Error Handling 675 If a PCE speaker receives an LSP with a Bidirectional LSP Association 676 Type that it does not support, the PCE speaker MUST send PCErr with 677 Error-Type = 26 (Association Error) and Error-Value = 1 (Association 678 Type is not supported). 680 An LSP (forward or reverse) cannot be part of more than one 681 Bidirectional LSP Association. If a PCE speaker receives an LSP not 682 complying to this rule, the PCE speaker MUST send PCErr with Error- 683 Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional 684 LSP Association - Group Mismatch). 686 The LSPs (forward or reverse) in a Single-sided Bidirectional 687 Association MUST belong to the same TE Tunnel (as defined in 688 [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- 689 sided Bidirectional LSP Association for a different Tunnel, the PCE 690 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 691 Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 693 The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up 694 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP 695 speaker receives a different PST value for the Bidirectional LSP 696 Associations defined in this document, the PCE speaker MUST return a 697 PCErr message with Error-Type = 26 (Association Error) and Error- 698 Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not 699 Supported). 701 A Bidirectional LSP Association cannot have both unidirectional LSPs 702 identified as Reverse LSPs or both LSPs identified as Forward LSPs. 703 If a PCE speaker receives an LSP not complying to this rule, the PCE 704 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 705 Error-Value = TBD7 (Bidirectional LSP Association - Direction 706 Mismatch). 708 A Bidirectional LSP Association cannot have one unidirectional LSP 709 identified as co-routed and the other identified as non-co-routed. 710 If a PCE speaker receives an LSP not complying to this rule, the PCE 711 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 712 Error-Value = TBD8 (Bidirectional LSP Association - Co-routed 713 Mismatch). 715 The unidirectional LSPs forming the Bidirectional LSP Association 716 MUST have matching endpoint nodes in the reverse directions. If a 717 PCE speaker receives an LSP not complying to this rule, the PCE 718 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 719 Error-Value = TBD9 (Bidirectional LSP Association - Endpoint 720 Mismatch). 722 The processing rules as specified in Section 6.4 of [RFC8697] 723 continue to apply to the Association Types defined in this document. 725 6. Implementation Status 727 [Note to the RFC Editor - remove this section before publication, as 728 well as remove the reference to RFC 7942.] 730 This section records the status of known implementations of the 731 protocol defined by this specification at the time of posting of this 732 Internet-Draft, and is based on a proposal described in [RFC7942]. 733 The description of implementations in this section is intended to 734 assist the IETF in its decision processes in progressing drafts to 735 RFCs. Please note that the listing of any individual implementation 736 here does not imply endorsement by the IETF. Furthermore, no effort 737 has been spent to verify the information presented here that was 738 supplied by IETF contributors. This is not intended as, and must not 739 be construed to be, a catalog of available implementations or their 740 features. Readers are advised to note that other implementations may 741 exist. 743 According to [RFC7942], "this will allow reviewers and working groups 744 to assign due consideration to documents that have the benefit of 745 running code, which may serve as evidence of valuable experimentation 746 and feedback that have made the implemented protocols more mature. 747 It is up to the individual working groups to use this information as 748 they see fit". 750 6.1. Implementation 752 The PCEP extensions defined in this document has been implemented by 753 a vendor on their product. No further information is available at 754 this time. 756 7. Security Considerations 758 The security considerations described in [RFC5440], [RFC8231], and 759 [RFC8281] apply to the extensions defined in this document as well. 761 Two new Association Types for the ASSOCIATION Object, Single-sided 762 Bidirectional LSP Association and Double-sided Bidirectional LSP 763 Association are introduced in this document. Additional security 764 considerations related to LSP associations due to a malicious PCEP 765 speaker is described in [RFC8697] and apply to these Association 766 Types. Hence, securing the PCEP session using Transport Layer 767 Security (TLS) [RFC8253] is RECOMMENDED. 769 8. Manageability Considerations 771 8.1. Control of Function and Policy 773 The mechanisms defined in this document do not imply any control or 774 policy requirements in addition to those already listed in [RFC5440], 775 [RFC8231], and [RFC8281]. 777 8.2. Information and Data Models 779 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 780 defined for LSP associations. 782 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 783 LSP associations. 785 8.3. Liveness Detection and Monitoring 787 The mechanisms defined in this document do not imply any new liveness 788 detection and monitoring requirements in addition to those already 789 listed in [RFC5440], [RFC8231], and [RFC8281]. 791 8.4. Verify Correct Operations 793 The mechanisms defined in this document do not imply any new 794 operation verification requirements in addition to those already 795 listed in [RFC5440], [RFC8231], and [RFC8281]. 797 8.5. Requirements On Other Protocols 799 The mechanisms defined in this document do not add any new 800 requirements on other protocols. 802 8.6. Impact On Network Operations 804 The mechanisms defined in this document do not have any impact on 805 network operations in addition to those already listed in [RFC5440], 806 [RFC8231], and [RFC8281]. 808 9. IANA Considerations 810 9.1. Association Types 812 This document defines two new Association Types, originally described 813 in [RFC8697]. IANA is requested to assign the following new values 814 in the "ASSOCIATION Type Field" subregistry [RFC8697] within the 815 "Path Computation Element Protocol (PCEP) Numbers" registry: 817 Type Name Reference 818 --------------------------------------------------------------------- 819 TBD1 Single-sided Bidirectional LSP Association [This document] 820 TBD2 Double-sided Bidirectional LSP Association [This document] 822 9.2. Bidirectional LSP Association Group TLV 824 This document defines a new TLV for carrying additional information 825 of LSPs within a Bidirectional LSP Association. IANA is requested to 826 add the assignment of a new value in the existing "PCEP TLV Type 827 Indicators" registry as follows: 829 Value Meaning Reference 830 ------------------------------------------------------------------- 831 TBD3 Bidirectional LSP Association Group TLV [This document] 833 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 835 This document requests that a new sub-registry, named "Bidirectional 836 LSP Association Group TLV Flag Field", is created within the "Path 837 Computation Element Protocol (PCEP) Numbers" registry to manage the 838 Flag field in the Bidirectional LSP Association Group TLV. New 839 values are to be assigned by Standards Action [RFC8126]. Each bit 840 should be tracked with the following qualities: 842 o Bit number (count from 0 as the most significant bit) 844 o Description 846 o Reference 848 The following values are defined in this document for the Flag field. 850 Bit No. Description Reference 851 --------------------------------------------------------- 852 31 F - Forward LSP [This document] 853 30 R - Reverse LSP [This document] 854 29 C - Co-routed Path [This document] 855 0-28 Unassigned 857 9.3. PCEP Errors 859 This document defines new Error value for Error Type 26 (Association 860 Error). IANA is requested to allocate new Error value within the 861 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 862 Numbers registry, as follows: 864 Error Type Description Reference 865 --------------------------------------------------------- 866 26 Association Error 868 Error value: TBD4 [This document] 869 Bidirectional LSP Association - Group Mismatch 871 Error value: TBD5 [This document] 872 Bidirectional LSP Association - Tunnel Mismatch 874 Error value: TBD6 [This document] 875 Bidirectional LSP Association - Path Setup Type 876 Not Supported 878 Error value: TBD7 [This document] 879 Bidirectional LSP Association - Direction Mismatch 881 Error value: TBD8 [This document] 882 Bidirectional LSP Association - Co-routed Mismatch 884 Error value: TBD9 [This document] 885 Bidirectional LSP Association - Endpoint Mismatch 887 10. References 889 10.1. Normative References 891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 892 Requirement Levels", BCP 14, RFC 2119, 893 DOI 10.17487/RFC2119, March 1997, 894 . 896 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 897 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 898 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 899 . 901 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 902 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 903 DOI 10.17487/RFC5440, March 2009, 904 . 906 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 907 Extensions for Associated Bidirectional Label Switched 908 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 909 . 911 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 912 Writing an IANA Considerations Section in RFCs", BCP 26, 913 RFC 8126, DOI 10.17487/RFC8126, June 2017, 914 . 916 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 917 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 918 May 2017, . 920 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 921 Computation Element Communication Protocol (PCEP) 922 Extensions for Stateful PCE", RFC 8231, 923 DOI 10.17487/RFC8231, September 2017, 924 . 926 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 927 Computation Element Communication Protocol (PCEP) 928 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 929 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 930 . 932 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 933 the Fast Reroute Procedures for Co-routed Associated 934 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 935 DOI 10.17487/RFC8537, February 2019, 936 . 938 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 939 Dhody, D., and Y. Tanaka, "Path Computation Element 940 Communication Protocol (PCEP) Extensions for Establishing 941 Relationships between Sets of Label Switched Paths 942 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 943 . 945 10.2. Informative References 947 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 948 Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path 949 Computation Element (PCE) Protocol Extensions for Stateful 950 PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- 951 pcep-stateful-pce-gmpls-14 (work in progress), December 952 2020. 954 [I-D.ietf-pce-pcep-yang] 955 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 956 YANG Data Model for Path Computation Element 957 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 958 yang-15 (work in progress), October 2020. 960 [I-D.ietf-pce-sr-bidir-path] 961 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 962 "Path Computation Element Communication Protocol (PCEP) 963 Extensions for Associated Bidirectional Segment Routing 964 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 965 progress), January 2021. 967 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 968 Sprecher, N., and S. Ueno, "Requirements of an MPLS 969 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 970 September 2009, . 972 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 973 Hardwick, "Path Computation Element Communication Protocol 974 (PCEP) Management Information Base (MIB) Module", 975 RFC 7420, DOI 10.17487/RFC7420, December 2014, 976 . 978 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 979 Code: The Implementation Status Section", BCP 205, 980 RFC 7942, DOI 10.17487/RFC7942, July 2016, 981 . 983 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 984 Stateful Path Computation Element (PCE)", RFC 8051, 985 DOI 10.17487/RFC8051, January 2017, 986 . 988 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 989 "PCEPS: Usage of TLS to Provide a Secure Transport for the 990 Path Computation Element Communication Protocol (PCEP)", 991 RFC 8253, DOI 10.17487/RFC8253, October 2017, 992 . 994 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 995 Hardwick, "Conveying Path Setup Type in PCE Communication 996 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 997 July 2018, . 999 Acknowledgments 1001 The authors would like to thank Dhruv Dhody for various discussions 1002 on association groups and inputs to this document. The authors would 1003 also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and 1004 Marina Fizgeer for reviewing this document and providing valuable 1005 comments. 1007 Authors' Addresses 1009 Rakesh Gandhi (editor) 1010 Cisco Systems, Inc. 1011 Canada 1013 Email: rgandhi@cisco.com 1015 Colby Barth 1016 Juniper Networks 1018 Email: cbarth@juniper.net 1020 Bin Wen 1021 Comcast 1023 Email: Bin_Wen@cable.comcast.com