idnits 2.17.1 draft-ietf-pce-association-bidir-10.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 06, 2021) is 1206 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-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: July 10, 2021 Juniper Networks 6 B. Wen 7 Comcast 8 January 06, 2021 10 Path Computation Element Communication Protocol (PCEP) Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-10 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 July 10, 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]) of forward and reverse LSPs 434 of the Single-sided Bidirectional LSP Association on the 435 originating endpoint node MUST be the same, albeit with reverse 436 endpoint nodes. 438 The Bidirectional LSP Association types are considered to be both 439 dynamic and operator-configured in nature. As per [RFC8697], the 440 association group could be manually created by the operator on the 441 PCEP peers, and the LSPs belonging to this association are conveyed 442 via PCEP messages to the PCEP peer; alternately, the association 443 group could be created dynamically by the PCEP speaker, and both the 444 association group information and the LSPs belonging to the 445 association group are conveyed to the PCEP peer. The Operator- 446 configured Association Range MUST be set for this association-type to 447 mark a range of Association Identifiers that are used for operator- 448 configured associations to avoid any Association Identifier clash 449 within the scope of the Association Source (Refer to [RFC8697]). 451 Specifically, for the PCE Initiated Bidirectional LSPs, these 452 Associations are dynamically created by the PCE on the PCE peers. 453 Similarly, for both PCE Initiated and PCC Initiated single-sided 454 case, these associations are also dynamically created on the remote 455 endpoint node using the information received from the RSVP message 456 from the originating node. 458 The Association ID, Association Source, optional Global Association 459 Source and optional Extended Association ID in the Bidirectional LSP 460 Association Object are initialized using the procedures defined in 461 [RFC8697] and [RFC7551]. 463 [RFC8697] specifies the mechanism for the capability advertisement of 464 the Association Types supported by a PCEP speaker by defining an 465 ASSOC-Type-List TLV to be carried within an OPEN Object. This 466 capability exchange for the Bidirectional LSP Association Types MUST 467 be done before using the Bidirectional LSP Association. Thus, the 468 PCEP speaker MUST include the Bidirectional LSP Association Types in 469 the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 470 before using the Bidirectional LSP Association in PCEP messages. 472 4.2. Bidirectional LSP Association Group TLV 474 The "Bidirectional LSP Association Group TLV" an OPTIONAL TLV for use 475 with the Bidirectional LSP Associations (ASSOCIATION Object with 476 Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for 477 Double-sided Bidirectional LSP). 479 o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV 480 format from [RFC5440]. 482 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 484 o The Length is 4 Bytes. 486 o The value comprises of a single field, the Bidirectional LSP 487 Association Flag (32 bits), where each bit represents a flag 488 option. 490 o If the "Bidirectional LSP Association Group TLV" is missing, it 491 means the LSP is the forward LSP and it is not co-routed LSP. 493 o When "Bidirectional LSP Association Group TLV" is present, the F 494 flag MUST be set for the forward LSP for both co-routed and non 495 co-routed LSPs. 497 o For co-routed LSPs, this TLV MUST be present and C flag set. 499 o For reverse LSPs, this TLV MUST be present and R flag set. 501 o The "Bidirectional LSP Association Group TLV" MUST NOT be present 502 more than once. If it appears more than once, only the first 503 occurrence is processed and any others MUST be ignored. 505 The format of the "Bidirectional LSP Association Group TLV" is shown 506 in Figure 7: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type = TBD3 | Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Flags |C|R|F| 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 7: Bidirectional LSP Association Group TLV format 518 Flags for "Bidirectional LSP Association Group TLV" are defined as 519 following. 521 F (Forward LSP, 1 bit, Bit number 31) - Indicates whether the LSP 522 associated is the forward LSP of the bidirectional LSP. If this flag 523 is set, the LSP is a forward LSP. 525 R (Reverse LSP, 1 bit, Bit number 30) - Indicates whether the LSP 526 associated is the reverse LSP of the bidirectional LSP. If this flag 527 is set, the LSP is a reverse LSP. 529 C (Co-routed Path, 1 bit, Bit number 29) - Indicates whether the 530 bidirectional LSP is co-routed. This flag MUST be set for both the 531 forward and reverse LSPs of a co-routed bidirectional LSP. 533 The C flag is used by the PCE (for both Stateful and Stateless) to 534 compute bidirectional paths of the forward and reverse LSPs of a co- 535 routed bidirectional LSP. 537 The unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and 538 MUST be ignored when received. 540 5. PCEP Procedure 542 The PCEP procedure defined in this document is applicable to the 543 following three scenarios: 545 o Neither unidirectional LSP exists, and both must be established. 547 o Both unidirectional LSPs exist, but the association must be 548 established. 550 o One LSP exists, but the reverse associated LSP must be 551 established. 553 5.1. PCE Initiated LSPs 555 As specified in [RFC8697], the Bidirectional LSP Associations can be 556 created and updated by a Stateful PCE. 558 o For Single-sided Bidirectional LSP Association initiated by the 559 PCE, it MUST send PCInitiate message to the originating endpoint 560 node with both direction LSPs. For Double-sided Bidirectional LSP 561 Association initiated by the PCE, it MUST send PCInitiate message 562 to both endpoint nodes with forward direction LSPs. 564 o Both PCCs MUST report the forward and reverse LSPs in the 565 Bidirectional LSP Association to the PCE. PCC reports via PCRpt 566 message. 568 o Stateful PCE MAY create and update the forward and reverse LSPs 569 independently for the Single-sided Bidirectional LSP Association 570 on the originating endpoint node. 572 o Stateful PCE MAY create and update the forward LSP independently 573 for the Double-sided Bidirectional LSP Association on the endpoint 574 nodes. 576 o Stateful PCE establishes and removes the association relationship 577 on a per LSP basis. 579 o Stateful PCE creates and updates the LSP and the association on a 580 PCC via PCInitiate and PCUpd messages, respectively, using the 581 procedures described in [RFC8697]. 583 5.2. PCC Initiated LSPs 585 As specified in [RFC8697], the Bidirectional LSP Associations can 586 also be created and updated by a PCC. 588 o For Single-sided Bidirectional LSP Association initiated at a PCC, 589 it MUST send PCRpt message to the PCE with both direction LSPs. 590 For Double-sided Bidirectional LSP Association initiated at the 591 PCCs, both PCCs MUST send PCRpt message to the PCE with forward 592 direction LSPs. 594 o PCC on the originating endpoint node MAY create and update the 595 forward and reverse LSPs independently for the Single-sided 596 Bidirectional LSP Association. 598 o PCC on the endpoint nodes MAY create and update the forward LSP 599 independently for the Double-sided Bidirectional LSP Association. 601 o PCC establishes and removes the association group on a per LSP 602 basis. PCC MUST report the change in the association group of an 603 LSP to PCE(s) via PCRpt message. 605 o PCC reports the forward and reverse LSPs in the Bidirectional LSP 606 Association independently to PCE(s) via PCRpt message. 608 o PCC for the single-sided case MAY delegate the forward and reverse 609 LSPs independently to a Stateful PCE, where PCE would control the 610 LSPs. In this case, the originating (PCC) endpoint node SHOULD 611 delegate both forward and reverse LSPs of a tunnel together to a 612 Stateful PCE in order to avoid any race condition. 614 o PCCs for the double-sided case MAY delegate the forward LSPs to a 615 Stateful PCE, where PCE would control the LSPs. 617 o Stateful PCE updates the LSPs in the Bidirectional LSP Association 618 via PCUpd message, using the procedures described in [RFC8697]. 620 5.3. Stateless PCE 622 For a stateless PCE, it might be useful to associate a path 623 computation request to an association group, thus enabling it to 624 associate a common set of configuration parameters or behaviors with 625 the request [RFC8697]. A PCC can request co-routed or non-co-routed 626 forward and reverse direction paths from a stateless PCE for a 627 Bidirectional LSP Association. 629 5.4. Bidirectional (B) Flag 631 As defined in [RFC5440], the Bidirectional (B) flag in the Request 632 Parameters (RP) Object is set when the PCC specifies that the path 633 computation request is for a bidirectional TE LSP with the same TE 634 requirements in each direction. For an associated bidirectional LSP, 635 the B-flag is also set when the PCC makes the path computation 636 request for the same TE requirements for the forward and reverse 637 direction LSPs. 639 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 640 Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate 641 'bidirectional co-routed LSP' is used for GMPLS signaled 642 bidirectional LSPs and is not applicable to the associated 643 bidirectional LSPs. 645 5.5. PLSP-ID Usage 647 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 648 created by a PCC to uniquely identify an LSP and it remains the same 649 for the lifetime of a PCEP session. 651 In case of Single-sided Bidirectional LSP Association, the reverse 652 LSP of a bidirectional LSP created on the originating endpoint node 653 is identified by the PCE using 2 different PLSP-IDs based on the PCEP 654 session on the ingress or egress nodes for the LSP. In other words, 655 the reverse LSP will have a PLSP-ID P1 at the ingress node while it 656 will have a PLSP-ID P3 at the egress node. There is no change in the 657 PLSP-ID allocation procedure for the forward LSP of the Single-sided 658 Bidirectional LSP on the originating endpoint node. In case of 659 Double-sided Bidirectional LSP Association, there is no change in the 660 PLSP-ID allocation procedure. 662 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 663 MUST be included in all forward and reverse LSPs. 665 5.6. State Synchronization 667 During state synchronization, a PCC MUST report all the existing 668 Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. 669 After the state synchronization, the PCE MUST remove all stale 670 Bidirectional LSP Associations. 672 5.7. Error Handling 674 If a PCE speaker receives an LSP with a Bidirectional LSP Association 675 Type that it does not support, the PCE speaker MUST send PCErr with 676 Error-Type = 26 (Association Error) and Error-Value = 1 (Association 677 Type is not supported). 679 An LSP (forward or reverse) cannot be part of more than one 680 Bidirectional LSP Association. If a PCE speaker receives an LSP not 681 complying to this rule, the PCE speaker MUST send PCErr with Error- 682 Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional 683 LSP Association - Group Mismatch). 685 The LSPs (forward or reverse) in a Single-sided Bidirectional 686 Association MUST belong to the same TE Tunnel (as defined in 687 [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- 688 sided Bidirectional LSP Association for a different Tunnel, the PCE 689 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 690 Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 692 The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up 693 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP 694 speaker receives a different PST value for the Bidirectional LSP 695 Associations defined in this document, the PCE speaker MUST return a 696 PCErr message with Error-Type = 26 (Association Error) and Error- 697 Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not 698 Supported). 700 A Bidirectional LSP Association cannot have both unidirectional LSPs 701 identified as Reverse LSPs or both LSPs identified as Forward LSPs. 702 If a PCE speaker receives an LSP not complying to this rule, the PCE 703 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 704 Error-Value = TBD7 (Bidirectional LSP Association - Direction 705 Mismatch). 707 A Bidirectional LSP Association cannot have one unidirectional LSP 708 identified as co-routed and the other identified as non-co-routed. 709 If a PCE speaker receives an LSP not complying to this rule, the PCE 710 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 711 Error-Value = TBD8 (Bidirectional LSP Association - Co-routed 712 Mismatch). 714 The unidirectional LSPs forming the Bidirectional LSP Association 715 MUST have matching endpoint nodes in the reverse directions. If a 716 PCE speaker receives an LSP not complying to this rule, the PCE 717 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 718 Error-Value = TBD9 (Bidirectional LSP Association - Endpoint 719 Mismatch). 721 The processing rules as specified in Section 6.4 of [RFC8697] 722 continue to apply to the Association Types defined in this document. 724 6. Implementation Status 726 [Note to the RFC Editor - remove this section before publication, as 727 well as remove the reference to RFC 7942.] 729 This section records the status of known implementations of the 730 protocol defined by this specification at the time of posting of this 731 Internet-Draft, and is based on a proposal described in [RFC7942]. 732 The description of implementations in this section is intended to 733 assist the IETF in its decision processes in progressing drafts to 734 RFCs. Please note that the listing of any individual implementation 735 here does not imply endorsement by the IETF. Furthermore, no effort 736 has been spent to verify the information presented here that was 737 supplied by IETF contributors. This is not intended as, and must not 738 be construed to be, a catalog of available implementations or their 739 features. Readers are advised to note that other implementations may 740 exist. 742 According to [RFC7942], "this will allow reviewers and working groups 743 to assign due consideration to documents that have the benefit of 744 running code, which may serve as evidence of valuable experimentation 745 and feedback that have made the implemented protocols more mature. 746 It is up to the individual working groups to use this information as 747 they see fit". 749 6.1. Implementation 751 The PCEP extensions defined in this document has been implemented by 752 a vendor on their product. No further information is available at 753 this time. 755 7. Security Considerations 757 The security considerations described in [RFC5440], [RFC8231], and 758 [RFC8281] apply to the extensions defined in this document as well. 760 Two new Association Types for the ASSOCIATION Object, Single-sided 761 Bidirectional LSP Association and Double-sided Bidirectional LSP 762 Association are introduced in this document. Additional security 763 considerations related to LSP associations due to a malicious PCEP 764 speaker is described in [RFC8697] and apply to these Association 765 Types. Hence, securing the PCEP session using Transport Layer 766 Security (TLS) [RFC8253] is recommended. 768 8. Manageability Considerations 770 8.1. Control of Function and Policy 772 The mechanisms defined in this document do not imply any control or 773 policy requirements in addition to those already listed in [RFC5440], 774 [RFC8231], and [RFC8281]. 776 8.2. Information and Data Models 778 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 779 defined for LSP associations. 781 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 782 LSP associations. 784 8.3. Liveness Detection and Monitoring 786 The mechanisms defined in this document do not imply any new liveness 787 detection and monitoring requirements in addition to those already 788 listed in [RFC5440], [RFC8231], and [RFC8281]. 790 8.4. Verify Correct Operations 792 The mechanisms defined in this document do not imply any new 793 operation verification requirements in addition to those already 794 listed in [RFC5440], [RFC8231], and [RFC8281]. 796 8.5. Requirements On Other Protocols 798 The mechanisms defined in this document do not add any new 799 requirements on other protocols. 801 8.6. Impact On Network Operations 803 The mechanisms defined in this document do not have any impact on 804 network operations in addition to those already listed in [RFC5440], 805 [RFC8231], and [RFC8281]. 807 9. IANA Considerations 809 9.1. Association Types 811 This document defines two new Association Types, originally described 812 in [RFC8697]. IANA is requested to assign the following new values 813 in the "ASSOCIATION Type Field" subregistry [RFC8697] within the 814 "Path Computation Element Protocol (PCEP) Numbers" registry: 816 Type Name Reference 817 --------------------------------------------------------------------- 818 TBD1 Single-sided Bidirectional LSP Association [This document] 819 TBD2 Double-sided Bidirectional LSP Association [This document] 821 9.2. Bidirectional LSP Association Group TLV 823 This document defines a new TLV for carrying additional information 824 of LSPs within a Bidirectional LSP Association. IANA is requested to 825 add the assignment of a new value in the existing "PCEP TLV Type 826 Indicators" registry as follows: 828 Value Meaning Reference 829 ------------------------------------------------------------------- 830 TBD3 Bidirectional LSP Association Group TLV [This document] 832 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 834 This document requests that a new sub-registry, named "Bidirectional 835 LSP Association Group TLV Flag Field", is created within the "Path 836 Computation Element Protocol (PCEP) Numbers" registry to manage the 837 Flag field in the Bidirectional LSP Association Group TLV. New 838 values are to be assigned by Standards Action [RFC8126]. Each bit 839 should be tracked with the following qualities: 841 o Bit number (count from 0 as the most significant bit) 843 o Description 845 o Reference 847 The following values are defined in this document for the Flag field. 849 Bit No. Description Reference 850 --------------------------------------------------------- 851 31 F - Forward LSP [This document] 852 30 R - Reverse LSP [This document] 853 29 C - Co-routed Path [This document] 854 0-28 Unassigned 856 9.3. PCEP Errors 858 This document defines new Error value for Error Type 26 (Association 859 Error). IANA is requested to allocate new Error value within the 860 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 861 Numbers registry, as follows: 863 Error Type Description Reference 864 --------------------------------------------------------- 865 26 Association Error 867 Error value: TBD4 [This document] 868 Bidirectional LSP Association - Group Mismatch 870 Error value: TBD5 [This document] 871 Bidirectional LSP Association - Tunnel Mismatch 873 Error value: TBD6 [This document] 874 Bidirectional LSP Association - Path Setup Type 875 Not Supported 877 Error value: TBD7 [This document] 878 Bidirectional LSP Association - Direction Mismatch 880 Error value: TBD8 [This document] 881 Bidirectional LSP Association - Co-routed Mismatch 883 Error value: TBD9 [This document] 884 Bidirectional LSP Association - Endpoint Mismatch 886 10. References 888 10.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, 892 DOI 10.17487/RFC2119, March 1997, 893 . 895 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 896 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 897 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 898 . 900 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 901 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 902 DOI 10.17487/RFC5440, March 2009, 903 . 905 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 906 Extensions for Associated Bidirectional Label Switched 907 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 908 . 910 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 911 Writing an IANA Considerations Section in RFCs", BCP 26, 912 RFC 8126, DOI 10.17487/RFC8126, June 2017, 913 . 915 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 916 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 917 May 2017, . 919 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 920 Computation Element Communication Protocol (PCEP) 921 Extensions for Stateful PCE", RFC 8231, 922 DOI 10.17487/RFC8231, September 2017, 923 . 925 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 926 Computation Element Communication Protocol (PCEP) 927 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 928 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 929 . 931 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 932 the Fast Reroute Procedures for Co-routed Associated 933 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 934 DOI 10.17487/RFC8537, February 2019, 935 . 937 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 938 Dhody, D., and Y. Tanaka, "Path Computation Element 939 Communication Protocol (PCEP) Extensions for Establishing 940 Relationships between Sets of Label Switched Paths 941 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 942 . 944 10.2. Informative References 946 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 947 Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path 948 Computation Element (PCE) Protocol Extensions for Stateful 949 PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- 950 pcep-stateful-pce-gmpls-14 (work in progress), December 951 2020. 953 [I-D.ietf-pce-pcep-yang] 954 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 955 YANG Data Model for Path Computation Element 956 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 957 yang-15 (work in progress), October 2020. 959 [I-D.ietf-pce-sr-bidir-path] 960 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 961 "PCEP Extensions for Associated Bidirectional Segment 962 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work 963 in progress), September 2020. 965 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 966 Sprecher, N., and S. Ueno, "Requirements of an MPLS 967 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 968 September 2009, . 970 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 971 Hardwick, "Path Computation Element Communication Protocol 972 (PCEP) Management Information Base (MIB) Module", 973 RFC 7420, DOI 10.17487/RFC7420, December 2014, 974 . 976 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 977 Code: The Implementation Status Section", BCP 205, 978 RFC 7942, DOI 10.17487/RFC7942, July 2016, 979 . 981 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 982 Stateful Path Computation Element (PCE)", RFC 8051, 983 DOI 10.17487/RFC8051, January 2017, 984 . 986 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 987 "PCEPS: Usage of TLS to Provide a Secure Transport for the 988 Path Computation Element Communication Protocol (PCEP)", 989 RFC 8253, DOI 10.17487/RFC8253, October 2017, 990 . 992 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 993 Hardwick, "Conveying Path Setup Type in PCE Communication 994 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 995 July 2018, . 997 Acknowledgments 999 The authors would like to thank Dhruv Dhody for various discussions 1000 on association groups and inputs to this document. The authors would 1001 also like to thank Mike Taillon, Harish Sitaraman, and Marina Fizgeer 1002 for reviewing this document and providing valuable comments. 1004 Authors' Addresses 1006 Rakesh Gandhi (editor) 1007 Cisco Systems, Inc. 1008 Canada 1010 Email: rgandhi@cisco.com 1012 Colby Barth 1013 Juniper Networks 1015 Email: cbarth@juniper.net 1017 Bin Wen 1018 Comcast 1020 Email: Bin_Wen@cable.comcast.com