idnits 2.17.1 draft-ietf-pce-association-bidir-09.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 (December 16, 2020) is 1199 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-15 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-03 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: June 19, 2021 Juniper Networks 6 B. Wen 7 Comcast 8 December 16, 2020 10 Path Computation Element Communication Protocol (PCEP) Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-09 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 June 19, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . 9 78 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10 80 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 11 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 Both endpoint (PCC) nodes report the forward LSP1 and LSP2 to the 329 PCE. Both endpoint (PCC) nodes also report the reverse LSPs (not 330 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. Both endpoint (PCC) nodes report the forward LSP1 and LSP2 354 to the PCE. Both endpoint (PCC) nodes also report the reverse LSPs 355 (not shown for simplicity) to the PCE. 357 3.3. Co-routed Associated Bidirectional LSP 359 In both single-sided and double-sided initiation cases, forward and 360 reverse LSPs can be co-routed as shown in Figure 6, where both 361 forward and reverse LSPs of a bidirectional LSP follow the same 362 congruent path in the forward and reverse directions, respectively. 364 LSP3 --> LSP3 --> LSP3 --> 365 +-----+ +-----+ +-----+ +-----+ 366 | A +-----------+ B +-----------+ C +-----------+ D | 367 +-----+ +-----+ +-----+ +-----+ 368 <-- LSP4 <-- LSP4 <-- LSP4 370 Figure 6: Example of Co-routed Associated Bidirectional LSP 372 3.4. Summary of PCEP Extensions 374 The PCEP extensions defined in this document cover the following 375 modes of operations under the stateful PCE model: 377 o A PCC initiates the forward and reverse LSP of a Single-sided 378 Bidirectional LSP and retains the control of the LSPs. Similarly, 379 both PCCs initiate the forward LSPs of a Double-sided 380 Bidirectional LSP and retain the control of the LSPs. The PCC 381 computes the path itself or makes a request for path computation 382 to a PCE. After the path setup, it reports the information and 383 state of the path to the PCE. This includes the association group 384 identifying the bidirectional LSP. This is the Passive Stateful 385 mode defined in [RFC8051]. 387 o A PCC initiates the forward and reverse LSP of a Single-sided 388 Bidirectional LSP and delegates the control of the LSPs to a 389 Stateful PCE. Similarly, both PCCs initiate the forward LSPs of a 390 Double-sided Bidirectional LSP and delegate the control of the 391 LSPs to a Stateful PCE. During delegation the association group 392 identifying the bidirectional LSP is included. The PCE computes 393 the path of the LSP and updates the PCC with the information about 394 the path as long as it controls the LSP. This is the Active 395 Stateful mode defined in [RFC8051]. 397 o A PCE initiates the forward and reverse LSP of a Single-sided 398 Bidirectional LSP on a PCC and retains the control of the LSP. 399 Similarly, a PCE initiates the forward LSPs of a Double-sided 400 Bidirectional LSP on both PCCs and retains the control of the 401 LSPs. The PCE is responsible for computing the path of the LSP 402 and updating the PCC with the information about the path as well 403 as the association group identifying the bidirectional LSP. This 404 is the PCE-Initiated mode defined in [RFC8281]. 406 o A PCC requests co-routed or non-co-routed paths for forward and 407 reverse LSPs of a bidirectional LSP including when using a 408 Stateless PCE [RFC5440]. 410 4. Protocol Extensions 412 4.1. ASSOCIATION Object 414 As per [RFC8697], LSPs are associated by adding them to a common 415 association group. This document defines two new Association Types, 416 called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided 417 Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object 418 ((Object-Class value 40). A member of the Bidirectional LSP 419 Association can take the role of a forward or reverse LSP and follows 420 the following rules: 422 o An LSP (forward or reverse) MUST NOT be part of more than one 423 Bidirectional LSP Association. 425 o A Bidirectional LSP Association SHOULD NOT have more than two 426 unidirectional LSPs. 428 o The LSPs in a Bidirectional LSP Association MUST have matching 429 endpoint nodes in the reverse directions. 431 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 432 of the Single-sided Bidirectional LSP Association on the 433 originating endpoint node MUST be the same, albeit with reverse 434 endpoint nodes. 436 The Bidirectional LSP Association types are considered to be both 437 dynamic and operator- configured in nature. As per [RFC8697], the 438 association group could be manually created by the operator on the 439 PCEP peers, and the LSPs belonging to this association are conveyed 440 via PCEP messages to the PCEP peer; alternately, the association 441 group could be created dynamically by the PCEP speaker, and both the 442 association group information and the LSPs belonging to the 443 association group are conveyed to the PCEP peer. The Operator- 444 configured Association Range MUST be set for this association-type to 445 mark a range of Association Identifiers that are used for operator- 446 configured associations to avoid any Association Identifier clash 447 within the scope of the Association Source (Refer to [RFC8697]). 449 Specifically, for the PCE Initiated Bidirectional LSPs, these 450 Associations are dynamically created by the PCE on the PCE peers. 451 Similarly, for both PCE Initiated and PCC Initiated single-sided 452 case, these associations are also dynamically created on thee remote 453 endpoint node using the information received from the RSVP message 454 from the originating node. 456 The Association ID, Association Source, optional Global Association 457 Source and optional Extended Association ID in the Bidirectional LSP 458 Association Object are initialized using the procedures defined in 459 [RFC8697] and [RFC7551]. 461 [RFC8697] specifies the mechanism for the capability advertisement of 462 the Association Types supported by a PCEP speaker by defining an 463 ASSOC-Type-List TLV to be carried within an OPEN Object. This 464 capability exchange for the Bidirectional LSP Association Types MUST 465 be done before using the Bidirectional LSP Association. Thus, the 466 PCEP speaker MUST include the Bidirectional LSP Association Types in 467 the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 468 before using the Bidirectional LSP Association in PCEP messages. 470 4.2. Bidirectional LSP Association Group TLV 472 The "Bidirectional LSP Association Group TLV" an OPTIONAL TLV for use 473 with the Bidirectional LSP Associations (ASSOCIATION Object with 474 Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for 475 Double-sided Bidirectional LSP). 477 o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV 478 format from [RFC5440]. 480 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 482 o The Length is 4 Bytes. 484 o The value comprises of a single field, the Bidirectional LSP 485 Association Flag (32 bits), where each bit represents a flag 486 option. 488 o If the "Bidirectional LSP Association Group TLV" is missing, it 489 means the LSP is the forward LSP and it is not co-routed LSP. 491 o For co-routed LSPs, this TLV MUST be present and C flag set. 493 o For reverse LSPs, this TLV MUST be present and R flag set. 495 o The "Bidirectional LSP Association Group TLV" MUST NOT be present 496 more than once. If it appears more than once, only the first 497 occurrence is processed and any others MUST be ignored. 499 The format of the "Bidirectional LSP Association Group TLV" is shown 500 in Figure 7: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type = TBD3 | Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Flags |C|R|F| 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 7: Bidirectional LSP Association Group TLV format 512 Flags for "Bidirectional LSP Association Group TLV" are defined as 513 following. 515 F (Forward LSP, 1 bit, Bit number 31) - Indicates whether the LSP 516 associated is the forward LSP of the bidirectional LSP. If this flag 517 is set, the LSP is a forward LSP. 519 R (Reverse LSP, 1 bit, Bit number 30) - Indicates whether the LSP 520 associated is the reverse LSP of the bidirectional LSP. If this flag 521 is set, the LSP is a reverse LSP. 523 C (Co-routed Path, 1 bit, Bit number 29) - Indicates whether the 524 bidirectional LSP is co-routed. This flag MUST be set for both the 525 forward and reverse LSPs of a co-routed bidirectional LSP. 527 The C flag is used by the PCE (for both Stateful and Stateless) to 528 compute bidirectional paths of the forward and reverse LSPs of a co- 529 routed bidirectional LSP. 531 The unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and 532 MUST be ignored when received. 534 5. PCEP Procedure 536 The PCEP procedure defined in this document is applicable to the 537 following three scenarios: 539 o Neither unidirectional LSP exists, and both must be established. 541 o Both unidirectional LSPs exist, but the association must be 542 established. 544 o One LSP exists, but the reverse associated LSP must be 545 established. 547 5.1. PCE Initiated LSPs 549 As specified in [RFC8697], the Bidirectional LSP Associations can be 550 created and updated by a Stateful PCE. 552 o For Single-sided Bidirectional LSP Association initiated by the 553 PCE, it MUST send PCInitiate message to the originating endpoint 554 node with both direction LSPs. For Double-sided Bidirectional LSP 555 Association initiated by the PCE, it MUST send PCInitiate message 556 to both endpoint nodes with forward direction LSPs. 558 o Both PCCs MUST report the forward and reverse LSPs in the 559 Bidirectional LSP Association to the PCE. PCC reports via PCRpt 560 message. 562 o Stateful PCE MAY create and update the forward and reverse LSPs 563 independently for the Single-sided Bidirectional LSP Association 564 on the originating endpoint node. 566 o Stateful PCE MAY create and update the forward LSP independently 567 for the Double-sided Bidirectional LSP Association on the endpoint 568 nodes. 570 o Stateful PCE establishes and removes the association relationship 571 on a per LSP basis. 573 o Stateful PCE creates and updates the LSP and the association on a 574 PCC via PCInitiate and PCUpd messages, respectively, using the 575 procedures described in [RFC8697]. 577 5.2. PCC Initiated LSPs 579 As specified in [RFC8697], Bidirectional LSP Associations can also be 580 created and updated by a PCC. 582 o For Single-sided Bidirectional LSP Association initiated at a PCC, 583 it MUST send PCRpt message to the PCE with both direction LSPs. 584 For Double-sided Bidirectional LSP Association initiated at the 585 PCCs, both PCCs MUST send PCRpt message to the PCE with forward 586 direction LSPs. 588 o PCC on the originating endpoint node MAY create and update the 589 forward and reverse LSPs independently for the Single-sided 590 Bidirectional LSP Association. 592 o PCC on the endpoint nodes MAY create and update the forward LSP 593 independently for the Double-sided Bidirectional LSP Association. 595 o PCC establishes and removes the association group on a per LSP 596 basis. PCC MUST report the change in the association group of an 597 LSP to PCE(s) via PCRpt message. 599 o PCC reports the forward and reverse LSPs in the Bidirectional LSP 600 Association independently to PCE(s) via PCRpt message. 602 o PCC for the single-sided case MAY delegate the forward and reverse 603 LSPs independently to a Stateful PCE, where PCE would control the 604 LSPs. In this case, the originating (PCC) endpoint node SHOULD 605 delegate both forward and reverse LSPs of a tunnel together to a 606 Stateful PCE in order to avoid any race condition. 608 o PCCs for the double-sided case MAY delegate the forward LSPs to a 609 Stateful PCE, where PCE would control the LSPs. 611 o Stateful PCE updates the LSPs in the Bidirectional LSP Association 612 via PCUpd message, using the procedures described in [RFC8697]. 614 5.3. Stateless PCE 616 For a stateless PCE, it might be useful to associate a path 617 computation request to an association group, thus enabling it to 618 associate a common set of configuration parameters or behaviors with 619 the request [RFC8697]. A PCC can request co-routed or non-co-routed 620 forward and reverse direction paths from a stateless PCE for a 621 Bidirectional LSP Association. 623 5.4. Bidirectional (B) Flag 625 As defined in [RFC5440], the Bidirectional (B) flag in the Request 626 Parameters (RP) Object is set when the PCC specifies that the path 627 computation request is for a bidirectional TE LSP with the same TE 628 requirements in each direction. For an associated bidirectional LSP, 629 the B-flag is also set when the PCC makes the path computation 630 request for the same TE requirements for the forward and reverse 631 direction LSPs. 633 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 634 Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate 635 'bidirectional co-routed LSP' is used for GMPLS signaled 636 bidirectional LSPs and is not applicable to the associated 637 bidirectional LSPs. 639 5.5. PLSP-ID Usage 641 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 642 created by a PCC to uniquely identify an LSP and it remains the same 643 for the lifetime of a PCEP session. 645 In case of Single-sided Bidirectional LSP Association, the reverse 646 LSP of a bidirectional LSP created on the originating endpoint node 647 is identified by the PCE using 2 different PLSP-IDs based on the PCEP 648 session on the ingress or egress nodes for the LSP. In other words, 649 the reverse LSP will have a PLSP-ID P1 at the ingress node while it 650 will have a PLSP-ID P3 at the egress node. There is no change in the 651 PLSP-ID allocation procedure for the forward LSP of the Single-sided 652 Bidirectional LSP on the originating endpoint node. In case of 653 Double-sided Bidirectional LSP Association, there is no change in the 654 PLSP-ID allocation procedure. 656 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 657 MUST be included in all forward and reverse LSPs. 659 5.6. State Synchronization 661 During state synchronization, a PCC MUST report all the existing 662 Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. 663 After the state synchronization, the PCE MUST remove all stale 664 Bidirectional LSP Associations. 666 5.7. Error Handling 668 If a PCE speaker receives an LSP with a Bidirectional LSP Association 669 Type that it does not support, the PCE speaker MUST send PCErr with 670 Error-Type = 26 (Association Error) and Error-Value = 1 (Association 671 Type is not supported). 673 An LSP (forward or reverse) cannot be part of more than one 674 Bidirectional LSP Association. If a PCE speaker receives an LSP not 675 complying to this rule, the PCE speaker MUST send PCErr with Error- 676 Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional 677 LSP Association - Group Mismatch). 679 The LSPs (forward or reverse) in a Single-sided Bidirectional 680 Association MUST belong to the same TE Tunnel (as defined in 681 [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- 682 sided Bidirectional LSP Association for a different Tunnel, the PCE 683 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 684 Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 686 The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up 687 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP 688 speaker receives a different PST value for the Bidirectional LSP 689 Associations defined in this document and it does not support; the 690 PCE speaker MUST return a PCErr message with Error-Type = 26 691 (Association Error) and Error-Value = TBD6 (Bidirectional LSP 692 Association - Path Setup Type Not Supported). 694 A Bidirectional LSP Association cannot have both unidirectional LSPs 695 identified as Reverse LSPs or both LSPs identified as Forward LSPs. 696 If a PCE speaker receives an LSP not complying to this rule, the PCE 697 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 698 Error-Value = TBD7 (Bidirectional LSP Association - Direction 699 Mismatch). 701 A Bidirectional LSP Association cannot have one unidirectional LSP 702 identified as co-routed and the other identified as non-co-routed. 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 = TBD8 (Bidirectional LSP Association - Co-routed 706 Mismatch). 708 The unidirectional LSPs forming the Bidirectional LSP Association 709 MUST have matching endpoint nodes in the reverse directions. If a 710 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 = TBD9 (Bidirectional LSP Association - Endpoint 713 Mismatch). 715 The processing rules as specified in Section 6.4 of [RFC8697] 716 continue to apply to the Association Types defined in this document. 718 6. Implementation Status 720 [Note to the RFC Editor - remove this section before publication, as 721 well as remove the reference to RFC 7942.] 723 This section records the status of known implementations of the 724 protocol defined by this specification at the time of posting of this 725 Internet-Draft, and is based on a proposal described in [RFC7942]. 726 The description of implementations in this section is intended to 727 assist the IETF in its decision processes in progressing drafts to 728 RFCs. Please note that the listing of any individual implementation 729 here does not imply endorsement by the IETF. Furthermore, no effort 730 has been spent to verify the information presented here that was 731 supplied by IETF contributors. This is not intended as, and must not 732 be construed to be, a catalog of available implementations or their 733 features. Readers are advised to note that other implementations may 734 exist. 736 According to [RFC7942], "this will allow reviewers and working groups 737 to assign due consideration to documents that have the benefit of 738 running code, which may serve as evidence of valuable experimentation 739 and feedback that have made the implemented protocols more mature. 740 It is up to the individual working groups to use this information as 741 they see fit". 743 6.1. Implementation 745 The PCEP extensions defined in this document has been implemented by 746 a vendor on their product. No further information is available at 747 this time. 749 7. Security Considerations 751 The security considerations described in [RFC5440], [RFC8231], and 752 [RFC8281] apply to the extensions defined in this document as well. 754 Two new Association Types for the ASSOCIATION Object, Single-sided 755 Bidirectional LSP Association and Double-sided Bidirectional LSP 756 Association are introduced in this document. Additional security 757 considerations related to LSP associations due to a malicious PCEP 758 speaker is described in [RFC8697] and apply to these Association 759 Types. Hence, securing the PCEP session using Transport Layer 760 Security (TLS) [RFC8253] is recommended. 762 8. Manageability Considerations 764 8.1. Control of Function and Policy 766 The mechanisms defined in this document do not imply any control or 767 policy requirements in addition to those already listed in [RFC5440], 768 [RFC8231], and [RFC8281]. 770 8.2. Information and Data Models 772 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 773 defined for LSP associations. 775 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 776 LSP associations. 778 8.3. Liveness Detection and Monitoring 780 The mechanisms defined in this document do not imply any new liveness 781 detection and monitoring requirements in addition to those already 782 listed in [RFC5440], [RFC8231], and [RFC8281]. 784 8.4. Verify Correct Operations 786 The mechanisms defined in this document do not imply any new 787 operation verification requirements in addition to those already 788 listed in [RFC5440], [RFC8231], and [RFC8281]. 790 8.5. Requirements On Other Protocols 792 The mechanisms defined in this document do not add any new 793 requirements on other protocols. 795 8.6. Impact On Network Operations 797 The mechanisms defined in this document do not have any impact on 798 network operations in addition to those already listed in [RFC5440], 799 [RFC8231], and [RFC8281]. 801 9. IANA Considerations 803 9.1. Association Types 805 This document defines two new Association Types, originally described 806 in [RFC8697]. IANA is requested to assign the following new values 807 in the "ASSOCIATION Type Field" subregistry [RFC8697] within the 808 "Path Computation Element Protocol (PCEP) Numbers" registry: 810 Type Name Reference 811 --------------------------------------------------------------------- 812 TBD1 Single-sided Bidirectional LSP Association [This document] 813 TBD2 Double-sided Bidirectional LSP Association [This document] 815 9.2. Bidirectional LSP Association Group TLV 817 This document defines a new TLV for carrying additional information 818 of LSPs within a Bidirectional LSP Association. IANA is requested to 819 add the assignment of a new value in the existing "PCEP TLV Type 820 Indicators" registry as follows: 822 Value Meaning Reference 823 ------------------------------------------------------------------- 824 TBD3 Bidirectional LSP Association Group TLV [This document] 826 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 828 This document requests that a new sub-registry, named "Bidirectional 829 LSP Association Group TLV Flag Field", is created within the "Path 830 Computation Element Protocol (PCEP) Numbers" registry to manage the 831 Flag field in the Bidirectional LSP Association Group TLV. New 832 values are to be assigned by Standards Action [RFC8126]. Each bit 833 should be tracked with the following qualities: 835 o Bit number (count from 0 as the most significant bit) 837 o Description 839 o Reference 841 The following values are defined in this document for the Flag field. 843 Bit No. Description Reference 844 --------------------------------------------------------- 845 31 F - Forward LSP [This document] 846 30 R - Reverse LSP [This document] 847 29 C - Co-routed Path [This document] 848 0-28 Unassigned 850 9.3. PCEP Errors 852 This document defines new Error value for Error Type 26 (Association 853 Error). IANA is requested to allocate new Error value within the 854 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 855 Numbers registry, as follows: 857 Error Type Description Reference 858 --------------------------------------------------------- 859 26 Association Error 861 Error value: TBD4 [This document] 862 Bidirectional LSP Association - Group Mismatch 864 Error value: TBD5 [This document] 865 Bidirectional LSP Association - Tunnel Mismatch 867 Error value: TBD6 [This document] 868 Bidirectional LSP Association - Path Setup Type 869 Not Supported 871 Error value: TBD7 [This document] 872 Bidirectional LSP Association - Direction Mismatch 874 Error value: TBD8 [This document] 875 Bidirectional LSP Association - Co-routed Mismatch 877 Error value: TBD9 [This document] 878 Bidirectional LSP Association - Endpoint Mismatch 880 10. References 882 10.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 890 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 891 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 892 . 894 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 895 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 896 DOI 10.17487/RFC5440, March 2009, 897 . 899 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 900 Extensions for Associated Bidirectional Label Switched 901 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 902 . 904 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 905 Writing an IANA Considerations Section in RFCs", BCP 26, 906 RFC 8126, DOI 10.17487/RFC8126, June 2017, 907 . 909 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 910 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 911 May 2017, . 913 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 914 Computation Element Communication Protocol (PCEP) 915 Extensions for Stateful PCE", RFC 8231, 916 DOI 10.17487/RFC8231, September 2017, 917 . 919 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 920 Computation Element Communication Protocol (PCEP) 921 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 922 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 923 . 925 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 926 the Fast Reroute Procedures for Co-routed Associated 927 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 928 DOI 10.17487/RFC8537, February 2019, 929 . 931 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 932 Dhody, D., and Y. Tanaka, "Path Computation Element 933 Communication Protocol (PCEP) Extensions for Establishing 934 Relationships between Sets of Label Switched Paths 935 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 936 . 938 10.2. Informative References 940 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 941 Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path 942 Computation Element (PCE) Protocol Extensions for Stateful 943 PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- 944 pcep-stateful-pce-gmpls-13 (work in progress), April 2020. 946 [I-D.ietf-pce-pcep-yang] 947 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 948 YANG Data Model for Path Computation Element 949 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 950 yang-15 (work in progress), October 2020. 952 [I-D.ietf-pce-sr-bidir-path] 953 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 954 "PCEP Extensions for Associated Bidirectional Segment 955 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work 956 in progress), September 2020. 958 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 959 Sprecher, N., and S. Ueno, "Requirements of an MPLS 960 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 961 September 2009, . 963 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 964 Hardwick, "Path Computation Element Communication Protocol 965 (PCEP) Management Information Base (MIB) Module", 966 RFC 7420, DOI 10.17487/RFC7420, December 2014, 967 . 969 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 970 Code: The Implementation Status Section", BCP 205, 971 RFC 7942, DOI 10.17487/RFC7942, July 2016, 972 . 974 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 975 Stateful Path Computation Element (PCE)", RFC 8051, 976 DOI 10.17487/RFC8051, January 2017, 977 . 979 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 980 "PCEPS: Usage of TLS to Provide a Secure Transport for the 981 Path Computation Element Communication Protocol (PCEP)", 982 RFC 8253, DOI 10.17487/RFC8253, October 2017, 983 . 985 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 986 Hardwick, "Conveying Path Setup Type in PCE Communication 987 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 988 July 2018, . 990 Acknowledgments 992 The authors would like to thank Dhruv Dhody for various discussions 993 on association groups and inputs to this document. The authors would 994 also like to thank Mike Taillon, and Marina Fizgeer for reviewing 995 this document and providing valuable comments. 997 Authors' Addresses 999 Rakesh Gandhi (editor) 1000 Cisco Systems, Inc. 1001 Canada 1003 Email: rgandhi@cisco.com 1005 Colby Barth 1006 Juniper Networks 1008 Email: cbarth@juniper.net 1010 Bin Wen 1011 Comcast 1013 Email: Bin_Wen@cable.comcast.com