idnits 2.17.1 draft-ietf-pce-vn-association-08.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 (11 May 2022) is 709 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) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-18 Summary: 0 errors (**), 0 flaws (~~), 2 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: 12 November 2022 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 11 May 2022 10 Path Computation Element Communication Protocol (PCEP) extensions for 11 establishing relationships between sets of Label Switched Paths and 12 Virtual Networks 13 draft-ietf-pce-vn-association-08 15 Abstract 17 This document describes how to extend the Path Computation Element 18 (PCE) Communication Protocol (PCEP) association mechanism introduced 19 by the PCEP Association Group specification, to further associate 20 sets of Label Switched Paths (LSPs) with a higher-level structure 21 such as a Virtual Network (VN) requested by a customer or 22 application. This extended association mechanism can be used to 23 facilitate control of virtual network using the PCE architecture. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 12 November 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Association Object Type Indicator . . . . . . . . . . . . 9 68 7.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9 69 7.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Manageability Considerations . . . . . . . . . . . . . . . . 10 71 8.1. Control of Function and Policy . . . . . . . . . . . . . 10 72 8.2. Information and Data Models . . . . . . . . . . . . . . . 10 73 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 74 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 75 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 76 8.6. Impact On Network Operations . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The Path Computation Element Communication Protocol (PCEP) provides 86 mechanisms for Path Computation Elements (PCEs) to perform path 87 computations in response to requests from Path Computation Clients 88 (PCCs) [RFC5440]. 90 [RFC8051] describes general considerations for a stateful PCE 91 deployment and examines its applicability and benefits, as well as 92 its challenges and limitations through a number of use cases. 93 [RFC8231] describes a set of extensions to PCEP to provide stateful 94 control. For its computations, a stateful PCE has access to not only 95 the information carried by the network's Interior Gateway Protocol 96 (IGP), but also the set of active paths and their reserved resources. 97 The additional state allows the PCE to compute constrained paths 98 while considering individual Label Switched Paths (LSPs) and their 99 interactions. 101 [RFC8281] describes the setup, maintenance and teardown of PCE- 102 initiated LSPs under the stateful PCE model. 104 [RFC8697] introduces a generic mechanism to create a grouping of 105 LSPs. This grouping can then be used to define associations between 106 sets of LSPs or between a set of LSPs and a set of attributes. 108 [RFC8453] introduces a framework for Abstraction and Control of TE 109 Networks (ACTN) and describes various Virtual Network (VN) operations 110 initiated by a customer or application. A VN is a customer view of 111 the TE network. Depending on the agreement between client and 112 provider, various VN operations and VN views are possible. 114 [RFC8637] examines the PCE and ACTN architectures and describes how 115 the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] 116 describes a hierarchy of stateful PCEs with Parent PCE coordinating 117 multi-domain path computation function between Child PCEs, and thus 118 making it the base for PCE applicability for ACTN. In this text 119 child PCE would be same as Provisioning Network Controller (PNC), and 120 the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453]. 122 In this context, there is a need to associate a set of LSPs with a VN 123 "construct" to facilitate VN operations in the PCE architecture. 124 This association allows a PCE to identify which LSPs belong to a 125 certain VN. The PCE could then use this association to optimize all 126 LSPs belonging to the VN at once. The PCE could further take VN- 127 specific actions on the LSPs, such as relaxation of constraints, 128 policy actions, setting default behavior, etc. 130 This document specifies a PCEP extension to associate a set of LSPs 131 based on Virtual Network (VN). 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 is not limited to - 155 * Path Computation: When computing a path for an LSP, it is useful 156 to analyze the impact of this LSP on the other LSPs belonging to 157 the same VN. The aim would be optimize all LSPs belonging to the 158 VN rather than a single LSP. Also, the optimization criteria 159 (such as minimizing the load of the most loaded link (MLL) 160 [RFC5541]) could be applied for all the LSPs belonging to the VN 161 identified by the VN association. 163 * Path Re-Optimization: The PCE would like to use advanced path 164 computation algorithms and optimization techniques that consider 165 all the LSPs belonging to a VN, and optimize them all together 166 during the path re-optimization. 168 In this document we define a new association group called the VN 169 Association Group (VNAG). This grouping is used to define the 170 association between a set of LSPs and a virtual network. 172 The Association Object contains a field to identify the type of 173 association, and this document defines a new Association Type value 174 of TBD1 to indicate that the association is a "VN Association". The 175 Association Identifier in the Association Object is the VNAG 176 Identifier and is handled in the same way as the generic association 177 identifier defined in [RFC8697]. 179 In this document, "VNAG object" refers to an Association Object with 180 the Association type set to "VN Association". 182 Local polices on the PCE define the computational and optimization 183 behavior for the LSPs in the VN. An LSP MUST NOT belong to more than 184 one VNAG. If an implementation encounters more than one VNAG object 185 in a PCEP message, it MUST process the first occurrence and it MUST 186 ignore the others. 188 [RFC8697] specifies the mechanism by which a PCEP speaker can 189 advertise which association types it supports. This is done using 190 the ASSOC-Type-List TLV carried within an OPEN object. A PCEP 191 speaker MUST include the VN Association Type (TBD1) in the ASSOC- 192 Type-List TLV before using the VNAG object in a PCEP message. As per 193 [RFC8697], if the implementation does not support the VN Association 194 Type, it will return a PCErr message with Error-Type 26 "Association 195 Error" and Error-value 1 "Association Type is not supported". 197 The Association IDs (VNAG IDs) for this Association Type are dynamic 198 in nature (and created by the Parent PCE (MDSC) based on the VN 199 operations for the LSPs belonging to the same VN). Operator 200 configuration of VNAG IDs is not supported so there is no need for an 201 Operator-Configured Association Range to be set. Thus, the VN 202 Association Type (TBD1) MUST NOT be present in the Operator- 203 Configured Association Range TLV if that TLV is present in the OPEN 204 object. If an implementation encounters the VN Association Type 205 (TBD1) in an Operator-Configured Association Range TLV, it MUST 206 ignore the associated Start-Assoc-ID and Range values. 208 This association is useful in a PCEP session between a parent PCE 209 (MDSC) and a child PCE (PNC). When computing the path, the child PCE 210 (PNC) refers to the VN association in the request from the parent PCE 211 (MDSC) and maps the VN to the associated LSPs and network resources. 212 From the perspective of Parent PCE, it receives a virtual network 213 creation request by its customer, with the VN uniquely identified by 214 an Association ID in VNAG as well as the Virtual Network identifier. 215 This VN may comprise multiple LSPs in the network in a single domain 216 or across multiple domains. Parent PCE sends a PCInitiate Message 217 with this association information in the VNAG Object. This in effect 218 binds an LSP that is to be instantiated at the child PCE with the VN. 219 The VN association information could be included as a part of the 220 response as well. Figure 1 shows an example of a typical VN 221 operation using PCEP. It is worth noting that in a multi-domain 222 scenario, the different domains are controlled by different child 223 PCEs. In order to set up the cross-domain tunnel, multiple segments 224 need to be stitched, by the border nodes in each domain who receives 225 the instruction from their child PCE (PNC). 227 ****** 228 ..........*MDSC*.............................. 229 . ****** .. MPI . 230 . . . PCEP . 231 . . . PCInitiate LSPx . 232 . . . with VNAG = 10 . 233 . . . . 234 . . . . 235 . . . . 236 v v v . 237 ****** ****** ****** . 238 *PNC1* *PNC2* *PNC4* . 239 ****** ****** ****** . 240 +---------------+ +---------------+ +---------------+ . 241 |A |----| |----| C| . 242 | | | | | | . 243 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 244 +------------B13+ +---------------+ +B43------------+ . 245 / . 246 ****** / . 247 *PNC3*<............/..................... 248 ****** / 249 +---------------+/ 250 B31 B34 251 | | 252 |DOMAIN 3 B| 253 +---------------+ 255 MDSC -> Parent PCE 256 PNC -> Child PCE 257 MPI -> PCEP 259 Figure 1: Example of VN operations in H-PCE Architecture 261 Whenever changes occur with the instantiated LSP in a domain network, 262 the domain child PCE reports the changes using a PCRpt Message in 263 which the VNAG Object indicates the relationship between the LSP and 264 the VN. 266 Whenever an update occurs with VNs in the Parent PCE (via the 267 customer's request), the parent PCE sends an PCUpd Message to inform 268 each affected child PCE of this change. 270 4. Extensions to PCEP 272 The format of VNAG is as per the ASSOCIATION object [RFC8697]. 274 This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV". 275 Optionally, the new TLV can be jointly used with the existing 276 "VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below: 278 * VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network 279 Identifier. 281 * VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 282 specific behavioral information, described in [RFC7470]. 284 The format of VIRTUAL-NETWORK-TLV is as follows. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type=TBD2 | Length (variable) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 // Virtual Network Identifier // 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 2: The VIRTUAL-NETWORK-TLV formats 297 Type: TBD2 (to be allocated by IANA) 299 Length: Variable Length, which covers the value portion of the TLV. 301 Virtual Network Identifier (variable): a symbolic name for the VN 302 that uniquely identifies the VN. It SHOULD be a string of printable 303 ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL 304 terminator. The Virtual Network Identifier is a human-readable 305 string that identifies a VN and can be specified with the association 306 information. An implementation could use the Virtual Network 307 Identifier to maintain a mapping to the VN association group and the 308 LSPs associated with the VN. The Virtual Network Identifier MAY be 309 specified by the customer or set via an operator policy or auto- 310 generated by the PCEP speaker. 312 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP 313 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 314 MUST send a PCErr message with Error-Type=6 (mandatory object 315 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 316 the session. 318 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 320 5. Implementation Status 322 [Note to the RFC Editor - remove this section before publication, as 323 well as remove the reference to RFC 7942.] 325 This section records the status of known implementations of the 326 protocol defined by this specification at the time of posting of this 327 Internet-Draft, and is based on a proposal described in [RFC7942]. 328 The description of implementations in this section is intended to 329 assist the IETF in its decision processes in progressing drafts to 330 RFCs. Please note that the listing of any individual implementation 331 here does not imply endorsement by the IETF. Furthermore, no effort 332 has been spent to verify the information presented here that was 333 supplied by IETF contributors. This is not intended as, and must not 334 be construed to be, a catalog of available implementations or their 335 features. Readers are advised to note that other implementations may 336 exist. 338 According to [RFC7942], "this will allow reviewers and working groups 339 to assign due consideration to documents that have the benefit of 340 running code, which may serve as evidence of valuable experimentation 341 and feedback that have made the implemented protocols more mature. 342 It is up to the individual working groups to use this information as 343 they see fit". 345 5.1. Huawei's Proof of Concept based on ONOS 347 The PCE function was developed in the ONOS open source platform. 348 This extension was implemented on a private version as a proof of 349 concept to ACTN. 351 * Organization: Huawei 353 * Implementation: Huawei's PoC based on ONOS 355 * Description: PCEP as a southbound plugin was added to ONOS. To 356 support ACTN, this extension in PCEP is used. Refer 357 https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 359 * Maturity Level: Prototype 361 * Coverage: Full 363 * Contact: satishk@huawei.com 365 6. Security Considerations 367 This document defines one new type for association, which do not add 368 any new security concerns beyond those discussed in [RFC5440], 369 [RFC8231] and [RFC8697] in itself. 371 Some deployments may find the Virtual Network Identifier and the VN 372 associations as extra sensitive; and thus should employ suitable PCEP 373 security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253]. 375 7. IANA Considerations 377 7.1. Association Object Type Indicator 379 IANA is requested to make the assignment of a new value for the sub- 380 registry "ASSOCIATION Type Field" (request to be created in 381 [RFC8697]) within the "Path Computation Element Protocol (PCEP) 382 Numbers" registry, as follows: 384 Value Name Reference 386 TBD1 VN Association Type [This I.D.] 388 7.2. PCEP TLV Type Indicator 390 IANA is requested to make the assignment of a new value for the 391 existing "PCEP TLV Type Indicators" sub-registry within the "Path 392 Computation Element Protocol (PCEP) Numbers" registry, as follows: 394 Value Name Reference 396 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 398 7.3. PCEP Error 400 IANA is requested to allocate new error value within the "PCEP-ERROR 401 Object Error Types and Values" sub-registry within the "Path 402 Computation Element Protocol (PCEP) Numbers" registry, as follows: 404 Error-Type Meaning 406 6 Mandatory Object missing 407 Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This 408 I.D.] 410 8. Manageability Considerations 412 8.1. Control of Function and Policy 414 An operator MUST be allowed to mark LSPs that belong to the same VN. 415 This could also be done automatically based on the VN configuration. 417 8.2. Information and Data Models 419 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 420 association between LSPs including VN association. 422 8.3. Liveness Detection and Monitoring 424 Mechanisms defined in this document do not imply any new liveness 425 detection and monitoring requirements in addition to those already 426 listed in [RFC5440]. 428 8.4. Verify Correct Operations 430 Mechanisms defined in this document do not imply any new operation 431 verification requirements in addition to those already listed in 432 [RFC5440]. 434 8.5. Requirements On Other Protocols 436 Mechanisms defined in this document do not imply any new requirements 437 on other protocols. 439 8.6. Impact On Network Operations 441 [RFC8637] describe the network operations when PCE is used for VN 442 operations. Section 3 further specify the operations when VN 443 associations is used. 445 9. References 447 9.1. Normative References 449 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 450 RFC 20, DOI 10.17487/RFC0020, October 1969, 451 . 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 459 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 460 DOI 10.17487/RFC5440, March 2009, 461 . 463 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 464 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 465 May 2017, . 467 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 468 Computation Element Communication Protocol (PCEP) 469 Extensions for Stateful PCE", RFC 8231, 470 DOI 10.17487/RFC8231, September 2017, 471 . 473 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 474 Computation Element Communication Protocol (PCEP) 475 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 476 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 477 . 479 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 480 Dhody, D., and Y. Tanaka, "Path Computation Element 481 Communication Protocol (PCEP) Extensions for Establishing 482 Relationships between Sets of Label Switched Paths 483 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 484 . 486 9.2. Informative References 488 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 489 Computation Element (PCE)-Based Architecture", RFC 4655, 490 DOI 10.17487/RFC4655, August 2006, 491 . 493 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 494 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 495 June 2010, . 497 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 498 Path Computation Element Architecture to the Determination 499 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 500 DOI 10.17487/RFC6805, November 2012, 501 . 503 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 504 Code: The Implementation Status Section", BCP 205, 505 RFC 7942, DOI 10.17487/RFC7942, July 2016, 506 . 508 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 509 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 510 DOI 10.17487/RFC8453, August 2018, 511 . 513 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 514 the Path Computation Element (PCE) to the Abstraction and 515 Control of TE Networks (ACTN)", RFC 8637, 516 DOI 10.17487/RFC8637, July 2019, 517 . 519 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 520 Objective Functions in the Path Computation Element 521 Communication Protocol (PCEP)", RFC 5541, 522 DOI 10.17487/RFC5541, June 2009, 523 . 525 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 526 Constraints in the Path Computation Element Communication 527 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 528 . 530 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 531 Stateful Path Computation Element (PCE)", RFC 8051, 532 DOI 10.17487/RFC8051, January 2017, 533 . 535 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 536 "PCEPS: Usage of TLS to Provide a Secure Transport for the 537 Path Computation Element Communication Protocol (PCEP)", 538 RFC 8253, DOI 10.17487/RFC8253, October 2017, 539 . 541 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 542 "Hierarchical Stateful Path Computation Element (PCE)", 543 RFC 8751, DOI 10.17487/RFC8751, March 2020, 544 . 546 [I-D.ietf-pce-pcep-yang] 547 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 548 "A YANG Data Model for Path Computation Element 549 Communications Protocol (PCEP)", Work in Progress, 550 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 551 2022, . 554 Appendix A. Contributors 556 Dhruv Dhody 557 Huawei Technologies 558 Divyashree Technopark, Whitefield 559 Bangalore, Karnataka 560066 560 India 561 Email: dhruv.ietf@gmail.com 563 Qin Wu 564 Huawei Technologies 565 China 566 Email: bill.wu@huawei.com 568 Xian Zhang 569 Huawei Technologies 570 China 571 Email: zhang.xian@huawei.com 573 Adrian Farrel 574 Old Dog Consulting 575 Email: adrian@olddog.co.uk 577 Authors' Addresses 579 Young Lee 580 Samsung 581 Seoul 582 South Korea 583 Email: younglee.tx@gmail.com 585 Haomian Zheng 586 Huawei Technologies 587 H1, Huawei Xiliu Beipo Village, Songshan Lake 588 Dongguan 589 Guangdong, 523808 590 China 591 Email: zhenghaomian@huawei.com 592 Daniele Ceccarelli 593 Ericsson 594 Torshamnsgatan,48 595 Stockholm 596 Sweden 597 Email: daniele.ceccarelli@ericsson.com