idnits 2.17.1 draft-ietf-pce-association-bidir-03.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 (March 11, 2019) is 1872 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 12, 2019 Juniper Networks 6 B. Wen 7 Comcast 8 March 11, 2019 10 PCEP Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-03 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 reverse 24 unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when 25 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 26 well as when using a Stateless PCE. The procedures defined are 27 applicable to the LSPs using Resource Reservation Protocol (RSVP) for 28 signaling. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 68 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6 69 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7 70 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 73 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 75 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 76 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11 77 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . . 11 78 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 11 79 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 80 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. Manageability Considerations . . . . . . . . . . . . . . . . . 13 83 7.1. Control of Function and Policy . . . . . . . . . . . . . . 13 84 7.2. Information and Data Models . . . . . . . . . . . . . . . 13 85 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 86 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 87 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 88 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 14 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 91 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 14 92 8.2.1. Flag Fields in Bidirectional LSP Association Group 93 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 98 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 104 communication mechanism between a Path Computation Client (PCC) and a 105 Path Control Element (PCE), or between PCE and PCC, that enables 106 computation of Multiprotocol Label Switching (MPLS) Traffic 107 Engineering (TE) Label Switched Paths (LSPs). 109 [RFC8231] specifies extensions to PCEP to enable stateful control of 110 MPLS TE LSPs. It describes two modes of operation - Passive Stateful 111 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 112 Stateful PCE where LSPs are provisioned on the PCC and control over 113 them is delegated to a PCE. Further, [RFC8281] describes the setup, 114 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 115 model. 117 [I-D.ietf-pce-association] introduces a generic mechanism to create a 118 grouping of LSPs which can then be used to define associations 119 between a set of LSPs and/or a set of attributes, for example primary 120 and secondary LSP associations, and is equally applicable to the 121 active and passive modes of a Stateful PCE [RFC8231] or a stateless 122 PCE [RFC5440]. 124 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 125 specifies that MPLS-TP MUST support associated bidirectional 126 point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for 127 binding two reverse unidirectional LSPs [RFC3209] into an associated 128 bidirectional LSP. The fast reroute (FRR) procedures for associated 129 bidirectional LSPs are described in [RFC8537]. 131 This document defines PCEP extensions for grouping two reverse 132 unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for 133 both single-sided and double-sided initiation cases when using a 134 Stateful (both active and passive modes) or Stateless PCE. The 135 procedures defined are applicable to the LSPs using Resource 136 Reservation Protocol (RSVP) for signaling [RFC3209]. The PCEP 137 extensions cover the following cases: 139 o A PCC initiates the forward and/ or reverse LSP of a single-sided 140 or double-sided bidirectional LSP and retains the control of the 141 LSP. The PCC computes the path itself or makes a request for path 142 computation to a PCE. After the path setup, it reports the 143 information and state of the path to the PCE. This includes the 144 association group identifying the bidirectional LSP. This is the 145 Passive Stateful mode defined in [RFC8051]. 147 o A PCC initiates the forward and/ or reverse LSP of a single-sided 148 or double-sided bidirectional LSP and delegates the control of the 149 LSP to a Stateful PCE. During delegation the association group 150 identifying the bidirectional LSP is included. The PCE computes 151 the path of the LSP and updates the PCC with the information about 152 the path as long as it controls the LSP. This is the Active 153 Stateful mode defined in [RFC8051]. 155 o A PCE initiates the forward and/ or reverse LSP of a single-sided 156 or double-sided bidirectional LSP on a PCC and retains the control 157 of the LSP. The PCE is responsible for computing the path of the 158 LSP and updating the PCC with the information about the path as 159 well as the association group identifying the bidirectional LSP. 160 This is the PCE-Initiated mode defined in [RFC8281]. 162 o A PCC requests co-routed or non co-routed paths for forward and 163 reverse LSPs of a bidirectional LSP from a Stateless PCE 164 [RFC5440]. 166 2. Conventions Used in This Document 168 2.1. Key Word Definitions 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 2.2. Terminology 178 The reader is assumed to be familiar with the terminology defined in 179 [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association]. 181 3. Overview 183 As shown in Figure 1, two reverse unidirectional LSPs can be grouped 184 to form an associated bidirectional LSP. There are two methods of 185 initiating the bidirectional LSP association, single-sided and 186 double-sided, as defined in [RFC7551] and described in the following 187 sections. 189 LSP1 --> LSP1 --> LSP1 --> 190 +-----+ +-----+ +-----+ +-----+ 191 | A +-----------+ B +-----------+ C +-----------+ D | 192 +-----+ +--+--+ +--+--+ +-----+ 193 <-- LSP2 | | <-- LSP2 194 | | 195 | | 196 +--+--+ +--+--+ 197 | E +-----------+ F | 198 +-----+ +-----+ 199 <-- LSP2 201 Figure 1: Example of Associated Bidirectional LSP 203 3.1. Single-sided Initiation 205 As specified in [RFC7551], in the single-sided case, the 206 bidirectional tunnel is provisioned only on one endpoint node (PCC) 207 of the tunnel. Both forward and reverse LSPs of this tunnel are 208 initiated with the Association Type set to "Single-sided 209 Bidirectional LSP Association" on the originating endpoint node. The 210 forward and reverse LSPs are identified in the Bidirectional LSP 211 Association Group TLV of their PCEP Association Objects. 213 The originating endpoint node signals the properties for the revere 214 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 215 message. The remote endpoint then creates the corresponding reverse 216 tunnel and signals the reverse LSP in response to the received RSVP 217 Path message. Similarly, the remote endpoint node deletes the 218 reverse LSP when it receives the RSVP Path delete message [RFC3209] 219 for the forward LSP. 221 The originating endpoint (PCC) node may report/ delegate the forward 222 and reverse direction LSPs to a PCE. The remote endpoint (PCC) node 223 may report its forward direction LSP to a PCE. 225 +-----+ 226 | PCE | 227 +-----+ 228 Initiates: | ^ Reports: 229 Tunnel 1 (F) | \ Tunnel 2 (F) 230 (LSP1 (F), LSP2 (R)) | \ (LSP2 (F)) 231 Association #1 v \ Association #1 232 +-----+ +-----+ 233 | A | | D | 234 +-----+ +-----+ 236 Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP 237 +-----+ 238 | PCE | 239 +-----+ 240 Reports/Delegates: ^ ^ Reports: 241 Tunnel 1 (F) | \ Tunnel 2 (F) 242 (LSP1 (F), LSP2 (R)) | \ (LSP2 (F)) 243 Association #2 | \ Association #2 244 +-----+ +-----+ 245 | A | | D | 246 +-----+ +-----+ 248 Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP 250 As shown in Figures 2A and 2B, the forward tunnel and both forward 251 LSP1 and reverse LSP2 are initiated on the originating endpoint node 252 A, either by the PCE or the originating PCC, respectively. The 253 originating endpoint node A signals the properties of reverse LSP2 in 254 the RSVP REVERSE_LSP Object in the Path message of the forward LSP1. 255 The creation of reverse tunnel and reverse LSP2 on the remote 256 endpoint node D is triggered by the RSVP signaled forward LSP1. 258 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 259 the LSP starting from the originating node is identified as the 260 forward LSP of the single-sided initiated bidirectional LSP. 262 3.2. Double-sided Initiation 264 As specified in [RFC7551], in the double-sided case, the 265 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 266 the tunnel. The forward and reverse LSPs of this tunnel are 267 initiated with the Association Type set to "Double-sided 268 Bidirectional LSP Association" on both endpoint nodes. The forward 269 and reverse LSPs are identified in the Bidirectional LSP Association 270 Group TLV of their Association Objects. 272 The endpoint (PCC) nodes may report/ delegate the forward and reverse 273 direction LSPs to a PCE. 275 +-----+ 276 | PCE | 277 +-----+ 278 Initiates: | \ Initiates: 279 Tunnel 1 (F) | \ Tunnel 2 (F) 280 (LSP1 (F)) | \ (LSP2 (F)) 281 Association #3 v v Association #3 282 +-----+ +-----+ 283 | A | | D | 284 +-----+ +-----+ 286 Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP 288 +-----+ 289 | PCE | 290 +-----+ 291 Reports/Delegates: ^ ^ Reports/Delegates: 292 Tunnel 1 (F) | \ Tunnel 2 (F) 293 (LSP1 (F)) | \ (LSP2 (F)) 294 Association #4 | \ Association #4 295 +-----+ +-----+ 296 | A | | D | 297 +-----+ +-----+ 299 Figure 3B: Example of PCC-Initiated Double-sided Bidirectional LSP 301 As shown in Figures 3A and 3B, the forward tunnel and forward LSP1 302 are initiated on the endpoint node A and the reverse tunnel and 303 reverse LSP2 are initiated on the endpoint node D, either by the PCE 304 or the PCCs, respectively. 306 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 307 the LSP with the higher Source Address [RFC3209] is identified as the 308 forward LSP of the double-sided initiated bidirectional LSP. 310 3.3. Co-routed Associated Bidirectional LSP 312 In both single-sided and double-sided initiation cases, forward and 313 reverse LSPs may be co-routed as shown in Figure 4, where both 314 forward and reverse LSPs of a bidirectional LSP follow the same 315 congruent path in the forward and reverse directions, respectively. 317 LSP3 --> LSP3 --> LSP3 --> 318 +-----+ +-----+ +-----+ +-----+ 319 | A +-----------+ B +-----------+ C +-----------+ D | 320 +-----+ +-----+ +-----+ +-----+ 321 <-- LSP4 <-- LSP4 <-- LSP4 323 Figure 4: Example of Co-routed Associated Bidirectional LSP 325 4. Protocol Extensions 327 4.1. Association Object 329 As per [I-D.ietf-pce-association], LSPs are associated by adding them 330 to a common association group. This document defines two new 331 Bidirectional LSP Association Groups to be used by the associated 332 bidirectional LSPs. A member of the Bidirectional LSP Association 333 Group can take the role of a forward or reverse LSP and follows the 334 following rules: 336 o An LSP (forward or reverse) can not be part of more than one 337 Bidirectional LSP Association Group. More than one forward LSP 338 and/ or reverse LSP can be part of a Bidirectional LSP Association 339 Group. 341 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 342 of the single-sided bidirectional LSP association on the 343 originating node MUST be the same. 345 This document defines two new Association Types for the Association 346 Object as follows: 348 o Association Type (TBD1) = Single-sided Bidirectional LSP 349 Association Group 351 o Association Type (TBD2) = Double-sided Bidirectional LSP 352 Association Group 354 These Association Types are operator-configured associations in 355 nature and statically created by the operator on the PCEP peers. The 356 LSP belonging to these associations is conveyed via PCEP messages to 357 the PCEP peer. Operator-configured Association Range TLV 358 [I-D.ietf-pce-association] MUST NOT be sent for these Association 359 Types, and MUST be ignored, so that the entire range of association 360 ID can be used for them. 362 The Association ID, Association Source, optional Global Association 363 Source and optional Extended Association ID in the Bidirectional LSP 364 Association Group Object are initialized using the procedures defined 365 in [I-D.ietf-pce-association] and [RFC7551]. 367 4.2. Bidirectional LSP Association Group TLV 369 The Bidirectional LSP Association Group TLV is defined for use with 370 the Single-sided and Double-sided Bidirectional LSP Association Group 371 Object Types. 373 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 374 format from [RFC5440]. 376 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 378 o The Length is 4 Bytes. 380 o The value comprises of a single field, the Bidirectional LSP 381 Association Flags (32 bits), where each bit represents a flag 382 option. 384 o If the Bidirectional LSP Association Group TLV is missing, it 385 means the LSP is the forward LSP and it is not co-routed LSP. 387 o For co-routed LSPs, this TLV MUST be present. 389 o For reverse LSPs, this TLV MUST be present. 391 o The Bidirectional LSP Association Group TLV MUST NOT be present 392 more than once. If it appears more than once, only the first 393 occurrence is processed and any others MUST be ignored. 395 The format of the Bidirectional LSP Association Group TLV is shown in 396 Figure 5: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type = TBD3 | Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Reserved |C|R|F| 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 5: Bidirectional LSP Association Group TLV format 408 Bidirectional LSP Association Flags are defined as following. 410 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 411 forward LSP of the bidirectional LSP. If this flag is set, the LSP 412 is a forward LSP. 414 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 415 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 416 is a reverse LSP. 418 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 419 co-routed. This flag MUST be set for both the forward and reverse 420 LSPs of a co-routed bidirectional LSP. 422 The C flag is used by the PCE (for both Stateful and Stateless) to 423 compute bidirectional paths of the forward and reverse LSPs of a 424 co-routed bidirectional LSP. 426 The Reserved flags MUST be set to 0 when sent and MUST be ignored 427 when received. 429 5. PCEP Procedure 431 5.1. PCE Initiated LSPs 433 As specified in [I-D.ietf-pce-association], the Bidirectional LSP 434 Association Groups can be created by a Stateful PCE. 436 o Stateful PCE can create and update the forward and reverse LSPs 437 independently for both single-sided and double-sided bidirectional 438 LSP association groups. 440 o Stateful PCE can establish and remove the association relationship 441 on a per LSP basis. 443 o Stateful PCE can create and update the LSP and the association on 444 a PCC via PCInitiate and PCUpd messages, respectively, using the 445 procedures described in [I-D.ietf-pce-association]. 447 5.2. PCC Initiated LSPs 449 As specified in [I-D.ietf-pce-association], Bidirectional LSP 450 Association Groups can also be created by a PCC. 452 o PCC can create and update the forward and reverse LSPs 453 independently for both single-sided and double-sided bidirectional 454 LSP association groups. 456 o PCC can establish and remove the association relationship on a per 457 LSP basis. 459 o PCC MUST report the change in the association group of an LSP to 460 PCE(s) via PCRpt message. 462 o PCC can report the forward and reverse LSPs independently to 463 PCE(s) via PCRpt message. 465 o PCC can delegate the forward and reverse LSPs independently to a 466 Stateful PCE, where PCE would control the LSPs. For single-sided 467 case, originating (PCC) node can delegate both forward and reverse 468 LSPs of a tunnel together to a Stateful PCE in order to avoid any 469 race condition. 471 o Stateful PCE can update the LSPs in the bidirectional LSP 472 association group via PCUpd message, using the procedures 473 described in [I-D.ietf-pce-association]. 475 5.3. Stateless PCE 477 For a stateless PCE, it might be useful to associate a path 478 computation request to an association group, thus enabling it to 479 associate a common set of configuration parameters or behaviors with 480 the request. A PCC can request co-routed or non co-routed forward 481 and reverse direction paths from a stateless PCE for a bidirectional 482 LSP association group. 484 5.4. Bidirectional (B) Flag 486 As defined in [RFC5440], the Bidirectional (B) flag in the Request 487 Parameters (RP) object is set when the PCC specifies that the path 488 computation request is for a bidirectional TE LSP with the same TE 489 requirements (e.g. latency) in each direction. For an associated 490 bidirectional LSP, the B-flag MAY be set when the PCC makes the path 491 computation request for the same TE requirements in the forward and 492 reverse directions. When a stateful PCE initiates or updates the 493 bidirectional LSPs, the B-flag in Stateful PCE Request Parameters 494 (SRP) object [RFC8231] MAY also be set. 496 5.5. PLSP-ID Usage 498 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 499 created by a PCC to uniquely identify each LSP and is constant for 500 the lifetime of a PCEP session. 502 In case of single-sided bidirectional LSP association, the reverse 503 LSP of a bidirectional LSP on the originating node is identified 504 using 2 different PLSP-IDs based on the PCEP session on the ingress 505 or egress nodes for the LSP. In other words, the reverse LSP on the 506 originating node will have a PLSP-ID A at the ingress node while it 507 will have a PLSP-ID B at the egress node. This is not the case for 508 the forward LSP of the single-sided bidirectional LSP on the 509 originating node and there is no change in the PLSP-ID allocation for 510 it. 512 In case of double-sided bidirectional LSP association, there is no 513 change in the PLSP-ID allocation. 515 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 516 MUST be included in all forward and reverse LSPs. 518 5.6. State Synchronization 520 During state synchronization, a PCC MUST report all the existing 521 bidirectional LSP association groups to the Stateful PCE as per 522 [I-D.ietf-pce-association]. After the state synchronization, the PCE 523 MUST remove all stale bidirectional LSP associations. 525 5.7. Error Handling 527 An LSP (forward or reverse) can not be part of more than one 528 Bidirectional LSP Association Group. If a PCE attempts to add an LSP 529 not complying to this rule, the PCC MUST send PCErr with Error-Type = 530 29 (Early allocation by IANA) (Association Error) and Error-Value = 531 TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if 532 a PCC attempts to add an LSP at PCE not complying to this rule, the 533 PCE MUST send this PCErr. 535 The LSPs (forward or reverse) in a single-sided bidirectional LSP 536 association group MUST belong to the same TE Tunnel (as defined in 537 [RFC3209]). If a PCE attempts to add an LSP in a single-sided 538 bidirectional LSP association group for a different Tunnel, the PCC 539 MUST send PCErr with Error-Type = 29 (Early allocation by IANA) 540 (Association Error) and Error-Value = TBD5 (Bidirectional LSP 541 Association - Tunnel Mismatch). Similarly, if a PCC attempts to add 542 an LSP to a single-sided bidirectional LSP association group at PCE 543 not complying to this rule, the PCE MUST send this PCErr. 545 The PCEP Path Setup Type (PST) MUST be set to 'Path is set up using 546 the RSVP-TE signaling protocol' (Value 0) [RFC8408] for the LSP 547 belonging to the Bidirectional LSP Association Groups defined in this 548 document. In case a PCEP speaker receives a different PST value for 549 this association group, it MUST return a PCErr message with Error- 550 Type = 29 (Early allocation by IANA) (Association Error) and Error- 551 Value = TBD6 (Bidirectional LSP Association - Path Setup Type 552 Mismatch). 554 The processing rules as specified in Section 5.4 of 555 [I-D.ietf-pce-association] continue to apply for the Association 556 Types defined in this document. 558 6. Security Considerations 560 The security considerations described in [RFC5440], [RFC8231], and 561 [RFC8281] apply to the extensions defined in this document as well. 563 Two new Association Types for the Association Object, Single-sided 564 Bidirectional LSP Association Group and Double-sided Associated 565 Bidirectional LSP Group are introduced in this document. Additional 566 security considerations related to LSP associations due to a 567 malicious PCEP speaker is described in [I-D.ietf-pce-association] and 568 apply to these Association Types. Hence, securing the PCEP session 569 using Transport Layer Security (TLS) [RFC8253] is recommended. 571 7. Manageability Considerations 573 7.1. Control of Function and Policy 575 The mechanisms defined in this document do not imply any control or 576 policy requirements in addition to those already listed in [RFC5440], 577 [RFC8231], and [RFC8281]. 579 7.2. Information and Data Models 581 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 582 defined for LSP associations. 584 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 585 LSP associations. 587 7.3. Liveness Detection and Monitoring 589 The mechanisms defined in this document do not imply any new liveness 590 detection and monitoring requirements in addition to those already 591 listed in [RFC5440], [RFC8231], and [RFC8281]. 593 7.4. Verify Correct Operations 595 The mechanisms defined in this document do not imply any new 596 operation verification requirements in addition to those already 597 listed in [RFC5440], [RFC8231], and [RFC8281]. 599 7.5. Requirements On Other Protocols 600 The mechanisms defined in this document do not add any new 601 requirements on other protocols. 603 7.6. Impact On Network Operations 605 The mechanisms defined in this document do not have any impact on 606 network operations in addition to those already listed in [RFC5440], 607 [RFC8231], and [RFC8281]. 609 8. IANA Considerations 611 8.1. Association Types 613 This document adds new Association Types for the Association Object 614 defined [I-D.ietf-pce-association]. IANA is requested to make the 615 assignment of values for the sub-registry "ASSOCIATION Type Field" 616 (to be created in [I-D.ietf-pce-association]), as follows: 618 Value Name Reference 619 --------------------------------------------------------------------- 620 TBD1 Single-sided Bidirectional LSP Association Group [This document] 621 TBD2 Double-sided Bidirectional LSP Association Group [This document] 623 8.2. Bidirectional LSP Association Group TLV 625 This document defines a new TLV for carrying additional information 626 of LSPs within a Bidirectional LSP Association Group. IANA is 627 requested to add the assignment of a new value in the existing "PCEP 628 TLV Type Indicators" registry as follows: 630 TLV-Type Name Reference 631 ------------------------------------------------------------------- 632 TBD3 Bidirectional LSP Association Group TLV [This document] 634 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 636 This document requests that a new sub-registry, named "Bidirectional 637 LSP Association Group TLV Flag Field", is created within the "Path 638 Computation Element Protocol (PCEP) Numbers" registry to manage the 639 Flag field in the Bidirectional LSP Association Group TLV. New 640 values are to be assigned by Standards Action [RFC8126]. Each bit 641 should be tracked with the following qualities: 643 o Bit number (count from 0 as the most significant bit) 645 o Description 646 o Reference 648 The following values are defined in this document for the Flag field. 650 Bit No. Description Reference 651 --------------------------------------------------------- 652 31 F - Forward LSP [This document] 653 30 R - Reverse LSP [This document] 654 29 C - Co-routed LSP [This document] 656 8.3. PCEP Errors 658 This document defines new Error value for Error Type 29 (Association 659 Error). IANA is requested to allocate new Error value within the 660 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 661 Numbers registry, as follows: 663 Error Type Description Reference 664 --------------------------------------------------------------------- 665 29 Association Error 667 Error value: TBD4 [This document] 668 Bidirectional LSP Association - Group Mismatch 670 Error value: TBD5 [This document] 671 Bidirectional LSP Association - Tunnel Mismatch 673 Error value: TBD6 [This document] 674 Bidirectional LSP Association - Path Setup Type Mismatch 676 9. References 678 9.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, DOI 682 10.17487/RFC2119, March 1997. 684 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 685 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 686 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001. 688 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 689 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 690 March 2009. 692 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 693 Extensions for Associated Bidirectional LSPs", RFC 7551, 694 May 2015. 696 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 697 Writing an IANA Considerations Section in RFCs", BCP 26, 698 RFC 8126, DOI 10.17487/RFC8126, June 2017. 700 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 701 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 702 May 2017, . 704 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 705 Computation Element Communication Protocol (PCEP) 706 Extensions for Stateful PCE", RFC 8231, DOI 707 10.17487/RFC8231, September 2017. 709 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 710 Extensions for PCE-initiated LSP Setup in a Stateful PCE 711 Model", RFC 8281, December 2017. 713 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 714 the Fast Reroute Procedures for Co-routed Associated 715 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 716 February 2019. 718 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 719 Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP 720 Extensions for Establishing Relationships Between Sets of 721 LSPs", draft-ietf-pce-association-group (work in 722 progress). 724 9.2. Informative References 726 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 727 Sprecher, N., and S. Ueno, "Requirements of an MPLS 728 Transport Profile", RFC 5654, September 2009. 730 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 731 Hardwick, "Path Computation Element Communication Protocol 732 (PCEP) Management Information Base (MIB) Module", RFC 733 7420, December 2014. 735 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 736 Stateful Path Computation Element (PCE)", RFC 8051, 737 January 2017. 739 [RFC8253] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage 740 of TLS to Provide a Secure Transport for the Path 741 Computation Element Communication Protocol (PCEP)", RFC 742 8253, October 2017. 744 [RFC8408] Sivabalan, S., et al. "Conveying Path Setup Type in PCE 745 Communication Protocol (PCEP) Messages", RFC 8408, July 746 2018. 748 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 749 Tantsura, "A YANG Data Model for Path Computation Element 750 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 751 (work in progress). 753 Acknowledgments 755 The authors would like to thank Dhruv Dhody for various discussions 756 on association groups and inputs to this document. The authors would 757 also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for 758 reviewing this document and providing valuable comments. 760 Authors' Addresses 762 Rakesh Gandhi (editor) 763 Cisco Systems, Inc. 764 Canada 766 Email: rgandhi@cisco.com 768 Colby Barth 769 Juniper Networks 771 Email: cbarth@juniper.net 773 Bin Wen 774 Comcast 776 Email: Bin_Wen@cable.comcast.com