idnits 2.17.1 draft-barth-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 (October 3, 2017) is 2389 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 5 Expires: April 6, 2018 Cisco Systems, Inc. 6 B. Wen 7 Comcast 8 October 3, 2017 10 PCEP Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-barth-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. 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) 2017 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 . . . . . . . . . . . . . . . . . 5 67 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 6 68 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 7 71 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 73 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 74 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 8 75 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 9 76 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. Manageability Considerations . . . . . . . . . . . . . . . . . 9 79 7.1. Control of Function and Policy . . . . . . . . . . . . . . 9 80 7.2. Information and Data Models . . . . . . . . . . . . . . . 10 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 82 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 83 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 84 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 10 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 10 87 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 10 88 8.2.1. Flag Fields in Bidirectional LSP Association Group 89 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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, [I-D.ietf-pce-pce-initiated- 110 lsp] describes the setup, maintenance and teardown of PCE-Initiated 111 LSPs for the Stateful PCE 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 point- 122 to-point LSPs. [RFC7551] specifies 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 [I-D.ietf-teas-assoc-corouted- 126 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 PCE initiates the forward and/ or reverse LSP of a single-sided 135 or double-sided bidirectional LSP on a PCC and retains the control 136 of the LSP. The PCE computes the path of the LSP and updates the 137 PCC with the information about the path. 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 of the LSP and reports the PCE 142 with the information about the path (as long as it controls the 143 LSP, as in passive Stateful PCE mode). 145 o A PCC initiates the forward and/ or reverse LSP of a single-sided 146 or double-sided bidirectional LSP and delegates the control of the 147 LSP to a Stateful PCE. The PCE may compute the path of the LSP 148 and update the PCC with the information about the path (as long as 149 it controls the LSP, as in active Stateful PCE mode). 151 o A PCC requests co-routed or non co-routed paths for forward and 152 reverse LSPs of a bidirectional LSP from a Stateless PCE. 154 2. Conventions Used in This Document 156 2.1. Key Word Definitions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2.2. Terminology 164 The reader is assumed to be familiar with the terminology defined in 165 [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association]. 167 3. Overview 169 As shown in Figure 1, two reverse unidirectional LSPs can be grouped 170 to form an associated bidirectional LSP. There are two methods of 171 initiating the bidirectional LSP association, single-sided and 172 double-sided as described in the following sections. 174 LSP1 --> LSP1 --> LSP1 --> 175 +-----+ +-----+ +-----+ +-----+ 176 | A +-----------+ B +-----------+ C +-----------+ D | 177 +-----+ +--+--+ +--+--+ +-----+ 178 <-- LSP2 | | <-- LSP2 179 | | 180 | | 181 +--+--+ +--+--+ 182 | E +-----------+ F | 183 +-----+ +-----+ 184 <-- LSP2 186 Figure 1: Example of Associated Bidirectional LSP 188 3.1. Single-sided Initiation 190 As specified in [RFC7551], in the single-sided case, the 191 bidirectional tunnel is provisioned only on one endpoint node (PCC) 192 of the tunnel. Both forward and reverse LSPs of this tunnel are 193 initiated with the Association Type set to "Single-sided 194 Bidirectional LSP Association" on the originating endpoint node. The 195 forward and reverse LSPs are identified in the Bidirectional LSP 196 Association Group TLV of their PCEP Association Objects. 198 The originating endpoint node signals the properties for the revere 199 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 200 message. The remote endpoint then creates the corresponding reverse 201 tunnel and signals the reverse LSP in response to the received RSVP 202 Path message. 204 The two unidirectional reverse LSPs on the originating endpoint node 205 are grouped together using the PCEP Association Object and on the 206 remote endpoint node by the RSVP signaled Association Object. 208 As shown in Figure 1, the forward tunnel and both the forward LSP 209 LSP1 and the reverse LSP LSP2 are initiated on the originating 210 endpoint node A, either by the PCE or the PCC. The creation of 211 reverse tunnel and reverse LSP2 on the remote endpoint node D is 212 triggered by the RSVP signaled LSP1. 214 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- 215 reroute bypass tunnel assignment, the LSP starting from the 216 originating node is identified as the forward LSP of the single-sided 217 initiated bidirectional LSP. 219 3.2. Double-sided Initiation 221 As specified in [RFC7551], in the double-sided case, the 222 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 223 the tunnel. The forward and reverse LSPs of this tunnel are 224 initiated with the Association Type set to "Double-sided 225 Bidirectional LSP Association" on both endpoint nodes. The forward 226 and reverse LSPs are identified in the Bidirectional LSP Association 227 Group TLV of their Association Objects. 229 The two reverse unidirectional LSPs on both the endpoint nodes are 230 grouped together by using the PCEP Association Object. 232 As shown in Figure 1, the forward tunnel and LSP1 are initiated on 233 the endpoint node A and the reverse tunnel and LSP2 are initiated on 234 the endpoint node D, either by the PCE or the PCCs. 236 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- 237 reroute bypass tunnel assignment, the LSP with the higher Source 238 Address [RFC3209] is identified as the forward LSP of the double- 239 sided initiated bidirectional LSP. 241 3.3. Co-routed Associated Bidirectional LSP 243 In both single-sided and double-sided initiation cases, forward and 244 reverse LSPs may be co-routed as shown in Figure 2, where both 245 forward and reverse LSPs follow the same congruent path in the 246 forward and reverse directions, respectively. 248 LSP3 --> LSP3 --> LSP3 --> 249 +-----+ +-----+ +-----+ +-----+ 250 | A +-----------+ B +-----------+ C +-----------+ D | 251 +-----+ +-----+ +-----+ +-----+ 252 <-- LSP4 <-- LSP4 <-- LSP4 254 Figure 2: Example of Co-routed Associated Bidirectional LSP 256 4. Protocol Extensions 258 4.1. Association Object 260 As per [I-D.ietf-pce-association], LSPs are associated by adding them 261 to a common association group. This document defines two new 262 Bidirectional LSP Association Groups to be used by the associated 263 bidirectional LSPs. A member of the Bidirectional LSP Association 264 Group can take the role of a forward or reverse LSP and follows the 265 following rules: 267 o An LSP can not be part of more than one Bidirectional LSP 268 Association Group. 270 o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs 271 of the single-sided bidirectional association MUST be the same. 273 This document defines two new Association Types for the Association 274 Object as follows: 276 o Association Type (TBD1) = Single-sided Bidirectional LSP 277 Association Group 279 o Association Type (TBD2) = Double-sided Bidirectional LSP 280 Association Group 282 These Association Types are operator-configured associations in 283 nature and statically created by the operator on the PCEP peers. The 284 LSP belonging to these associations is conveyed via PCEP messages to 285 the PCEP peer. Operator-configured Association Range TLV [I-D.ietf- 286 pce-association] SHOULD NOT be sent for these Association Types, and 287 MUST be ignored, so that the entire range of association ID can be 288 used for them. 290 The Association ID, Association Source, optional Global Association 291 Source and optional Extended Association ID in the Bidirectional LSP 292 Association Group Object are also operator-configured and populated 293 using the procedures defined in [RFC7551]. 295 4.2. Bidirectional LSP Association Group TLV 297 The Bidirectional LSP Association Group TLV is an optional TLV for 298 use with the Single-sided and Double-sided Bidirectional LSP 299 Association Group Object Types. 301 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 302 format from [RFC5440]. 304 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 306 o The Length is 4 Bytes. 308 o The value comprises of a single field, the Bidirectional LSP 309 Association Flags (32 bits), where each bit represents a flag 310 option. 312 o If the Bidirectional LSP Association Group TLV is missing, it 313 means the LSP is the forward LSP. 315 o The Bidirectional LSP Association Group TLV MUST NOT be present 316 more than once. If it appears more than once, only the first 317 occurrence is processed and any others MUST be ignored. 319 The format of the Bidirectional LSP Association Group TLV is shown in 320 Figure 3: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type = TBD3 | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Reserved |C|R|F| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: Bidirectional LSP Association Group TLV format 331 Bidirectional LSP Association Flags are defined as following. 333 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 334 forward LSP of the bidirectional LSP. If this flag is set, the LSP 335 is a forward LSP. 337 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 338 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 339 is a reverse LSP. 341 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 342 co-routed. This flag MUST be set for both the forward and reverse 343 LSPs of a co-routed bidirectional LSP. 345 The C flag is used by the PCE (for both Stateful and Stateless) to 346 compute bidirectional paths of the forward and reverse LSPs. 348 The Reserved flags MUST be set to 0 when sent and MUST be ignored 349 when received. 351 5. PCEP Procedure 353 5.1. PCE Initiated LSPs 355 As specified in [I-D.ietf-pce-association], Association Groups can be 356 created by both Stateful PCE and PCC. 358 A Stateful PCE can create and update the forward and reverse LSPs 359 independently for both Single-sided and Double-sided bidirectional 360 LSP association groups. The establishment and removal of the 361 association relationship can be done on a per LSP basis. A PCE can 362 create and update the association of the LSP on a PCC via PCInitiate 363 and PCUpd messages, respectively, using the procedures described in 364 [I-D.ietf-pce-association]. 366 5.2. PCC Initiated LSPs 368 A PCC can associate or remove an LSP under its control from the 369 bidirectional LSP association group. The PCC MUST report the change 370 in LSP association to Stateful PCE via PCRpt message. 372 5.3. Stateless PCE 374 For a stateless PCE, it might be useful to associate a path 375 computation request to an association group, thus enabling it to 376 associate a common set of configuration parameters or behaviors with 377 the request. A PCC can request co-routed or non co-routed forward 378 and reverse direction paths from a stateless PCE for the 379 bidirectional LSP association group. 381 5.4. State Synchronization 383 During state synchronization, a PCC MUST report all the existing 384 bidirectional LSP association groups to the Stateful PCE. After the 385 state synchronization, the PCE MUST remove all stale bidirectional 386 associations. 388 5.5. Error Handling 390 The LSPs (forward or reverse) in a single-sided bidirectional LSP 391 association group MUST belong to the same TE Tunnel (as defined in 392 [RFC3209]). If a PCE attempts to add an LSP in a single-sided 393 bidirectional LSP association group for a different Tunnel, the PCC 394 MUST send PCErr with Error-Type = TBD4 (Bidirectional LSP Association 395 Error) and Error-Value = 1 (Tunnel mismatch). Similarly, if a PCC 396 attempts to add an LSP to a single-sided bidirectional LSP 397 association group at PCE not complying to this rule, the PCE MUST 398 send this PCErr. 400 6. Security Considerations 402 The security considerations described in [RFC5440], [RFC8231], and 403 [I-D.ietf-pce-pce-initiated-lsp] apply to the extensions defined in 404 this document as well. 406 Two new Association Types for the Association Object, Double-sided 407 Bidirectional LSP Association Group and Single-sided Associated 408 Bidirectional LSP Group are introduced in this document. Additional 409 security considerations related to LSP associations due to a 410 malicious PCEP speaker is described in [I-D.ietf-pce-association] and 411 apply to these Association Types. Thus, securing the PCEP session 412 using Transport Layer Security (TLS) [I-D.ietf-pce-pceps] is 413 recommended. 415 7. Manageability Considerations 417 7.1. Control of Function and Policy 419 The mechanisms defined in this document do not imply any control or 420 policy requirements in addition to those already listed in [RFC5440], 421 [RFC8231], and [I-D.ietf-pce-pce-initiated-lsp]. 423 7.2. Information and Data Models 425 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 426 defined for LSP associations. 428 The PCEP YANG module [I-D.ietf-pce-pcep-yang] supports LSP 429 associations. 431 7.3. Liveness Detection and Monitoring 433 The mechanisms defined in this document do not imply any new liveness 434 detection and monitoring requirements in addition to those already 435 listed in [RFC5440], [RFC8231], and [I-D.ietf-pce-pce-initiated-lsp]. 437 7.4. Verify Correct Operations 439 The mechanisms defined in this document do not imply any new 440 operation verification requirements in addition to those already 441 listed in [RFC5440], [RFC8231], and [I-D.ietf-pce-pce-initiated-lsp]. 443 7.5. Requirements On Other Protocols 445 The mechanisms defined in this document do not add any new 446 requirements on other protocols. 448 7.6. Impact On Network Operations 450 The mechanisms defined in this document do not have any impact on 451 network operations in addition to those already listed in [RFC5440], 452 [RFC8231], and [I-D.ietf-pce-pce-initiated-lsp]. 454 8. IANA Considerations 456 8.1. Association Types 458 This document adds new Association Types for the Association Object 459 defined [I-D.ietf-pce-association]. IANA is requested to make the 460 assignment of values for the sub-registry "ASSOCIATION Type Field" 461 (to be created in [I-D.ietf-pce-association]), as follows: 463 Value Name Reference 464 --------------------------------------------------------------------- 465 TBD1 Single-sided Bidirectional LSP Association Group [This document] 466 TBD2 Double-sided Bidirectional LSP Association Group [This document] 468 8.2. Bidirectional LSP Association Group TLV 469 This document defines a new TLV for carrying additional information 470 of LSPs within a Bidirectional LSP Association Group. IANA is 471 requested to add the assignment of a new value in the existing "PCEP 472 TLV Type Indicators" registry as follows: 474 TLV-Type Name Reference 475 ------------------------------------------------------------------- 476 TBD3 Bidirectional LSP Association Group TLV [This document] 478 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 480 This document requests that a new sub-registry, named "Bidirectional 481 LSP Association Group TLV Flag Field", is created within the "Path 482 Computation Element Protocol (PCEP) Numbers" registry to manage the 483 Flag field in the Bidirectional LSP Association Group TLV. New 484 values are to be assigned by Standards Action [RFC8126]. Each bit 485 should be tracked with the following qualities: 487 o Bit number (count from 0 as the most significant bit) 489 o Description 491 o Reference 493 The following values are defined in this document for the Flag field. 495 Bit No. Description Reference 496 --------------------------------------------------------- 497 31 F - Forward LSP [This document] 498 30 R - Reverse LSP [This document] 499 29 C - Co-routed LSP [This document] 501 8.3. PCEP Errors 503 IANA is requested to allocate new Error-Type and Error-Value related 504 to bidirectional LSP association within the " PCEP-ERROR Object Error 505 Types and Values" sub-registry of the PCEP Numbers registry, as 506 follows: 508 Error-Type Description Reference 509 ----------------------------------------------------------------- 510 TBD4 Bidirectional LSP Association Error [This document] 512 Error-value=1: Tunnel mismatch [This document] 514 9. References 516 9.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, DOI 520 10.17487/RFC2119, March 1997, . 523 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 524 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 525 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 526 . 528 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 529 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 530 March 2009. 532 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 533 Extensions for Associated Bidirectional LSPs", RFC 7551, 534 May 2015. 536 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 537 Writing an IANA Considerations Section in RFCs", BCP 26, 538 RFC 8126, DOI 10.17487/RFC8126, June 2017, 539 . 541 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 542 Computation Element Communication Protocol (PCEP) 543 Extensions for Stateful PCE", RFC 8231, DOI 544 10.17487/RFC8231, September 2017, . 547 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 548 Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP 549 Extensions for Establishing Relationships Between Sets of 550 LSPs", draft-ietf-pce-association-group (work in 551 progress). 553 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 554 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 555 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 556 initiated-lsp (work in progress). 558 [I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H., 559 and J. Whittaker, "Fast Reroute Procedures for Associated 560 Bidirectional Label Switched Paths", draft-ietf-teas- 561 assoc-corouted-bidir-frr (work-in-progress). 563 9.2. Informative References 565 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 566 Sprecher, N., and S. Ueno, "Requirements of an MPLS 567 Transport Profile", RFC 5654, September 2009. 569 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 570 Hardwick, "Path Computation Element Communication Protocol 571 (PCEP) Management Information Base (MIB) Module", RFC 572 7420, December 2014. 574 [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, Q., and D. Dhody, 575 "Secure Transport for PCEP", draft-ietf-pce-pceps (work in 576 progress). 578 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 579 Tantsura, "A YANG Data Model for Path Computation Element 580 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 581 (work in progress). 583 Acknowledgments 585 TBA. 587 Authors' Addresses 589 Colby Barth 590 Juniper Networks 592 Email: cbarth@juniper.net 594 Rakesh Gandhi 595 Cisco Systems, Inc. 597 Email: rgandhi@cisco.com 599 Bin Wen 600 Comcast 602 Email: Bin_Wen@cable.comcast.com