idnits 2.17.1 draft-barth-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 (May 21, 2017) is 2531 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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: November 22, 2017 Cisco Systems, Inc. 6 B. Wen 7 Comcast 8 May 21, 2017 10 PCEP Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-barth-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 binding two reverse 24 unidirectional MPLS TE LSPs into an Associated Bidirectional Label 25 Switched Path (LSP) when using a Stateful PCE for both PCE-Initiated 26 and PCC-Initiated LSPs as 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 . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 8 76 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 9 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 82 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 83 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 106 stateful control of MPLS TE LSPs. It describes two modes of 107 operation - Passive Stateful PCE and Active Stateful PCE. In [I- 108 D.ietf-pce-stateful-pce], the focus is on Active Stateful PCE where 109 LSPs are provisioned on the PCC and control over them is delegated to 110 a PCE. Further, [I-D.ietf-pce-pce-initiated-lsp] describes the 111 setup, maintenance and teardown of PCE-Initiated LSPs for the 112 Stateful PCE 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 [I-D.ietf-pce-stateful- 119 pce] or a stateless PCE [RFC5440]. 121 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 122 specifies that MPLS-TP MUST support associated bidirectional point- 123 to-point LSPs. [RFC7551] specifies RSVP signaling extensions for 124 binding two reverse unidirectional LSPs into an associated 125 bidirectional LSP. The fast reroute (FRR) procedures for associated 126 bidirectional LSPs are described in [I-D.ietf-teas-assoc-corouted- 127 bidir-frr]. 129 This document specifies PCEP extensions for binding 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 or Stateless PCE. The PCEP extensions cover the following 133 cases: 135 o A PCE initiates the forward and/ or reverse LSP of a single-sided 136 or double-sided bidirectional LSP on a PCC and retains the control 137 of the LSP. The PCE computes the path of the LSP and updates the 138 PCC with the information about the path. 140 o A PCC initiates the forward and/ or reverse LSP of a single-sided 141 bidirectional LSP and retains the control of the LSP. The PCC 142 computes the path of the LSP and updates the PCE with the 143 information about the path (as long as it controls the LSP). 145 o A PCC initiates the forward and/ or reverse LSP of a single-sided 146 bidirectional LSP and delegates the control of the LSP to a 147 Stateful PCE. The PCE may compute the path of the LSP and update 148 the PCC with the information about the path (as long as it 149 controls the LSP). 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] and [RFC7551]. 167 3. Overview 169 As shown in Figure 1, two reverse unidirectional LSPs can be 170 associated to form an associated bidirectional LSP. There are two 171 methods of initiating the bidirectional LSP association, single-sided 172 and 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 initiation case, the 191 bidirectional tunnel is signaled only by one endpoint node (PCC) of 192 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 bound 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, both the forward LSP LSP1 and the reverse LSP 209 LSP2 are initiated on the originating endpoint node A, either by the 210 PCE or the PCC. The creation of reverse LSP2 on the remote endpoint 211 node D is triggered by the RSVP signaled LSP1. 213 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- 214 reroute bypass tunnel assignment, the LSP starting from the 215 originating node is identified as the forward LSP of the single-sided 216 initiated bidirectional LSP. 218 3.2. Double-sided Initiation 220 As specified in [RFC7551], in the double-sided initiation case, the 221 bidirectional LSP is signaled by the both endpoint nodes (PCCs) of 222 the tunnel. The forward and reverse LSPs of this tunnel are 223 initiated with the Association Type set to "Double-sided 224 Bidirectional LSP Association" on both endpoint nodes. The forward 225 and reverse LSPs are identified in the Bidirectional LSP Association 226 Group TLV of their Association Objects. 228 The two reverse unidirectional LSPs on both the endpoint nodes are 229 bound together by using the PCEP Association Object. 231 As shown in Figure 1, LSP1 is initiated on the endpoint node A and 232 LSP2 is initiated on the endpoint node D, both by the PCE. 234 As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- 235 reroute bypass tunnel assignment, the LSP with the higher source 236 address is identified as the forward LSP of the double-sided 237 initiated bidirectional LSP. 239 3.3. Co-routed Associated Bidirectional LSP 241 In both single-sided and double-sided initiation cases, forward and 242 reverse LSPs may be co-routed as shown in Figure 2, where both 243 forward and reverse LSPs follow the same congruent path. 245 LSP3 --> LSP3 --> LSP3 --> 246 +-----+ +-----+ +-----+ +-----+ 247 | A +-----------+ B +-----------+ C +-----------+ D | 248 +-----+ +-----+ +-----+ +-----+ 249 <-- LSP4 <-- LSP4 <-- LSP4 251 Figure 2: Example of Co-routed Associated Bidirectional LSP 253 4. Protocol Extensions 255 4.1. Association Object 257 As per [I-D.ietf-pce-association], LSPs are associated by adding them 258 to a common association group. This document defines two new 259 Bidirectional LSP Association Groups to be used by the associated 260 bidirectional LSPs. A member of the Bidirectional LSP Association 261 Group can take the role of a forward or reverse LSP. The reverse LSP 262 source address MUST be the destination address of the forward LSP and 263 the reverse LSP destination address MUST be the source address of the 264 forward LSP within a bidirectional LSP association group. An LSP can 265 not be part of more than one Bidirectional LSP Association Group. 267 This document defines two new Association Types for the Association 268 Object as follows: 270 o Association Type (TBD1) = Single-sided Bidirectional LSP 271 Association Group 273 o Association Type (TBD2) = Double-sided Bidirectional LSP 274 Association Group 276 The Association ID, Association Source, optional Global Association 277 Source and optional Extended Association ID in the Bidirectional LSP 278 Association Group Object are populated using the procedures defined 279 in [RFC7551]. 281 4.2. Bidirectional LSP Association Group TLV 282 The Bidirectional LSP Association Group TLV is an optional TLV for 283 use with the Single-sided and Double-sided Bidirectional LSP 284 Association Group Object Types. 286 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 287 format from [RFC5440]. 289 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 291 o The Length is 4 Bytes. 293 o The value comprises of a single field, the Bidirectional LSP 294 Association Flags (32 bits), where each bit represents a flag 295 option. 297 o If the Bidirectional LSP Association Group TLV is missing, it 298 means the LSP is the forward LSP. 300 o The Bidirectional LSP Association Group TLV MUST NOT be present 301 more than once. If it appears more than once, only the first 302 occurrence is processed and any others MUST be ignored. 304 The format of the Bidirectional LSP Association Group TLV is shown in 305 Figure 3: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type = TBD3 | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Reserved |C|R|F| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 3: Bidirectional LSP Association Group TLV format 317 Bidirectional LSP Association Flags are defined as following. 319 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 320 forward LSP of the bidirectional LSP. If this flag is set, the LSP 321 is a forward LSP. 323 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 324 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 325 is a reverse LSP. 327 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 328 co-routed. If this flag is set, the associated bidirectional LSP 329 is co-routed. This flag MUST be set for both the forward and 330 reverse LSPs of a co-routed bidirectional LSP. 332 The Reserved flags MUST be set to 0 when sent and MUST be ignore when 333 received. 335 When an associated bidirectional LSP is delegated to a Stateful PCE, 336 the C flag is used by the PCE to compute paths of the forward and 337 reverse LSPs. 339 5. PCEP Procedure 341 5.1. PCE Initiated LSPs 343 As specified in [I-D.ietf-pce-association], Association Groups can be 344 created by both Stateful PCE and PCC. 346 A Stateful PCE can create and update the forward and reverse LSPs 347 independently for both Single-sided and Double-sided bidirectional 348 LSP association groups. 350 5.2. PCC Initiated LSPs 352 A PCC can associate or remove an LSP under its control from the 353 bidirectional LSP association group. The PCC must report the change 354 in association to Stateful PCE via PCRpt message. 356 5.3. Stateless PCE 358 A PCC can request co-routed or non co-routed forward and reverse 359 direction paths from a stateless PCE for the bidirectional LSP 360 association group. 362 5.4. State Synchronization 364 During state synchronization, a PCC MUST report all the existing 365 bidirectional LSP association groups to the Stateful PCE. After the 366 state synchronization, the PCE MUST remove all stale associations. 368 5.5. Error Handling 370 The reverse LSP in the bidirectional LSP association group MUST have 371 the source address matching the destination address of the forward 372 LSP and destination address matching the source address of the 373 forward LSP. If a PCE attempts to add an LSP to a bidirectional LSP 374 association group not complying to this rule, the PCC for the single- 375 sided initiation case MUST send PCErr with Error-Type= TBD4 376 (Bidirectional LSP Association Error) and Error-Value = 1 (Endpoints 377 mismatch). Similarly, if a PCC attempts to add an LSP to a 378 bidirectional LSP association group at PCE not complying to this 379 rule, the PCE for both single-sided and double-sided initiated 380 bidirectional LSPs MUST send this PCErr. 382 6. Security Considerations 384 This document introduces two new Association Types for the 385 Association Object, Double-sided Bidirectional LSP Association Group 386 and Single-sided Associated Bidirectional LSP Group. These types, by 387 themselves, introduce no additional security concerns beyond those 388 discussed in [RFC5440], [I-D.ietf-pce-stateful-pce], and [I-D.ietf- 389 pce-association]. 391 7. Manageability Considerations 393 7.1. Control of Function and Policy 395 An operator MUST be allowed to provision the bidirectional LSP 396 association parameters at PCEP peers. 398 7.2. Information and Data Models 400 A Management Information Base (MIB) module for modeling PCEP is 401 described in [RFC7420]. However, one may prefer the mechanism for 402 configuration using YANG data model [I-D.ietf-pce-pcep-yang]. These 403 SHOULD be enhanced to provide controls and indicators for support of 404 the associated bidirectional LSP feature. Support for various 405 configuration parameters as well as counters of messages 406 sent/received containing the TLVs defined in this document SHOULD be 407 added. 409 7.3. Liveness Detection and Monitoring 411 The mechanisms defined in this document do not imply any new liveness 412 detection and monitoring requirements in addition to those already 413 listed in [RFC5440]. 415 7.4. Verify Correct Operations 417 The mechanisms defined in this document do not imply any new 418 operation verification requirements in addition to those already 419 listed in [RFC5440]. 421 7.5. Requirements On Other Protocols 422 The mechanisms defined in this document do not add any new 423 requirements on other protocols. 425 7.6. Impact On Network Operations 427 The mechanisms defined in this document do not have any new impact on 428 network operations. 430 8. IANA Considerations 432 8.1. Association Types 434 This document defines the following Association Types for the 435 Association Object defined [I-D.ietf-pce-association]. 437 Value Name Reference 438 --------------------------------------------------------------------- 439 TBD1 Single-sided Bidirectional LSP Association Group [This document] 440 TBD2 Double-sided Bidirectional LSP Association Group [This document] 442 8.2. Bidirectional LSP Association Group TLV 444 This document defines a new TLV for carrying additional LSP 445 information for the Bidirectional LSP Association Group TLV as 446 following: 448 TLV-Type Name Reference 449 ------------------------------------------------------------------- 450 TBD3 Bidirectional LSP Association Group TLV [This document] 452 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 454 This document requests that a new sub-registry, named "Bidirectional 455 LSP Association Group TLV Flag Field", is created within the "Path 456 Computation Element Protocol (PCEP) Numbers" registry to manage the 457 Flag field in the Bidirectional LSP Association Group TLV. 459 New values are to be assigned by Standards Action [RFC5226]. Each 460 bit should be tracked with the following qualities: 462 o Bit number (counting from bit 0 as the most significant bit) 464 o Capability description 466 o Defining RFC 468 The following values are defined in this document for the Flag field. 470 Bit No. Description Reference 471 --------------------------------------------------------- 472 31 F - Forward LSP [This document] 473 30 R - Reverse LSP [This document] 474 29 C - Co-routed LSP [This document] 476 8.3. PCEP Errors 478 IANA is requested to allocate new Error-Type and Error-Value within 479 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 480 PCEP Numbers registry, as follows: 482 Error-Type Description Reference 483 ----------------------------------------------------------------- 484 TBD4 Bidirectional LSP Association Error [This document] 486 Error-value=1: Endpoints mismatch [This document] 488 9. References 490 9.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 496 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 497 May 2008. 499 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 500 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 501 March 2009. 503 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 504 Extensions for Associated Bidirectional LSPs", RFC 7551, 505 May 2015. 507 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 508 Ananthakrishnan, H., Zhang, X., and Y. Tanaka, "PCEP 509 Extensions for Establishing Relationships Between Sets of 510 LSPs", draft-ietf-pce-association-group (work in 511 progress). 513 [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and 514 R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf- 515 pce-stateful-pce (work in progress). 517 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 518 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 519 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 520 initiated-lsp (work in progress). 522 [I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H., 523 and J. Whittaker, "Fast Reroute Procedures for Associated 524 Bidirectional Label Switched Paths", draft-ietf-teas- 525 assoc-corouted-bidir-frr (work-in-progress). 527 9.2. Informative References 529 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 530 Sprecher, N., and S. Ueno, "Requirements of an MPLS 531 Transport Profile", RFC 5654, September 2009. 533 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 534 Hardwick, "Path Computation Element Communication Protocol 535 (PCEP) Management Information Base (MIB) Module", RFC 536 7420, December 2014. 538 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 539 Tantsura, "A YANG Data Model for Path Computation Element 540 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 541 (work in progress). 543 Acknowledgments 545 TBA. 547 Authors' Addresses 549 Colby Barth 550 Juniper Networks 552 Email: cbarth@juniper.net 554 Rakesh Gandhi 555 Cisco Systems, Inc. 557 Email: rgandhi@cisco.com 559 Bin Wen 560 Comcast 562 Email: Bin_Wen@cable.comcast.com