idnits 2.17.1 draft-ietf-pce-vn-association-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 (April 16, 2020) is 1464 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) == Missing Reference: 'I-D.ietf-pce-pcep-yang' is mentioned on line 447, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Lee 3 Internet-Draft Samsung 4 Intended status: Standards Track H. Zheng 5 Expires: October 18, 2020 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 April 16, 2020 10 Path Computation Element communication Protocol (PCEP) extensions for 11 Establishing Relationships between sets of LSPs and Virtual Networks 12 draft-ietf-pce-vn-association-02 14 Abstract 16 This document describes how to extend Path Computation Element (PCE) 17 Communication Protocol (PCEP) association mechanism introduced by the 18 PCEP Association Group specification, to further associate sets of 19 LSPs with a higher-level structure such as a virtual network (VN) 20 requested by clients or applications. This extended association 21 mechanism can be used to facilitate virtual network control using PCE 22 architecture. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 18, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 4 62 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6 63 5. Applicability to H-PCE architecture . . . . . . . . . . . . . 7 64 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Association Object Type Indicator . . . . . . . . . . . . 9 69 8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9 70 8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 72 9.1. Control of Function and Policy . . . . . . . . . . . . . 10 73 9.2. Information and Data Models . . . . . . . . . . . . . . . 10 74 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 75 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 76 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 77 9.6. Impact On Network Operations . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The Path Computation Element communication Protocol (PCEP) provides 87 mechanisms for Path Computation Elements (PCEs) to perform path 88 computations in response to Path Computation Clients' (PCCs) 89 requests. 91 [RFC8051] describes general considerations for a stateful PCE 92 deployment and examines its applicability and benefits, as well as 93 its challenges and limitations through a number of use cases. 94 [RFC8231] describes a set of extensions to PCEP to provide stateful 95 control. A stateful PCE has access to not only the information 96 carried by the network's Interior Gateway Protocol (IGP), but also 97 the set of active paths and their reserved resources for its 98 computations. The additional state allows the PCE to compute 99 constrained paths while considering individual LSPs and their 100 interactions. 102 [RFC8281] describes the setup, maintenance and teardown of PCE- 103 initiated LSPs under the stateful PCE model. 105 [RFC8697] introduces a generic mechanism to create a grouping of 106 LSPs. This grouping can then be used to define association between 107 sets of LSPs or between a set of LSPs and a set of attributes. 109 [RFC8453] describes various Virtual Network (VN) operations initiated 110 by a customer/application. In this context, there is a need for 111 associating a set of LSPs with a VN "construct" to facilitate VN 112 operations in PCE architecture. This association allows the PCEs to 113 identify which LSPs belong to a certain VN. The PCE could then use 114 this association to optimize all LSPs belonging to the VN together. 115 The PCE could further take VN specific actions on the LSPs such as 116 relaxation of constraints, policy actions, setting default behavior 117 etc. 119 [RFC8637] examines the PCE and ACTN architecture and describes how 120 the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] 121 describes a hierarchy of stateful PCEs with Parent PCE coordinating 122 multi-domain path computation function between Child PCE(s) and thus 123 making it the base for PCE applicability for ACTN. In this text 124 child PCE would be same as Provisioning Network Controller (PNC), and 125 the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453]. 127 This document specifies a PCEP extension to associate a set of LSPs 128 based on Virtual Network (VN) (or customer). A Virtual Network (VN) 129 is a customer view of the TE network. Depending on the agreement 130 between client and provider various VN operations and VN views are 131 possible as described in [RFC8453]. 133 1.1. Requirement Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. Terminology 143 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] 144 and [RFC8453]. 146 3. Operation Overview 148 As per [RFC8697], LSPs are associated with other LSPs with which they 149 interact by adding them to a common association group. 151 An association group based on VN is useful for various optimizations 152 that should be applied by considering all the LSPs in the 153 association. This includes, but not limited to - 155 o Path Computation: When computing path for a LSP, the impact of 156 this LSP, on the other LSPs belonging to the same VN is useful to 157 analyze. The aim would be optimize overall VN and all LSPs, 158 rather than a single LSP. Also, the optimization criteria such as 159 minimize the load of the most loaded link (MLL) [RFC5541] and 160 other could be applied for all the LSP belonging to the same VN, 161 identified by the VN association. 163 o Path Re-Optimization: The child PCE or the parent PCE would like 164 to use advanced path computation algorithm and optimization 165 technique that consider all the LSPs belonging to a VN/customer 166 and optimize them all together during the re-optimization. 168 This association is useful in PCEP session between parent PCE (MDSC) 169 and child PCE (PNC). When computing the path, the child PCE (PNC) 170 refer to the VN association in the request from the parent PCE (MDSC) 171 and maps the VN to the associated LSPs and the network resources. 172 Based on this information, operator policy and various constraints, 173 the path is computed and replied to the parent PCE (MDSC). The VN 174 association information could be included as a part of response as 175 well. The figure describes a typical VN operations using PCEP for 176 illustration purpose. It is worth noting that in a multi-domain 177 scenario, the different domain is controlled by different child PCEs. 178 In order to set up the end-to-end tunnel, multiple segments need to 179 be stitched, by the border nodes in each domain who receives the 180 instruction from their child PCE (PNC). 182 ****** 183 ..........*MDSC*.............................. 184 . ****** .. MPI . 185 . . . PCEP . 186 . . . PCInitiate LSPx . 187 . . . with VNAG = 10 . 188 . . . . 189 . . . . 190 . . . . 191 v v v . 192 ****** ****** ****** . 193 *PNC1* *PNC2* *PNC4* . 194 ****** ****** ****** . 195 +---------------+ +---------------+ +---------------+ . 196 |A |----| |----| C| . 197 | | | | | | . 198 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 199 +------------B13+ +---------------+ +B43------------+ . 200 / . 201 ****** / . 202 *PNC3*<............/..................... 203 ****** / 204 +---------------+/ 205 B31 B34 206 | | 207 |DOMAIN 3 B| 208 +---------------+ 210 MDSC -> Parent PCE 211 PNC -> Child PCE 212 MPI -> PCEP 214 In this draft, this grouping is used to define associations between a 215 set of LSPs and a virtual network, a new association group is defined 216 below - 218 o VN Association Group (VNAG) 220 One new Association type is defined as described in the Association 221 object - 223 o Association type = TBD1 ("VN Association") for VNAG 225 The scope and handling of VNAG identifier is similar to the generic 226 association identifier defined in [RFC8697] . 228 In this document VNAG object refers to an Association Object with the 229 Association type set to "VNAG". 231 Local polices on the PCE MAY define the computational and 232 optimization behavior for the LSPs in the VN. An LSP MUST NOT belong 233 to more than one VNAG. If an implementation encounters more than one 234 VNAG, it MUST consider the first occurrence and ignore the others. 236 [RFC8697] specify the mechanism for the capability advertisement of 237 the association types supported by a PCEP speaker by defining a 238 ASSOC-Type-List TLV to be carried within an OPEN object. This 239 capability exchange for the association type described in this 240 document (i.e. VN Association Type) MUST be done before using the 241 policy association. Thus the PCEP speaker MUST include the VN 242 Association Type (TBD1) in the ASSOC-Type-List TLV before using the 243 VNAG in the PCEP messages. 245 This Association-Type is dynamic in nature and created by the Parent 246 PCE (MDSC) for the LSPs belonging to the same VN or customer. These 247 associations are conveyed via PCEP messages to the PCEP peer. 248 Operator-configured Association Range MUST NOT be set for this 249 association-type and MUST be ignored. 251 4. Extensions to PCEP 253 The format of VNAG is as per the ASSOCIATION object [RFC8697]. 255 This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one 256 new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, 257 VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific 258 information. 260 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 262 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 263 specific behavioral information, described in [RFC7470]. 265 The format of VIRTUAL-NETWORK-TLV is as follows. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type=TBD2 | Length (variable) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 // Virtual Network Name // 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: The VIRTUAL-NETWORK-TLV formats 278 Type: TBD2 (to be allocated by IANA) 279 Length: Variable Length 281 Virtual Network Name (variable): an unique symbolic name for the VN. 282 It SHOULD be a string of printable ASCII characters, without a NULL 283 terminator. The VN name is a human-readable string that identifies a 284 VN and can be specified with the association information. An 285 implementation could use the VN name to maintain a mapping to the VN 286 association group and the LSPs associated with the VN. The VN name 287 MAY be specified by an operator or auto-generated by the PCEP 288 speaker. 290 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 291 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 292 MUST send a PCErr message with Error-Type=6 (mandatory object 293 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 294 the session. 296 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 298 5. Applicability to H-PCE architecture 300 The ability to compute shortest constrained TE LSPs in Multiprotocol 301 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 302 multiple domains has been identified as a key motivation for PCE 303 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 304 architecture which can be used for computing end-to-end paths for 305 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 306 Paths (LSPs). Within the hierarchical PCE architecture, the parent 307 PCE is used to compute a multi-domain path based on the domain 308 connectivity information. A child PCE may be responsible for a 309 single domain or multiple domains, it is used to compute the intra- 310 domain path based on its domain topology information. 312 [RFC8751] introduces general considerations for stateful PCE(s) in 313 hierarchical PCE architecture. In particular, the behavior changes 314 and additions to the existing stateful PCE mechanisms in the context 315 of a H-PCE architecture. 317 In Stateful H-PCE architecture, the Parent PCE receives a virtual 318 network creation request by its client over its Northbound API. This 319 VN is uniquely identified by an Association ID in VNAG as well as the 320 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 321 network in a single domain or across multiple domains. 323 As the Parent PCE computes the optimum E2E paths for each tunnel in 324 VN, it MUST associate each LSP with the VN to which it belongs. 325 Parent PCE sends a PCInitiate Message with this association 326 information in the VNAG Object (See Section 4 for details). This in 327 effect binds an LSP that is to be instantiated at the child PCE with 328 the VN. 330 Whenever changes occur with the instantiated LSP in a domain network, 331 the domain child PCE reports the changes using a PCRpt Message in 332 which the VNAG Object indicates the relationship between the LSP and 333 the VN. 335 Whenever an update occurs with VNs in the Parent PCE (via the 336 client's request), the parent PCE sends an PCUpd Message to inform 337 each affected child PCE of this change. 339 The Child PCE could then use this association to optimize all LSPs 340 belonging to the same VN association together. The Child PCE could 341 further take VN specific actions on the LSPs such as relaxation of 342 constraints, policy actions, setting default behavior etc. The 343 parent PCE could also maintain all E2E LSP or per-domain path 344 segments under a single VN association. 346 6. Implementation Status 348 [Note to the RFC Editor - remove this section before publication, as 349 well as remove the reference to RFC 7942.] 351 This section records the status of known implementations of the 352 protocol defined by this specification at the time of posting of this 353 Internet-Draft, and is based on a proposal described in [RFC7942]. 354 The description of implementations in this section is intended to 355 assist the IETF in its decision processes in progressing drafts to 356 RFCs. Please note that the listing of any individual implementation 357 here does not imply endorsement by the IETF. Furthermore, no effort 358 has been spent to verify the information presented here that was 359 supplied by IETF contributors. This is not intended as, and must not 360 be construed to be, a catalog of available implementations or their 361 features. Readers are advised to note that other implementations may 362 exist. 364 According to [RFC7942], "this will allow reviewers and working groups 365 to assign due consideration to documents that have the benefit of 366 running code, which may serve as evidence of valuable experimentation 367 and feedback that have made the implemented protocols more mature. 368 It is up to the individual working groups to use this information as 369 they see fit". 371 6.1. Huawei's Proof of Concept based on ONOS 373 The PCE function was developed in the ONOS open source platform. 374 This extension was implemented on a private version as a proof of 375 concept to ACTN. 377 o Organization: Huawei 379 o Implementation: Huawei's PoC based on ONOS 381 o Description: PCEP as a southbound plugin was added to ONOS. To 382 support ACTN, this extension in PCEP is used. Refer 383 https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 385 o Maturity Level: Prototype 387 o Coverage: Full 389 o Contact: satishk@huawei.com 391 7. Security Considerations 393 This document defines one new type for association, which do not add 394 any new security concerns beyond those discussed in [RFC5440], 395 [RFC8231] and [RFC8697] in itself. 397 Some deployments may find the Virtual Network Name and the VN 398 associations as extra sensitive; and thus should employ suitable PCEP 399 security mechanisms like TCP-AO [RFC5925] or [RFC8253]. 401 8. IANA Considerations 403 8.1. Association Object Type Indicator 405 This document defines a new association type, originally defined in 406 [RFC8697], for path protection. IANA is requested to make the 407 assignment of a new value for the sub-registry "ASSOCIATION Type 408 Field" (request to be created in [RFC8697]), as follows: 410 Value Name Reference 412 TBD1 VN Association Type [This I.D.] 414 8.2. PCEP TLV Type Indicator 416 This document defines a new TLV for carrying additional information 417 of LSPs within a path protection association group. IANA is 418 requested to make the assignment of a new value for the existing 419 "PCEP TLV Type Indicators" registry as follows: 421 Value Name Reference 423 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 425 8.3. PCEP Error 427 This document defines new Error-Type and Error-Value related to path 428 protection association. IANA is requested to allocate new error 429 values within the "PCEP-ERROR Object Error Types and Values" sub- 430 registry of the PCEP Numbers registry, as follows: 432 Error-Type Meaning 434 6 Mandatory Object missing 435 Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This 436 I.D.] 438 9. Manageability Considerations 440 9.1. Control of Function and Policy 442 An operator MUST BE allowed to mark LSPs that belong to the same VN. 443 This could also be done automatically based on the VN configuration. 445 9.2. Information and Data Models 447 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 448 association between LSPs including VN association. 450 9.3. Liveness Detection and Monitoring 452 Mechanisms defined in this document do not imply any new liveness 453 detection and monitoring requirements in addition to those already 454 listed in [RFC5440]. 456 9.4. Verify Correct Operations 458 Mechanisms defined in this document do not imply any new operation 459 verification requirements in addition to those already listed in 460 [RFC5440]. 462 9.5. Requirements On Other Protocols 464 Mechanisms defined in this document do not imply any new requirements 465 on other protocols. 467 9.6. Impact On Network Operations 469 Mechanisms defined in this document do not have any impact on network 470 operations in addition to those already listed in [RFC5440]. 472 10. References 474 10.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 482 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 483 DOI 10.17487/RFC5440, March 2009, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 491 Computation Element Communication Protocol (PCEP) 492 Extensions for Stateful PCE", RFC 8231, 493 DOI 10.17487/RFC8231, September 2017, 494 . 496 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 497 Computation Element Communication Protocol (PCEP) 498 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 499 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 500 . 502 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 503 Dhody, D., and Y. Tanaka, "Path Computation Element 504 Communication Protocol (PCEP) Extensions for Establishing 505 Relationships between Sets of Label Switched Paths 506 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 507 . 509 10.2. Informative References 511 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 512 Element (PCE)-Based Architecture", RFC 4655, 513 DOI 10.17487/RFC4655, August 2006, 514 . 516 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 517 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 518 June 2010, . 520 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 521 Path Computation Element Architecture to the Determination 522 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 523 DOI 10.17487/RFC6805, November 2012, 524 . 526 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 527 Code: The Implementation Status Section", BCP 205, 528 RFC 7942, DOI 10.17487/RFC7942, July 2016, 529 . 531 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 532 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 533 DOI 10.17487/RFC8453, August 2018, 534 . 536 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 537 the Path Computation Element (PCE) to the Abstraction and 538 Control of TE Networks (ACTN)", RFC 8637, 539 DOI 10.17487/RFC8637, July 2019, 540 . 542 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 543 Objective Functions in the Path Computation Element 544 Communication Protocol (PCEP)", RFC 5541, 545 DOI 10.17487/RFC5541, June 2009, 546 . 548 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 549 Constraints in the Path Computation Element Communication 550 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 551 . 553 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 554 Stateful Path Computation Element (PCE)", RFC 8051, 555 DOI 10.17487/RFC8051, January 2017, 556 . 558 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 559 "PCEPS: Usage of TLS to Provide a Secure Transport for the 560 Path Computation Element Communication Protocol (PCEP)", 561 RFC 8253, DOI 10.17487/RFC8253, October 2017, 562 . 564 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 565 "Hierarchical Stateful Path Computation Element (PCE)", 566 RFC 8751, DOI 10.17487/RFC8751, March 2020, 567 . 569 Appendix A. Contributors 571 Dhruv Dhody 572 Huawei Technologies 573 Divyashree Technopark, Whitefield 574 Bangalore, Karnataka 560066 575 India 577 Email: dhruv.ietf@gmail.com 579 Qin Wu 580 Huawei Technologies 581 China 583 Email: bill.wu@huawei.com 585 Xian Zhang 586 Huawei Technologies 587 China 589 Email: zhang.xian@huawei.com 591 Authors' Addresses 593 Young Lee 594 Samsung 595 Seoul 596 South Korea 598 Email: younglee.tx@gmail.com 599 Haomian Zheng 600 Huawei Technologies 601 H1-1-A043S Huawei Industrial Base, Songshanhu 602 Dongguan, Guangdong 523808 603 China 605 Email: zhenghaomian@huawei.com 607 Daniele Ceccarelli 608 Ericsson 609 Torshamnsgatan,48 610 Stockholm 611 Sweden 613 Email: daniele.ceccarelli@ericsson.com