idnits 2.17.1 draft-ietf-pce-association-bidir-02.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 (November 14, 2018) is 1990 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: May 18, 2019 Cisco Systems, Inc. 6 B. Wen 7 Comcast 8 November 14, 2018 10 PCEP Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-02 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. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . . 11 76 5.5. State Synchronization . . . . . . . . . . . . . . . . . . 11 77 5.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Manageability Considerations . . . . . . . . . . . . . . . . . 12 80 7.1. Control of Function and Policy . . . . . . . . . . . . . . 12 81 7.2. Information and Data Models . . . . . . . . . . . . . . . 12 82 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 83 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 84 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 85 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13 88 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13 89 8.2.1. Flag Fields in Bidirectional LSP Association Group 90 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 101 communication mechanism between a Path Computation Client (PCC) and a 102 Path Control Element (PCE), or between PCE and PCC, that enables 103 computation of Multiprotocol Label Switching (MPLS) Traffic 104 Engineering (TE) Label Switched Paths (LSPs). 106 [RFC8231] specifies extensions to PCEP to enable stateful control of 107 MPLS TE LSPs. It describes two modes of operation - Passive Stateful 108 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 109 Stateful PCE where LSPs are provisioned on the PCC and control over 110 them is delegated to a PCE. Further, [RFC8281] describes the setup, 111 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 112 model. 114 [I-D.ietf-pce-association] introduces a generic mechanism to create a 115 grouping of LSPs which can then be used to define associations 116 between a set of LSPs and/or a set of attributes, for example primary 117 and secondary LSP associations, and is equally applicable to the 118 active and passive modes of a Stateful PCE [RFC8231] or a stateless 119 PCE [RFC5440]. 121 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 122 specifies that MPLS-TP MUST support associated bidirectional 123 point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for 124 binding two reverse unidirectional LSPs [RFC3209] into an associated 125 bidirectional LSP. The fast reroute (FRR) procedures for associated 126 bidirectional LSPs are described in 127 [I-D.ietf-teas-assoc-corouted-bidir-frr]. 129 This document specifies PCEP extensions for grouping two reverse 130 unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for 131 both single-sided and double-sided initiation cases when using a 132 Stateful (both active and passive modes) or Stateless PCE. The PCEP 133 extensions cover the following cases: 135 o A PCC initiates the forward and/ or reverse LSP of a single-sided 136 or double-sided bidirectional LSP and retains the control of the 137 LSP. The PCC computes the path itself or makes a request for path 138 computation to a PCE. After the path setup, it reports the 139 information and state of the path to the PCE. This includes the 140 association group identifying the bidirectional LSP. This is the 141 Passive Stateful mode defined in [RFC8051]. 143 o A PCC initiates the forward and/ or reverse LSP of a single-sided 144 or double-sided bidirectional LSP and delegates the control of the 145 LSP to a Stateful PCE. During delegation the association group 146 identifying the bidirectional LSP is included. The PCE computes 147 the path of the LSP and updates the PCC with the information about 148 the path as long as it controls the LSP. This is the Active 149 Stateful mode defined in [RFC8051]. 151 o A PCE initiates the forward and/ or reverse LSP of a single-sided 152 or double-sided bidirectional LSP on a PCC and retains the control 153 of the LSP. The PCE is responsible for computing the path of the 154 LSP and updating the PCC with the information about the path as 155 well as the association group identifying the bidirectional LSP. 156 This is the PCE-Initiated mode defined in [RFC8281]. 158 o A PCC requests co-routed or non co-routed paths for forward and 159 reverse LSPs of a bidirectional LSP from a Stateless PCE 160 [RFC5440]. 162 2. Conventions Used in This Document 164 2.1. Key Word Definitions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 2.2. Terminology 174 The reader is assumed to be familiar with the terminology defined in 175 [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association]. 177 The term forward and reverse direction of an LSP is from the view 178 point of a PCE. 180 3. Overview 182 As shown in Figure 1, two reverse unidirectional LSPs can be grouped 183 to form an associated bidirectional LSP. There are two methods of 184 initiating the bidirectional LSP association, single-sided and 185 double-sided, as defined in [RFC7551] and described in the following 186 sections. 188 LSP1 --> LSP1 --> LSP1 --> 189 +-----+ +-----+ +-----+ +-----+ 190 | A +-----------+ B +-----------+ C +-----------+ D | 191 +-----+ +--+--+ +--+--+ +-----+ 192 <-- LSP2 | | <-- LSP2 193 | | 194 | | 195 +--+--+ +--+--+ 196 | E +-----------+ F | 197 +-----+ +-----+ 198 <-- LSP2 200 Figure 1: Example of Associated Bidirectional LSP 202 3.1. Single-sided Initiation 204 As specified in [RFC7551], in the single-sided case, the 205 bidirectional tunnel is provisioned only on one endpoint node (PCC) 206 of the tunnel. Both forward and reverse LSPs of this tunnel are 207 initiated with the Association Type set to "Single-sided 208 Bidirectional LSP Association" on the originating endpoint node. The 209 forward and reverse LSPs are identified in the Bidirectional LSP 210 Association Group TLV of their PCEP Association Objects. 212 The originating endpoint node signals the properties for the revere 213 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 214 message. The remote endpoint then creates the corresponding reverse 215 tunnel and signals the reverse LSP in response to the received RSVP 216 Path message. Similarly, the remote endpoint node deletes the 217 reverse LSP when it receives the RSVP Path delete message [RFC3209] 218 for the forward LSP. 220 The originating endpoint (PCC) node may report/ delegate the forward 221 and reverse LSPs to a PCE. The remote endpoint (PCC) node may report 222 the reverse LSP to a PCE. 224 +-----+ 225 | PCE | 226 +-----+ 227 Initiates: | ^ Reports: 228 Tunnel 1 (F) | \ Tunnel 2 (R) 229 (LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) 230 v \ 231 +-----+ +-----+ 232 | A | | D | 233 +-----+ +-----+ 235 Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP 236 +-----+ 237 | PCE | 238 +-----+ 239 Reports/Delegates: ^ ^ Reports: 240 Tunnel 1 (F) | \ Tunnel 2 (R) 241 (LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) 242 | \ 243 +-----+ +-----+ 244 | A | | D | 245 +-----+ +-----+ 247 Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP 249 As shown in Figures 2A and 2B, the forward tunnel and both forward 250 LSP1 and reverse LSP2 are initiated on the originating endpoint node 251 A, either by the PCE or the originating PCC. The originating 252 endpoint node A signals the properties of reverse LSP2 in the RSVP 253 REVERSE_LSP Object in the Path message of the forward LSP1. The 254 creation of reverse tunnel and reverse LSP2 on the remote endpoint 255 node D is triggered by the RSVP signaled forward LSP1. 257 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast 258 reroute bypass tunnel assignment, the LSP starting from the 259 originating node is identified as the forward LSP of the single-sided 260 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 LSPs to a PCE. 275 +-----+ 276 | PCE | 277 +-----+ 278 Initiates: | \ Initiates: 279 Tunnel 1 (F) | \ Tunnel 2 (R) 280 (LSP1 (F)) | \ (LSP2 (R)) 281 v v 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 (R) 293 (LSP1 (F)) | \ (LSP2 (R)) 294 | \ 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. 306 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast 307 reroute bypass tunnel assignment, the LSP with the higher Source 308 Address [RFC3209] is identified as the forward LSP of the 309 double-sided initiated bidirectional LSP. 311 3.3. Co-routed Associated Bidirectional LSP 313 In both single-sided and double-sided initiation cases, forward and 314 reverse LSPs may be co-routed as shown in Figure 4, where both 315 forward and reverse LSPs of a bidirectional LSP follow the same 316 congruent path in the forward and reverse directions, respectively. 318 LSP3 --> LSP3 --> LSP3 --> 319 +-----+ +-----+ +-----+ +-----+ 320 | A +-----------+ B +-----------+ C +-----------+ D | 321 +-----+ +-----+ +-----+ +-----+ 322 <-- LSP4 <-- LSP4 <-- LSP4 324 Figure 4: Example of Co-routed Associated Bidirectional LSP 326 4. Protocol Extensions 328 4.1. Association Object 330 As per [I-D.ietf-pce-association], LSPs are associated by adding them 331 to a common association group. This document defines two new 332 Bidirectional LSP Association Groups to be used by the associated 333 bidirectional LSPs. A member of the Bidirectional LSP Association 334 Group can take the role of a forward or reverse LSP and follows the 335 following rules: 337 o An LSP (forward or reverse) can not be part of more than one 338 Bidirectional LSP Association Group. More than one forward LSP 339 and/ or reverse LSP can be part of a Bidirectional LSP Association 340 Group. 342 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 343 of the single-sided bidirectional LSP association on the 344 originating node MUST be the same. 346 This document defines two new Association Types for the Association 347 Object as follows: 349 o Association Type (TBD1) = Single-sided Bidirectional LSP 350 Association Group 352 o Association Type (TBD2) = Double-sided Bidirectional LSP 353 Association Group 355 These Association Types are operator-configured associations in 356 nature and statically created by the operator on the PCEP peers. The 357 LSP belonging to these associations is conveyed via PCEP messages to 358 the PCEP peer. Operator-configured Association Range TLV 359 [I-D.ietf-pce-association] MUST NOT be sent for these Association 360 Types, and MUST be ignored, so that the entire range of association 361 ID can be used for them. 363 The Association ID, Association Source, optional Global Association 364 Source and optional Extended Association ID in the Bidirectional LSP 365 Association Group Object are initialized using the procedures defined 366 in [I-D.ietf-pce-association] and [RFC7551]. 368 4.2. Bidirectional LSP Association Group TLV 370 The Bidirectional LSP Association Group TLV is defined for use with 371 the Single-sided and Double-sided Bidirectional LSP Association Group 372 Object Types. 374 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 375 format from [RFC5440]. 377 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 379 o The Length is 4 Bytes. 381 o The value comprises of a single field, the Bidirectional LSP 382 Association Flags (32 bits), where each bit represents a flag 383 option. 385 o If the Bidirectional LSP Association Group TLV is missing, it 386 means the LSP is the forward LSP and it is not co-routed LSP. 388 o For co-routed LSPs, this TLV MUST be present. 390 o For reverse LSPs, this TLV MUST be present. 392 o The Bidirectional LSP Association Group TLV MUST NOT be present 393 more than once. If it appears more than once, only the first 394 occurrence is processed and any others MUST be ignored. 396 The format of the Bidirectional LSP Association Group TLV is shown in 397 Figure 5: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type = TBD3 | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Reserved |C|R|F| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 5: Bidirectional LSP Association Group TLV format 409 Bidirectional LSP Association Flags are defined as following. 411 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 412 forward LSP of the bidirectional LSP. If this flag is set, the LSP 413 is a forward LSP. 415 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 416 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 417 is a reverse LSP. 419 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 420 co-routed. This flag MUST be set for both the forward and reverse 421 LSPs of a co-routed bidirectional LSP. 423 The C flag is used by the PCE (for both Stateful and Stateless) to 424 compute bidirectional paths of the forward and reverse LSPs of a 425 co-routed bidirectional LSP. 427 The Reserved flags MUST be set to 0 when sent and MUST be ignored 428 when received. 430 5. PCEP Procedure 432 5.1. PCE Initiated LSPs 434 As specified in [I-D.ietf-pce-association], the Bidirectional LSP 435 Association Groups can be created by a Stateful PCE. 437 o Stateful PCE can create and update the forward and reverse LSPs 438 independently for both single-sided and double-sided bidirectional 439 LSP association groups. 441 o Stateful PCE can establish and remove the association relationship 442 on a per LSP basis. 444 o Stateful PCE can create and update the LSP and the association on 445 a PCC via PCInitiate and PCUpd messages, respectively, using the 446 procedures described in [I-D.ietf-pce-association]. 448 5.2. PCC Initiated LSPs 450 As specified in [I-D.ietf-pce-association], Bidirectional LSP 451 Association Groups can also be created by a PCC. 453 o PCC can create and update the forward and reverse LSPs 454 independently for both single-sided and double-sided bidirectional 455 LSP association groups. 457 o PCC can establish and remove the association relationship on a per 458 LSP basis. 460 o PCC MUST report the change in the association group of an LSP to 461 PCE(s) via PCRpt message. 463 o PCC can report the forward and reverse LSPs independently to 464 PCE(s) via PCRpt message. 466 o PCC can delegate the forward and reverse LSPs independently to a 467 Stateful PCE, where PCE would control the LSPs. For single-sided 468 case, originating (PCC) node can delegate both forward and reverse 469 LSPs of a tunnel together to a Stateful PCE in order to avoid any 470 race condition. 472 o Stateful PCE can update the LSPs in the bidirectional LSP 473 association group via PCUpd message, using the procedures 474 described in [I-D.ietf-pce-association]. 476 5.3. Stateless PCE 478 For a stateless PCE, it might be useful to associate a path 479 computation request to an association group, thus enabling it to 480 associate a common set of configuration parameters or behaviors with 481 the request. A PCC can request co-routed or non co-routed forward 482 and reverse direction paths from a stateless PCE for a bidirectional 483 LSP association group. 485 5.4. Bidirectional (B) Flag 487 As defined in [RFC5440], the Bidirectional (B) flag in the Request 488 Parameters (RP) object is set when the PCC specifies that the path 489 computation request is for a bidirectional TE LSP with the same TE 490 requirements (e.g. latency) in each direction. For an associated 491 bidirectional LSP, the B-flag MAY be set when the PCC makes the path 492 computation request for the same TE requirements in the forward and 493 reverse directions. When a stateful PCE initiates or updates the 494 bidirectional LSPs, the B-flag in Stateful PCE Request Parameters 495 (SRP) object [RFC8231] MAY also be set. 497 5.5. State Synchronization 499 During state synchronization, a PCC MUST report all the existing 500 bidirectional LSP association groups to the Stateful PCE as per 501 [I-D.ietf-pce-association]. After the state synchronization, the PCE 502 MUST remove all stale bidirectional LSP associations. 504 5.6. Error Handling 505 An LSP (forward or reverse) can not be part of more than one 506 Bidirectional LSP Association Group. If a PCE attempts to add an LSP 507 not complying to this rule, the PCC MUST send PCErr with Error-Type = 508 29 (Early allocation by IANA) (Association Error) and Error-Value = 509 TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if 510 a PCC attempts to add an LSP at PCE not complying to this rule, the 511 PCE MUST send this PCErr. 513 The LSPs (forward or reverse) in a single-sided bidirectional LSP 514 association group MUST belong to the same TE Tunnel (as defined in 515 [RFC3209]). If a PCE attempts to add an LSP in a single-sided 516 bidirectional LSP association group for a different Tunnel, the PCC 517 MUST send PCErr with Error-Type = 29 (Early allocation by IANA) 518 (Association Error) and Error-Value = TBD5 (Bidirectional LSP 519 Association - Tunnel Mismatch). Similarly, if a PCC attempts to add 520 an LSP to a single-sided bidirectional LSP association group at PCE 521 not complying to this rule, the PCE MUST send this PCErr. 523 6. Security Considerations 525 The security considerations described in [RFC5440], [RFC8231], and 526 [RFC8281] apply to the extensions defined in this document as well. 528 Two new Association Types for the Association Object, Single-sided 529 Bidirectional LSP Association Group and Double-sided Associated 530 Bidirectional LSP Group are introduced in this document. Additional 531 security considerations related to LSP associations due to a 532 malicious PCEP speaker is described in [I-D.ietf-pce-association] and 533 apply to these Association Types. Hence, securing the PCEP session 534 using Transport Layer Security (TLS) [RFC8253] is recommended. 536 7. Manageability Considerations 538 7.1. Control of Function and Policy 540 The mechanisms defined in this document do not imply any control or 541 policy requirements in addition to those already listed in [RFC5440], 542 [RFC8231], and [RFC8281]. 544 7.2. Information and Data Models 546 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 547 defined for LSP associations. 549 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 550 LSP associations. 552 7.3. Liveness Detection and Monitoring 554 The mechanisms defined in this document do not imply any new liveness 555 detection and monitoring requirements in addition to those already 556 listed in [RFC5440], [RFC8231], and [RFC8281]. 558 7.4. Verify Correct Operations 560 The mechanisms defined in this document do not imply any new 561 operation verification requirements in addition to those already 562 listed in [RFC5440], [RFC8231], and [RFC8281]. 564 7.5. Requirements On Other Protocols 566 The mechanisms defined in this document do not add any new 567 requirements on other protocols. 569 7.6. Impact On Network Operations 571 The mechanisms defined in this document do not have any impact on 572 network operations in addition to those already listed in [RFC5440], 573 [RFC8231], and [RFC8281]. 575 8. IANA Considerations 577 8.1. Association Types 579 This document adds new Association Types for the Association Object 580 defined [I-D.ietf-pce-association]. IANA is requested to make the 581 assignment of values for the sub-registry "ASSOCIATION Type Field" 582 (to be created in [I-D.ietf-pce-association]), as follows: 584 Value Name Reference 585 --------------------------------------------------------------------- 586 TBD1 Single-sided Bidirectional LSP Association Group [This document] 587 TBD2 Double-sided Bidirectional LSP Association Group [This document] 589 8.2. Bidirectional LSP Association Group TLV 591 This document defines a new TLV for carrying additional information 592 of LSPs within a Bidirectional LSP Association Group. IANA is 593 requested to add the assignment of a new value in the existing "PCEP 594 TLV Type Indicators" registry as follows: 596 TLV-Type Name Reference 597 ------------------------------------------------------------------- 598 TBD3 Bidirectional LSP Association Group TLV [This document] 600 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 602 This document requests that a new sub-registry, named "Bidirectional 603 LSP Association Group TLV Flag Field", is created within the "Path 604 Computation Element Protocol (PCEP) Numbers" registry to manage the 605 Flag field in the Bidirectional LSP Association Group TLV. New 606 values are to be assigned by Standards Action [RFC8126]. Each bit 607 should be tracked with the following qualities: 609 o Bit number (count from 0 as the most significant bit) 611 o Description 613 o Reference 615 The following values are defined in this document for the Flag field. 617 Bit No. Description Reference 618 --------------------------------------------------------- 619 31 F - Forward LSP [This document] 620 30 R - Reverse LSP [This document] 621 29 C - Co-routed LSP [This document] 623 8.3. PCEP Errors 625 This document defines new Error value for Error Type 29 (Association 626 Error). IANA is requested to allocate new Error value within the 627 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 628 Numbers registry, as follows: 630 Error Type Description Reference 631 --------------------------------------------------------------------- 632 29 Association Error 634 Error value: TBD4 [This document] 635 Bidirectional LSP Association - Group Mismatch 637 Error value: TBD5 [This document] 638 Bidirectional LSP Association - Tunnel Mismatch 640 9. References 642 9.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, DOI 646 10.17487/RFC2119, March 1997. 648 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 649 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 650 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001. 652 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 653 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 654 March 2009. 656 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 657 Extensions for Associated Bidirectional LSPs", RFC 7551, 658 May 2015. 660 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 661 Writing an IANA Considerations Section in RFCs", BCP 26, 662 RFC 8126, DOI 10.17487/RFC8126, June 2017. 664 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 665 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 666 May 2017, . 668 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 669 Computation Element Communication Protocol (PCEP) 670 Extensions for Stateful PCE", RFC 8231, DOI 671 10.17487/RFC8231, September 2017. 673 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 674 Extensions for PCE-initiated LSP Setup in a Stateful PCE 675 Model", RFC 8281, December 2017. 677 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 678 Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP 679 Extensions for Establishing Relationships Between Sets of 680 LSPs", draft-ietf-pce-association-group (work in 681 progress). 683 [I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H., 684 and J. Whittaker, "Fast Reroute Procedures for Co-routed 685 Associated Bidirectional Label Switched Paths (LSPs)", 686 draft-ietf-teas-assoc-corouted-bidir-frr (work in 687 progress). 689 9.2. Informative References 691 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 692 Sprecher, N., and S. Ueno, "Requirements of an MPLS 693 Transport Profile", RFC 5654, September 2009. 695 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 696 Hardwick, "Path Computation Element Communication Protocol 697 (PCEP) Management Information Base (MIB) Module", RFC 698 7420, December 2014. 700 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 701 Stateful Path Computation Element (PCE)", RFC 8051, 702 January 2017. 704 [RFC8253] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage 705 of TLS to Provide a Secure Transport for the Path 706 Computation Element Communication Protocol (PCEP)", RFC 707 8253, October 2017. 709 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 710 Tantsura, "A YANG Data Model for Path Computation Element 711 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 712 (work in progress). 714 Acknowledgments 716 The authors would like to thank Dhruv Dhody for various discussions 717 on association groups and inputs to this document. The authors would 718 also like to thank Dhruv Dhody and Mike Taillon for reviewing this 719 document and providing valuable comments. 721 Authors' Addresses 723 Colby Barth 724 Juniper Networks 726 Email: cbarth@juniper.net 728 Rakesh Gandhi (editor) 729 Cisco Systems, Inc. 730 Canada 732 Email: rgandhi@cisco.com 734 Bin Wen 735 Comcast 737 Email: Bin_Wen@cable.comcast.com