idnits 2.17.1 draft-ietf-pce-association-bidir-01.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 (May 18, 2018) is 2168 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 C. Barth 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Gandhi, Ed. 5 Expires: November 19, 2018 Cisco Systems, Inc. 6 B. Wen 7 Comcast 8 May 18, 2018 10 PCEP Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-01 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. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 66 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6 67 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7 68 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8 70 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 71 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 73 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 74 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11 75 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 76 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7. Manageability Considerations . . . . . . . . . . . . . . . . . 12 79 7.1. Control of Function and Policy . . . . . . . . . . . . . . 12 80 7.2. Information and Data Models . . . . . . . . . . . . . . . 12 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 82 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 83 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 84 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13 87 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13 88 8.2.1. Flag Fields in Bidirectional LSP Association Group 89 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 100 communication mechanism between a Path Computation Client (PCC) and a 101 Path Control Element (PCE), or between PCE and PCC, that enables 102 computation of Multiprotocol Label Switching (MPLS) Traffic 103 Engineering (TE) Label Switched Paths (LSPs). 105 [RFC8231] specifies extensions to PCEP to enable stateful control of 106 MPLS TE LSPs. It describes two modes of operation - Passive Stateful 107 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 108 Stateful PCE where LSPs are provisioned on the PCC and control over 109 them is delegated to a PCE. Further, [RFC8281] describes the setup, 110 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 111 model. 113 [I-D.ietf-pce-association] introduces a generic mechanism to create a 114 grouping of LSPs which can then be used to define associations 115 between a set of LSPs and/or a set of attributes, for example primary 116 and secondary LSP associations, and is equally applicable to the 117 active and passive modes of a Stateful PCE [RFC8231] or a stateless 118 PCE [RFC5440]. 120 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 121 specifies that MPLS-TP MUST support associated bidirectional 122 point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for 123 binding two reverse unidirectional LSPs [RFC3209] into an associated 124 bidirectional LSP. The fast reroute (FRR) procedures for associated 125 bidirectional LSPs are described in 126 [I-D.ietf-teas-assoc-corouted-bidir-frr]. 128 This document specifies PCEP extensions for grouping two reverse 129 unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for 130 both single-sided and double-sided initiation cases when using a 131 Stateful (both active and passive modes) or Stateless PCE. The PCEP 132 extensions cover the following cases: 134 o A PCC initiates the forward and/ or reverse LSP of a single-sided 135 or double-sided bidirectional LSP and retains the control of the 136 LSP. The PCC computes the path itself or makes a request for path 137 computation to a PCE. After the path setup, it reports the 138 information and state of the path to the PCE. This includes the 139 association group identifying the bidirectional LSP. This is the 140 Passive Stateful mode defined in [RFC8051]. 142 o A PCC initiates the forward and/ or reverse LSP of a single-sided 143 or double-sided bidirectional LSP and delegates the control of the 144 LSP to a Stateful PCE. During delegation the association group 145 identifying the bidirectional LSP is included. The PCE computes 146 the path of the LSP and updates the PCC with the information about 147 the path as long as it controls the LSP. This is the Active 148 Stateful mode defined in [RFC8051]. 150 o A PCE initiates the forward and/ or reverse LSP of a single-sided 151 or double-sided bidirectional LSP on a PCC and retains the control 152 of the LSP. The PCE is responsible for computing the path of the 153 LSP and updating the PCC with the information about the path as 154 well as the association group identifying the bidirectional LSP. 155 This is the PCE-Initiated mode defined in [RFC8281]. 157 o A PCC requests co-routed or non co-routed paths for forward and 158 reverse LSPs of a bidirectional LSP from a Stateless PCE 159 [RFC5440]. 161 2. Conventions Used in This Document 163 2.1. Key Word Definitions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 2.2. Terminology 173 The reader is assumed to be familiar with the terminology defined in 174 [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association]. 176 3. Overview 178 As shown in Figure 1, two reverse unidirectional LSPs can be grouped 179 to form an associated bidirectional LSP. There are two methods of 180 initiating the bidirectional LSP association, single-sided and 181 double-sided, as defined in [RFC7551] and described in the following 182 sections. 184 LSP1 --> LSP1 --> LSP1 --> 185 +-----+ +-----+ +-----+ +-----+ 186 | A +-----------+ B +-----------+ C +-----------+ D | 187 +-----+ +--+--+ +--+--+ +-----+ 188 <-- LSP2 | | <-- LSP2 189 | | 190 | | 191 +--+--+ +--+--+ 192 | E +-----------+ F | 193 +-----+ +-----+ 194 <-- LSP2 196 Figure 1: Example of Associated Bidirectional LSP 198 3.1. Single-sided Initiation 200 As specified in [RFC7551], in the single-sided case, the 201 bidirectional tunnel is provisioned only on one endpoint node (PCC) 202 of the tunnel. Both forward and reverse LSPs of this tunnel are 203 initiated with the Association Type set to "Single-sided 204 Bidirectional LSP Association" on the originating endpoint node. The 205 forward and reverse LSPs are identified in the Bidirectional LSP 206 Association Group TLV of their PCEP Association Objects. 208 The originating endpoint node signals the properties for the revere 209 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 210 message. The remote endpoint then creates the corresponding reverse 211 tunnel and signals the reverse LSP in response to the received RSVP 212 Path message. Similarly, the remote endpoint node deletes the 213 reverse LSP when it receives the RSVP Path delete message [RFC3209] 214 for the forward LSP. 216 The originating endpoint (PCC) node may report/ delegate the forward 217 and reverse LSPs to a PCE. The remote endpoint (PCC) node may report 218 the reverse LSP to a PCE. 220 +-----+ 221 | PCE | 222 +-----+ 223 Initiates: | ^ Reports: 224 Tunnel 1 (F) | \ Tunnel 2 (R) 225 (LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) 226 v \ 227 +-----+ +-----+ 228 | A | | D | 229 +-----+ +-----+ 231 Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP 232 +-----+ 233 | PCE | 234 +-----+ 235 Reports/Delegates: ^ ^ Reports: 236 Tunnel 1 (F) | \ Tunnel 2 (R) 237 (LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) 238 | \ 239 +-----+ +-----+ 240 | A | | D | 241 +-----+ +-----+ 243 Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP 245 As shown in Figures 2A and 2B, the forward tunnel and both forward 246 LSP1 and reverse LSP2 are initiated on the originating endpoint node 247 A, either by the PCE or the originating PCC. The originating 248 endpoint node A signals the properties of reverse LSP2 in the RSVP 249 REVERSE_LSP Object in the Path message of the forward LSP1. The 250 creation of reverse tunnel and reverse LSP2 on the remote endpoint 251 node D is triggered by the RSVP signaled forward LSP1. 253 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast 254 reroute bypass tunnel assignment, the LSP starting from the 255 originating node is identified as the forward LSP of the single-sided 256 initiated bidirectional LSP. 258 3.2. Double-sided Initiation 260 As specified in [RFC7551], in the double-sided case, the 261 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 262 the tunnel. The forward and reverse LSPs of this tunnel are 263 initiated with the Association Type set to "Double-sided 264 Bidirectional LSP Association" on both endpoint nodes. The forward 265 and reverse LSPs are identified in the Bidirectional LSP Association 266 Group TLV of their Association Objects. 268 The endpoint (PCC) nodes may report/ delegate the forward and reverse 269 LSPs to a PCE. 271 +-----+ 272 | PCE | 273 +-----+ 274 Initiates: | \ Initiates: 275 Tunnel 1 (F) | \ Tunnel 2 (R) 276 (LSP1 (F)) | \ (LSP2 (R)) 277 v v 278 +-----+ +-----+ 279 | A | | D | 280 +-----+ +-----+ 282 Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP 284 +-----+ 285 | PCE | 286 +-----+ 287 Reports/Delegates: ^ ^ Reports/Delegates: 288 Tunnel 1 (F) | \ Tunnel 2 (R) 289 (LSP1 (F)) | \ (LSP2 (R)) 290 | \ 291 +-----+ +-----+ 292 | A | | D | 293 +-----+ +-----+ 295 Figure 3B: Example of PCC-Initiated Double-sided Bidirectional LSP 297 As shown in Figures 3A and 3B, the forward tunnel and forward LSP1 298 are initiated on the endpoint node A and the reverse tunnel and 299 reverse LSP2 are initiated on the endpoint node D, either by the PCE 300 or the PCCs. 302 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast 303 reroute bypass tunnel assignment, the LSP with the higher Source 304 Address [RFC3209] is identified as the forward LSP of the 305 double-sided initiated bidirectional LSP. 307 3.3. Co-routed Associated Bidirectional LSP 309 In both single-sided and double-sided initiation cases, forward and 310 reverse LSPs may be co-routed as shown in Figure 4, where both 311 forward and reverse LSPs of a bidirectional LSP follow the same 312 congruent path in the forward and reverse directions, respectively. 314 LSP3 --> LSP3 --> LSP3 --> 315 +-----+ +-----+ +-----+ +-----+ 316 | A +-----------+ B +-----------+ C +-----------+ D | 317 +-----+ +-----+ +-----+ +-----+ 318 <-- LSP4 <-- LSP4 <-- LSP4 320 Figure 4: Example of Co-routed Associated Bidirectional LSP 322 4. Protocol Extensions 324 4.1. Association Object 326 As per [I-D.ietf-pce-association], LSPs are associated by adding them 327 to a common association group. This document defines two new 328 Bidirectional LSP Association Groups to be used by the associated 329 bidirectional LSPs. A member of the Bidirectional LSP Association 330 Group can take the role of a forward or reverse LSP and follows the 331 following rules: 333 o An LSP (forward or reverse) can not be part of more than one 334 Bidirectional LSP Association Group. More than one forward LSP 335 and/ or reverse LSP can be part of a Bidirectional LSP Association 336 Group. 338 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 339 of the single-sided bidirectional LSP association on the 340 originating node MUST be the same. 342 This document defines two new Association Types for the Association 343 Object as follows: 345 o Association Type (TBD1) = Single-sided Bidirectional LSP 346 Association Group 348 o Association Type (TBD2) = Double-sided Bidirectional LSP 349 Association Group 351 These Association Types are operator-configured associations in 352 nature and statically created by the operator on the PCEP peers. The 353 LSP belonging to these associations is conveyed via PCEP messages to 354 the PCEP peer. Operator-configured Association Range TLV 355 [I-D.ietf-pce-association] MUST NOT be sent for these Association 356 Types, and MUST be ignored, so that the entire range of association 357 ID can be used for them. 359 The Association ID, Association Source, optional Global Association 360 Source and optional Extended Association ID in the Bidirectional LSP 361 Association Group Object are initialized using the procedures defined 362 in [I-D.ietf-pce-association] and [RFC7551]. 364 4.2. Bidirectional LSP Association Group TLV 366 The Bidirectional LSP Association Group TLV is defined for use with 367 the Single-sided and Double-sided Bidirectional LSP Association Group 368 Object Types. 370 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 371 format from [RFC5440]. 373 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 375 o The Length is 4 Bytes. 377 o The value comprises of a single field, the Bidirectional LSP 378 Association Flags (32 bits), where each bit represents a flag 379 option. 381 o If the Bidirectional LSP Association Group TLV is missing, it 382 means the LSP is the forward LSP and it is not co-routed LSP. 384 o For co-routed LSPs, this TLV MUST be present. 386 o For reverse LSPs, this TLV MUST be present. 388 o The Bidirectional LSP Association Group TLV MUST NOT be present 389 more than once. If it appears more than once, only the first 390 occurrence is processed and any others MUST be ignored. 392 The format of the Bidirectional LSP Association Group TLV is shown in 393 Figure 5: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = TBD3 | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Reserved |C|R|F| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 5: Bidirectional LSP Association Group TLV format 405 Bidirectional LSP Association Flags are defined as following. 407 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 408 forward LSP of the bidirectional LSP. If this flag is set, the LSP 409 is a forward LSP. 411 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 412 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 413 is a reverse LSP. 415 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 416 co-routed. This flag MUST be set for both the forward and reverse 417 LSPs of a co-routed bidirectional LSP. 419 The C flag is used by the PCE (for both Stateful and Stateless) to 420 compute bidirectional paths of the forward and reverse LSPs of a 421 co-routed bidirectional LSP. 423 The Reserved flags MUST be set to 0 when sent and MUST be ignored 424 when received. 426 5. PCEP Procedure 428 5.1. PCE Initiated LSPs 430 As specified in [I-D.ietf-pce-association], Bidirectional LSP 431 Association Groups can be created by a Stateful PCE. 433 o Stateful PCE can create and update the forward and reverse LSPs 434 independently for both single-sided and double-sided bidirectional 435 LSP association groups. 437 o Stateful PCE can establish and remove the association relationship 438 on a per LSP basis. 440 o Stateful PCE can create and update the LSP and the association on 441 a PCC via PCInitiate and PCUpd messages, respectively, using the 442 procedures described in [I-D.ietf-pce-association]. 444 5.2. PCC Initiated LSPs 446 As specified in [I-D.ietf-pce-association], Bidirectional LSP 447 Association Groups can also be created by a PCC. 449 o PCC can create and update the forward and reverse LSPs 450 independently for both single-sided and double-sided bidirectional 451 LSP association groups. 453 o PCC can establish and remove the association relationship on a per 454 LSP basis. 456 o PCC MUST report the change in the association group of an LSP to 457 PCE(s) via PCRpt message. 459 o PCC can report the forward and reverse LSPs independently to 460 PCE(s) via PCRpt message. 462 o PCC can delegate the forward and reverse LSPs independently to a 463 Stateful PCE, where PCE would control the LSPs. For single-sided 464 case, originating (PCC) node can delegate both forward and reverse 465 LSPs of a tunnel together to a Stateful PCE in order to avoid any 466 race condition. 468 o Stateful PCE can update the LSPs in the bidirectional LSP 469 association group via PCUpd message, using the procedures 470 described in [I-D.ietf-pce-association]. 472 5.3. Stateless PCE 474 For a stateless PCE, it might be useful to associate a path 475 computation request to an association group, thus enabling it to 476 associate a common set of configuration parameters or behaviors with 477 the request. A PCC can request co-routed or non co-routed forward 478 and reverse direction paths from a stateless PCE for a bidirectional 479 LSP association group. 481 5.4. State Synchronization 483 During state synchronization, a PCC MUST report all the existing 484 bidirectional LSP association groups to the Stateful PCE as per 485 [I-D.ietf-pce-association]. After the state synchronization, the PCE 486 MUST remove all stale bidirectional LSP associations. 488 5.5. Error Handling 490 An LSP (forward or reverse) can not be part of more than one 491 Bidirectional LSP Association Group. If a PCE attempts to add an LSP 492 not complying to this rule, the PCC MUST send PCErr with Error-Type = 493 29 (Early allocation by IANA) (Association Error) and Error-Value = 494 TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if 495 a PCC attempts to add an LSP at PCE not complying to this rule, the 496 PCE MUST send this PCErr. 498 The LSPs (forward or reverse) in a single-sided bidirectional LSP 499 association group MUST belong to the same TE Tunnel (as defined in 500 [RFC3209]). If a PCE attempts to add an LSP in a single-sided 501 bidirectional LSP association group for a different Tunnel, the PCC 502 MUST send PCErr with Error-Type = 29 (Early allocation by IANA) 503 (Association Error) and Error-Value = TBD5 (Bidirectional LSP 504 Association - Tunnel Mismatch). Similarly, if a PCC attempts to add 505 an LSP to a single-sided bidirectional LSP association group at PCE 506 not complying to this rule, the PCE MUST send this PCErr. 508 6. Security Considerations 510 The security considerations described in [RFC5440], [RFC8231], and 511 [RFC8281] apply to the extensions defined in this document as well. 513 Two new Association Types for the Association Object, Single-sided 514 Bidirectional LSP Association Group and Double-sided Associated 515 Bidirectional LSP Group are introduced in this document. Additional 516 security considerations related to LSP associations due to a 517 malicious PCEP speaker is described in [I-D.ietf-pce-association] and 518 apply to these Association Types. Hence, securing the PCEP session 519 using Transport Layer Security (TLS) [RFC8253] is recommended. 521 7. Manageability Considerations 523 7.1. Control of Function and Policy 525 The mechanisms defined in this document do not imply any control or 526 policy requirements in addition to those already listed in [RFC5440], 527 [RFC8231], and [RFC8281]. 529 7.2. Information and Data Models 531 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 532 defined for LSP associations. 534 The PCEP YANG module [I-D.ietf-pce-pcep-yang] supports LSP 535 associations. 537 7.3. Liveness Detection and Monitoring 539 The mechanisms defined in this document do not imply any new liveness 540 detection and monitoring requirements in addition to those already 541 listed in [RFC5440], [RFC8231], and [RFC8281]. 543 7.4. Verify Correct Operations 545 The mechanisms defined in this document do not imply any new 546 operation verification requirements in addition to those already 547 listed in [RFC5440], [RFC8231], and [RFC8281]. 549 7.5. Requirements On Other Protocols 551 The mechanisms defined in this document do not add any new 552 requirements on other protocols. 554 7.6. Impact On Network Operations 556 The mechanisms defined in this document do not have any impact on 557 network operations in addition to those already listed in [RFC5440], 558 [RFC8231], and [RFC8281]. 560 8. IANA Considerations 562 8.1. Association Types 564 This document adds new Association Types for the Association Object 565 defined [I-D.ietf-pce-association]. IANA is requested to make the 566 assignment of values for the sub-registry "ASSOCIATION Type Field" 567 (to be created in [I-D.ietf-pce-association]), as follows: 569 Value Name Reference 570 --------------------------------------------------------------------- 571 TBD1 Single-sided Bidirectional LSP Association Group [This document] 572 TBD2 Double-sided Bidirectional LSP Association Group [This document] 574 8.2. Bidirectional LSP Association Group TLV 576 This document defines a new TLV for carrying additional information 577 of LSPs within a Bidirectional LSP Association Group. IANA is 578 requested to add the assignment of a new value in the existing "PCEP 579 TLV Type Indicators" registry as follows: 581 TLV-Type Name Reference 582 ------------------------------------------------------------------- 583 TBD3 Bidirectional LSP Association Group TLV [This document] 585 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 587 This document requests that a new sub-registry, named "Bidirectional 588 LSP Association Group TLV Flag Field", is created within the "Path 589 Computation Element Protocol (PCEP) Numbers" registry to manage the 590 Flag field in the Bidirectional LSP Association Group TLV. New 591 values are to be assigned by Standards Action [RFC8126]. Each bit 592 should be tracked with the following qualities: 594 o Bit number (count from 0 as the most significant bit) 595 o Description 597 o Reference 599 The following values are defined in this document for the Flag field. 601 Bit No. Description Reference 602 --------------------------------------------------------- 603 31 F - Forward LSP [This document] 604 30 R - Reverse LSP [This document] 605 29 C - Co-routed LSP [This document] 607 8.3. PCEP Errors 609 This document defines new Error value for Error Type 29 (Association 610 Error). IANA is requested to allocate new Error value within the 611 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 612 Numbers registry, as follows: 614 Error Type Description Reference 615 --------------------------------------------------------------------- 616 29 Association Error 618 Error value: TBD4 [This document] 619 Bidirectional LSP Association - Group Mismatch 621 Error value: TBD5 [This document] 622 Bidirectional LSP Association - Tunnel Mismatch 624 9. References 626 9.1. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, DOI 630 10.17487/RFC2119, March 1997. 632 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 633 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 634 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001. 636 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 637 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 638 March 2009. 640 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 641 Extensions for Associated Bidirectional LSPs", RFC 7551, 642 May 2015. 644 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 645 Writing an IANA Considerations Section in RFCs", BCP 26, 646 RFC 8126, DOI 10.17487/RFC8126, June 2017. 648 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 649 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 650 May 2017, . 652 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 653 Computation Element Communication Protocol (PCEP) 654 Extensions for Stateful PCE", RFC 8231, DOI 655 10.17487/RFC8231, September 2017. 657 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 658 Extensions for PCE-initiated LSP Setup in a Stateful PCE 659 Model", RFC 8281, December 2017. 661 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 662 Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP 663 Extensions for Establishing Relationships Between Sets of 664 LSPs", draft-ietf-pce-association-group (work in 665 progress). 667 [I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H., 668 and J. Whittaker, "Fast Reroute Procedures for Co-routed 669 Associated Bidirectional Label Switched Paths (LSPs)", 670 draft-ietf-teas-assoc-corouted-bidir-frr (work in 671 progress). 673 9.2. Informative References 675 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 676 Sprecher, N., and S. Ueno, "Requirements of an MPLS 677 Transport Profile", RFC 5654, September 2009. 679 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 680 Hardwick, "Path Computation Element Communication Protocol 681 (PCEP) Management Information Base (MIB) Module", RFC 682 7420, December 2014. 684 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 685 Stateful Path Computation Element (PCE)", RFC 8051, 686 January 2017. 688 [RFC8253] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage 689 of TLS to Provide a Secure Transport for the Path 690 Computation Element Communication Protocol (PCEP)", RFC 691 8253, October 2017. 693 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 694 Tantsura, "A YANG Data Model for Path Computation Element 695 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 696 (work in progress). 698 Acknowledgments 700 The authors would like to thank Dhruv Dhody for various discussions 701 on association groups. The authors would also like to thank Dhruv 702 Dhody and Mike Taillon for reviewing this document and providing 703 valuable comments. 705 Authors' Addresses 707 Colby Barth 708 Juniper Networks 710 Email: cbarth@juniper.net 712 Rakesh Gandhi (editor) 713 Cisco Systems, Inc. 714 Canada 716 Email: rgandhi@cisco.com 718 Bin Wen 719 Comcast 721 Email: Bin_Wen@cable.comcast.com