idnits 2.17.1 draft-lee-pce-pcep-ls-optical-09.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 (March 9, 2020) is 1501 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) == Unused Reference: 'RFC8363' is defined on line 543, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee 2 Internet Draft Samsung 3 Intended Status: Standard track Haomian Zheng 4 Expires: September 2020 Huawei 5 Daniele Ceccarelli 6 Ericsson 7 Wei Wang 8 Beijing Univ. of Posts and Telecom 9 Peter Park 10 KT 11 Bin Young Yoon 12 ETRI 14 March 9, 2020 16 PCEP Extension for Distribution of Link-State and TE information for 17 Optical Networks 19 draft-lee-pce-pcep-ls-optical-09 21 Abstract 23 In order to compute and provide optimal paths, Path Computation 24 Elements (PCEs) require an accurate and timely Traffic Engineering 25 Database (TED). Traditionally this Link State and TE information has 26 been obtained from a link state routing protocol (supporting traffic 27 engineering extensions). 29 This document extends the Path Communication Element Communication 30 Protocol (PCEP) with Link-State and TE information for optical 31 networks. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with 36 the provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as 46 reference material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on September 9, 2020. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction ................................................ 3 74 1.1. Requirements Language .................................. 4 75 2. Applicability ............................................... 5 76 3. Requirements for PCEP extension ............................. 6 77 3.1. Reachable source-destination ........................... 6 78 3.2. Optical latency......................................... 7 79 4. PCEP-LS extension for Optical Networks ...................... 7 80 4.1. Node Attributes TLV .................................... 7 81 4.2. Link Attributes TLV .................................... 8 82 4.3. PCEP-LS for Optical Network Extension .................. 9 83 5. Security Considerations .................................... 10 84 6. IANA Considerations ........................................ 10 85 6.1. PCEP-LS Sub-TLV Type Indicators ....................... 10 86 7. References ................................................. 11 87 7.1. Normative References .................................. 11 88 7.2. Informative References ................................ 11 90 Appendix A. Contributor Addresses ............................. 13 91 Author's Addresses ............................................ 13 93 1. Introduction 95 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 96 (GMPLS), a Traffic Engineering Database (TED) is used in computing 97 paths for connection oriented packet services and for circuits. The 98 TED contains all relevant information that a Path Computation 99 Element (PCE) needs to perform its computations. It is important 100 that the TED should be complete and accurate anytime so that the PCE 101 can perform path computations. 103 In MPLS and GMPLS networks, Interior Gateway routing Protocols 104 (IGPs) have been used to create and maintain a copy of the TED at 105 each node. One of the benefits of the PCE architecture [RFC4655] is 106 the use of computationally more sophisticated path computation 107 algorithms and the realization that these may need enhanced 108 processing power not necessarily available at each node 109 participating in an IGP. 111 Section 4.3 of [RFC4655] describes the potential load of the TED on 112 a network node and proposes an architecture where the TED is 113 maintained by the PCE rather than the network nodes. However it does 114 not describe how a PCE would obtain the information needed to 115 populate its TED. PCE may construct its TED by participating in the 116 IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] 117 for GMPLS). An alternative is offered by [RFC7752]. 119 [RFC7399] touches upon this issue:"It has also been proposed that 120 the PCE Communication Protocol (PCEP) [RFC5440] could be extended to 121 serve as an information collection protocol to supply information 122 from network devices to a PCE. The logic is that the network devices 123 may already speak PCEP and so the protocol could easily be used to 124 report details about the resources and state in the network, 125 including the LSP state discussed in Sections 14 and 15." 127 [RFC8231] describes a set of extensions to PCEP to provide stateful 128 control. A stateful PCE has access to not only the information 129 carried by the network's Interior Gateway Protocol (IGP), but also 130 the set of active paths and their reserved resources for its 131 computations. PCC can delegate the rights to modify the LSP 132 parameters to an Active Stateful PCE. This requires PCE to quickly 133 be updated on any changes in the Topology and TEDB, so that PCE can 134 meet the need for updating LSPs effectively and in a timely manner. 135 The fastest way for a PCE to be updated on TED changes is via a 136 direct interface with each network node and with incremental update 137 from each network node. [S-PCE-GMPLS] specified the extensions to 138 apply stateful PCE to GMPLS-based networks. 140 [RFC8281] describes the setup, maintenance and teardown of PCE- 141 initiated LSPs under the stateful PCE model, without the need for 142 local configuration on the PCC, thus allowing for a dynamic network 143 that is centrally controlled and deployed. This model requires 144 timely topology and TED update at the PCE. 146 [PCEP-LS-Arch] proposes alternative architecture approaches for 147 learning and maintaining the Link State (and TE) information 148 directly on a PCE from network nodes as an alternative to IGPs and 149 BGP transport and investigate the impact from the PCE, routing 150 protocol, and network node perspectives. 152 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which 153 can be used for computing end-to-end paths for inter-domain MPLS 154 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). 155 Within the Hierarchical PCE (H-PCE) architecture [RFC6805], the 156 Parent PCE (P-PCE) is used to compute a multi-domain path based on 157 the domain connectivity information. A Child PCE (C-PCE) may be 158 responsible for a single domain or multiple domains, it is used to 159 compute the intra-domain path based on its domain topology 160 information. 162 [Stateful H-PCE] presents general considerations for stateful PCE(s) 163 in hierarchical PCE architecture. In particular, the behavior 164 changes and additions to the existing stateful PCE mechanisms 165 (including PCE-initiated LSP setup and active PCE usage) in the 166 context of networks using the H-PCE architecture. 168 [PCEP-LS] describes a mechanism by which Link State and TE 169 information can be collected from packet networks and shared with 170 PCE with the PCEP itself. This is achieved using a new PCEP message 171 format. 173 This draft describes an optical extension of [PCEP-LS] and explains 174 how encodings suggested by [PCEP-LS] can be used in the optical 175 network contexts. 177 1.1. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in 182 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 2. Applicability 187 There are three main applicability of this alternative proposed by 188 this draft: 190 - Case 1: Where there is IGP running in optical network but 191 there is a need for a faster link-state and TE resource 192 collection at the PCE directly from an optical node (PCC) via 193 a PCC-PCE interface. 195 o A PCE may receive an incremental update (as opposed to 196 the entire TE information of the node/link). 198 Note: A PCE may receive full information from IGP using 199 existing mechanism. In some cases, the convergence of full 200 link-state and TE resource information of the entire network 201 may not be appropriate for certain applications. Incremental 202 update capability will enhance the accuracy of the TE 203 information at a given time. 205 - Case 2: Where there is no IGP running in the optical network 206 and there is a need for link-state and TE resource collections 207 at the PCE directly from an optical node (PCC) via a PCC-PCE 208 interface. 210 - Case 3: Where there is a need for transporting abstract 211 optical link-state and TE information from child PCE and to a 212 parent PCE in H-PCE [RFC6805] and [Stateful H-PCE] as well as 213 for Physical Network Controller (PNC) to Multi-Domain Service 214 Coordinator (MDSC) in Abstraction and Control of TE Networks 215 (ACTN) [RFC8453]. 217 Note: The applicability for Case 3 may arise as a consequence 218 of Case 1 and Case 2. When TE information changes occur in the 219 optical network, this may also affect abstracted TE 220 information and thus needs to be updated to Parent PCE/MSDC 221 from each child PCE/PNC. 223 3. Requirements for PCEP extension 225 The key requirements associated with link-state (and TE) 226 distribution are identified for PCEP and listed in Section 4 of 227 [PCEP-LS]. These new functions required in PCEP to support 228 distribution of link-state (and TE) information are described in 229 Section 5 of [PCEP-LS]. Details of PCEP messages and related 230 Objects/TLVs are specified in Sections 8 and 9 of [PCEP-LS]. The key 231 requirements and new functions specified in [PCEP-LS] are equally 232 applicable to optical networks. 234 Besides the generic requirements specified in [PCEP-LS], optical 235 specific features also need to be considered in this document. As 236 connection-based network, there are specific parameters such as 237 reachable table, optical latency, wavelength consistency and some 238 other parameters that need to be included during the topology 239 collection. Without these restrictions, the path computation may be 240 inaccurate or infeasible for deployment, therefore these information 241 MUST be included in the PCEP. 243 The procedure on how the optical parameters are used is described in 244 following sections. 246 3.1. Reachable source-destination 248 The reachable source-destination node pair indicates that there are 249 a few number of OCh paths between two nodes. The reachability is 250 restricted by impairment, wavelength consistency and so on. This 251 information is necessary at PCE to promise the path computed between 252 source node and destination node is reachable. In this scenario, the 253 PCE should be responsible to compute how many OCh paths are 254 available to set up connections between source and destination node. 255 Moreover, if a set of optical wavelength is indicated in the path 256 computation request, the PCE should also determine whether a 257 wavelength of the set of preselected optical wavelength is available 258 for the source-destination pair connection. 260 To enable PCE to complete the above functions, the reachable 261 relationship and OMS link information need to be reported to PCE. 262 Once PCE detect that any wavelength is available, the corresponding 263 OMS link should be included in a lambda plane. Then this link can be 264 used for path computation in future. 266 Moreover, in a hierarchical PCE architecture, the information above 267 need to be reported from child PCE to parent PCE, who acts as a 268 service coordinator. 270 3.2. Optical latency 272 It is a usual case that the PCC indicates the latency when 273 requesting the path computation. In optical networks the latency is 274 a very sensitive parameter and there is stricter requirement on 275 latency. Given the maximal number of OCh paths between source- 276 destination nodes, the PCE also need to determine how many OCh path 277 satisfies the indicated latency threshold. 279 There is usually high-performance algorithm running on the PCE to 280 guarantee the performance of the computed path. During the 281 computation, the delay factor may be converted into a kind of link 282 weight. After the algorithm provides a few candidate paths between 283 the source and destination nodes, the PCE SHOULD be capable to 284 selecting one shortest path by computing the total path propagation 285 delay. 287 Optical PCEs are embedded with optimization algorithm, e.g., 288 shortest path algorithm, to improve the performance of computed 289 path. 291 4. PCEP-LS extension for Optical Networks 293 This section provides additional PCEP-LS extension necessary to 294 support optical networks. All Objects/TLVs defined in [PCEP-LS] are 295 applicable to optical networks. 297 4.1. Node Attributes TLV 299 Node-Attributed TLV is defined in Section 9.2.10.1 in [PCEP-LS] as 300 follows. This TLV is applicable for LS Node Object-Type as defined 301 in [PCEP-LS]. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 // Node Attributes Sub-TLVs (variable) // 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 The following 'Node Attribute' sub-TLVs are valid for optical 314 networks: 316 +-----------+------------------+--------------+-------------------+ 317 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference| 318 +-----------+------------------+--------------+---------+---------+ 319 | TBD | Connectivity | 5/14 | variable|[RFC7579]| 320 | | Matrix | | |[RFC7580]| 321 | TBD | Resource Block | 6/1 | variable|[RFC7688]| 322 | | Information | | | | 323 | TBD | Resource Block | 6/2 | variable|[RFC7688]| 324 | | Accessibility | | | | 325 | TBD | Resource Block | 6/3 | variable|[RFC7688]| 326 | | Wavelength Const | | | | 327 | TBD | Resource Block | 6/4 | variable|[RFC7688]| 328 | | Pool State | | | | 329 | TBD | Resource Block | 6/5 | variable|[RFC7688]| 330 | | Shared Access | | | | 331 | | Wavelength Avail.| | | | 332 +------------------------------------------------------=----------+ 334 4.2. Link Attributes TLV 336 Link-Attributes TLV is defined in Section 9.2.10.2 in [PCEP-LS] as 337 follows. This TLV is applicable for LS Link Object-Type as defined 338 in [PCEP-LS]. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 // Link Attributes Sub-TLVs (variable) // 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 The following 'Link Attribute' sub-TLVs are valid for optical 351 networks: 353 +-----------+-----------------+--------------+--------+----------+ 354 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference | 355 | | | | | | 356 +-----------+-----------------+--------------+--------+----------+ 357 | TBD | ISCD | 15 |Variable|[RFC4203] | 358 | | | | | | 359 | TBD | OTN-TDM SCSI | 15/1,2 |Variable|[RFC4203] | 360 | | | | |[RFC7138] | 361 | TBD | WSON-LSC SCSI | 15/1,2 |Variable|[RFC4203] | 362 | | | | |[RFC7688] | 363 | TBD | Flexi-grid SCSI | 15/1 |Variable|[RFC8363] | 364 | | | | | | 365 | TBD | Port Label | 34 |Variable|[RFC7579] | 366 | | Restriction | | |[RFC7580] | 367 | | | | |[RFC8363] | 368 +-----------+-----------------+--------------+--------+----------+ 370 4.3. PCEP-LS for Optical Network Extension 372 This section provides additional PCEP-LS extension necessary to 373 support optical networks parameters discussed in Sections 3.1 and 374 3.2. 376 The link state information collection is usually done before the 377 path computation processing. The procedure can be divided into 1) 378 link state collection by receiving the corresponding topology 379 information in a periodical style; 2) path computation on PCE, 380 triggered by receiving the path computation request message from 381 PCC, and completed by transmitting a path computation reply with the 382 path computation result, per [RFC4655]. 384 For OTN networks, max bandwidth available may be per ODU 0/1/2/3 385 switching level or aggregated across all ODU switching levels (i.e., 386 ODUj/k). 388 For WSON networks, RWA information collected from NEs would be 389 utilized to compute light paths. The list of information can be 390 found in [RFC7688]. More specifically, the max bandwidth available 391 may be per lambda/frequency level (OCh) or aggregated across all 392 lambda/frequency level. Per OCh level abstraction gives more 393 detailed data to the P-PCE at the expense of more information 394 processing. Either the OCh-level or the aggregated level abstraction 395 in the RWA constraint (i.e., wavelength continuity) needs to be 396 taken into account by the PCE during path computation. Resource 397 Block Accessibility (i.e., wavelength conversion information) in 398 [RFC7688] needs to be taken into account in order to guarantee the 399 reliability for optical path computation. 401 [Editor's Note: Encoding will be provided in the revision, including 402 RFC7688 RWA information] 404 5. Security Considerations 406 This document extends PCEP for LS (and TE) distribution including a 407 set of TLVs. Procedures and protocol extensions defined in this 408 document do not affect the overall PCEP security model. See 409 [RFC5440], [RFC8253]. The PCE implementation SHOULD provide 410 mechanisms to prevent strains created by network flaps and amount of 411 LS (and TE) information. Thus it is suggested that any mechanism 412 used for securing the transmission of other PCEP message be applied 413 here as well. As a general precaution, it is RECOMMENDED that these 414 PCEP extensions only be activated on authenticated and encrypted 415 sessions belonging to the same administrative authority. 417 6. IANA Considerations 419 This document requests IANA actions to allocate code points for the 420 protocol elements defined in this document. 422 6.1. PCEP-LS Sub-TLV Type Indicators 424 This document specifies a set of PCEP-LS Sub-TLVs. IANA is requested 425 to create a "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV 426 Type Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Node 427 Attributes TLV and Link Attributes TLV). 429 +-----------+------------------+--------------+----------+ 430 | Sub-TLV | Description | Ref Sub-TLV | Reference| 431 +-----------+------------------+--------------+----------+ 432 | TBD | Connectivity | 5/14 | [RFC7579]| 433 | | Matrix | | [RFC7580]| 434 | TBD | Resource Block | 6/1 | [RFC7688]| 435 | | Information | | | 436 | TBD | Resource Block | 6/2 | [RFC7688]| 437 | | Accessibility | | | 438 | TBD | Resource Block | 6/3 | [RFC7688]| 439 | | Wavelength Const | | | 440 | TBD | Resource Block | 6/4 | [RFC7688]| 441 | | Pool State | | | 442 | TBD | Resource Block | 6/5 | [RFC7688]| 443 | | Shared Access | | | 444 | | Wavelength Avail.| | | 445 | TBD | ISCD | 15 |[RFC4203] | 446 | | | | | 447 | TBD | OTN-TDM SCSI | 15/1,2 |[RFC4203] | 448 | | | |[RFC7138] | 449 | TBD | WSON-LSC SCSI | 15/1,2 |[RFC4203] | 450 | | | |[RFC7688] | 451 | TBD | Flexi-grid SCSI | 15/1 |[RFC8363] | 452 | | | | | 453 | TBD | Port Label | 34 |[RFC7579] | 454 | | Restriction | |[RFC7580] | 455 | | | |[RFC8363] | 456 +-----------+------------------+--------------+----------+ 458 7. References 460 7.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 466 Engineering", RFC 5305, October 2008. 468 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 469 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 470 March 2009. 472 [RFC7688] Lee, Y., Ed., and G. Bernstein, Ed., "GMPLS OSPF 473 Enhancement for Signal and Network Element Compatibility 474 for Wavelength Switched Optical Networks", RFC 7688, 475 November 2015. 477 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 478 Key Words", RFC 8174, May 2017. 480 7.2. Informative References 482 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 483 (TE) Extensions to OSPF Version 2", RFC 3630, September 484 2003. 486 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 487 Support of Generalized Multi-Protocol Label Switching 488 (GMPLS)", RFC 4203, October 2005. 490 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 491 Element (PCE)-Based Architecture", RFC 4655, August 2006. 493 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 494 in Support of Generalized Multi-Protocol Label Switching 495 (GMPLS)", RFC 5307, October 2008. 497 [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 498 S.Ray, "North-Bound Distribution of Link-State and TE 499 information using BGP", RFC 7752, March 2016. 501 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 502 Protocol Extensions for Stateful PCE Usage in GMPLS- 503 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 504 gmpls, work in progress. 506 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 507 Computation Element Architecture", RFC 7399, October 2015. 509 [RFC8453] D.Ceccarelli, and Y. Lee (Editors), "Framework for 510 Abstraction and Control of TE Networks", RFC453, August, 511 2018. 513 [RFC6805] A. Farrel and D. King, "The Application of the Path 514 Computation Element Architecture to the Determination of a 515 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 516 2012. 518 [PCEP-LS-Arch] Y. Lee, D. Dhody and D. Ceccarelli, "Architecture and 519 Requirement for Distribution of Link-State and TE 520 Information via PCEP", draft-leedhody-teas-pcep-ls, work 521 in progress. 523 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 524 Distribution of Link-State and TE Information.", work in 525 progress, September 21, 2015 527 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 528 Extensions for Stateful PCE", RFC8231, September 2017. 530 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., 531 "PCEPS: Usage of TLS to Provide a Secure Transport for the 532 Path Computation Element Communication Protocol (PCEP)", 533 RFC8253, October 2017. 535 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 536 Extensions for PCE-initiated LSP Setup in a Stateful PCE 537 Model", RFC8281, December 2017. 539 [Stateful H-PCE] D. Dhody, Y. Lee and D. Ceccarelli, "Hierarchical 540 Stateful Path Computation Element (PCE)", draft-ietf-pce- 541 stateful-hpce, work-in-progress. 543 [RFC8363] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 544 Ceccarelli, "GMPLS OSPF Extensions in support of Flexi- 545 grid DWDM networks", RFC8363, May 2018. 547 Appendix A. Contributor Addresses 549 Dhruv Dhody 550 Huawei Technologies 551 Divyashree Techno Park, Whitefield 552 Bangalore, Karnataka 560066 553 India 554 Email: dhruv.ietf@gmail.com 556 Author's Addresses 558 Young Lee 559 Samsung 560 Email: younglee.tx@gmail.com 562 Haomian Zheng 563 Huawei Technologies Co., Ltd. 564 Email: zhenghaomian@huawei.com 566 Daniele Ceccarelli 567 Ericsson 568 Torshamnsgatan,48 569 Stockholm 570 Sweden 572 EMail: daniele.ceccarelli@ericsson.com 574 Wei Wang 575 Beijing University of Posts and Telecom 576 No. 10, Xitucheng Rd. Haidian District, Beijing 100876, P.R.China 578 Email: weiw@bupt.edu.cn 580 Peter Park 581 KT 582 Email: peter.park@kt.com 584 Bin Yeong Yoon 585 ETRI 586 Email: byyun@etri.re.kr