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