idnits 2.17.1 draft-lee-pce-pcep-ls-optical-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 234: '... MUST be included in the PCEP....' RFC 2119 keyword, line 276: '...on nodes, the PCE SHOULD be capable to...' RFC 2119 keyword, line 401: '... [RFC5440], [RFC8253]. The PCE implementation SHOULD provide...' RFC 2119 keyword, line 405: '...recaution, it is RECOMMENDED that thes...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 4, 2018) is 2054 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5307' is mentioned on line 117, but not defined == Missing Reference: 'RFC7688' is mentioned on line 390, but not defined == Unused Reference: 'RFC4674' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'S-PCE-GMPLS' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC7449' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'G.680' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC8363' is defined on line 555, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5088 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5089 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5250 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5305 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5440 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee 2 Haomian Zheng 3 Internet Draft Huawei 4 Intended Status: Standard 5 Expires: March 4, 2019 Daniele Ceccarelli 6 Ericsson 8 Wei Wang 9 Beijing Univ. of Posts and Telecom 11 Peter Park 12 KT 14 Bin Young Yoon 15 ETRI 17 September 4, 2018 19 PCEP Extension for Distribution of Link-State and TE information for 20 Optical Networks 22 draft-lee-pce-pcep-ls-optical-05 24 Abstract 26 In order to compute and provide optimal paths, Path Computation 27 Elements (PCEs) require an accurate and timely Traffic Engineering 28 Database (TED). Traditionally this Link State and TE information has 29 been obtained from a link state routing protocol (supporting traffic 30 engineering extensions). 32 This document extends the Path Communication Element Communication 33 Protocol (PCEP) with Link-State and TE information for optical 34 networks. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on March 4, 2019. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Applicability..................................................4 78 3. Requirements for PCEP extension................................5 79 3.1. Reachable source-destination..............................6 80 3.2. Optical latency...........................................6 81 4. PCEP-LS extension for Optical Networks.........................7 82 4.1. Node Attributes TLV.......................................7 83 4.2. Link Attributes TLV.......................................8 84 4.3. PCEP-LS for Optical Network Extension.....................9 85 5. Security Considerations.......................................10 86 6. IANA Considerations...........................................10 87 6.1. PCEP-LS Sub-TLV Type Indicators..........................10 88 7. References....................................................11 89 7.1. Normative References.....................................11 90 7.2. Informative References...................................12 91 Appendix A. Contributor Addresses................................13 92 Author's Addresses...............................................14 94 1. Introduction 96 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 97 (GMPLS), a Traffic Engineering Database (TED) is used in computing 98 paths for connection oriented packet services and for circuits. The 99 TED contains all relevant information that a Path Computation 100 Element (PCE) needs to perform its computations. It is important 101 that the TED should be complete and accurate anytime so that the PCE 102 can perform path computations. 104 In MPLS and GMPLS networks, Interior Gateway routing Protocols 105 (IGPs) have been used to create and maintain a copy of the TED at 106 each node. One of the benefits of the PCE architecture [RFC4655] is 107 the use of computationally more sophisticated path computation 108 algorithms and the realization that these may need enhanced 109 processing power not necessarily available at each node 110 participating in an IGP. 112 Section 4.3 of [RFC4655] describes the potential load of the TED on 113 a network node and proposes an architecture where the TED is 114 maintained by the PCE rather than the network nodes. However it does 115 not describe how a PCE would obtain the information needed to 116 populate its TED. PCE may construct its TED by participating in the 117 IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] 118 for GMPLS). An alternative is offered by [BGP-LS]. 120 [RFC7399] touches upon this issue: "It has also been proposed that 121 the PCE Communication Protocol (PCEP) [RFC5440] could be extended to 122 serve as an information collection protocol to supply information 123 from network devices to a PCE. The logic is that the network devices 124 may already speak PCEP and so the protocol could easily be used to 125 report details about the resources and state in the network, 126 including the LSP state discussed in Sections 14 and 15." 128 [RFC8231] describes a set of extensions to PCEP to provide stateful 129 control. A stateful PCE has access to not only the information 130 carried by the network's Interior Gateway Protocol (IGP), but also 131 the set of active paths and their reserved resources for its 132 computations. PCC can delegate the rights to modify the LSP 133 parameters to an Active Stateful PCE. This requires PCE to quickly 134 be updated on any changes in the Topology and TEDB, so that PCE can 135 meet the need for updating LSPs effectively and in a timely manner. 137 The fastest way for a PCE to be updated on TED changes is via a 138 direct interface with each network node and with incremental update 139 from each network node. 141 [RFC8281] describes the setup, maintenance and teardown of PCE- 142 initiated LSPs under the stateful PCE model, without the need for 143 local configuration on the PCC, thus allowing for a dynamic network 144 that is centrally controlled and deployed. This model requires 145 timely topology and TED update at the PCE. 147 [PCEP-LS-Arch] proposes alternative architecture approaches for 148 learning and maintaining the Link State (and TE) information 149 directly on a PCE from network nodes as an alternative to IGPs and 150 BGP transport and investigate the impact from the PCE, routing 151 protocol, and network node perspectives. 153 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which 154 can be used for computing end-to-end paths for inter-domain MPLS 155 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). 156 Within the Hierarchical PCE (H-PCE) architecture [RFC6805], the 157 Parent PCE (P-PCE) is used to compute a multi-domain path based on 158 the domain connectivity information. A Child PCE (C-PCE) may be 159 responsible for a single domain or multiple domains, it is used to 160 compute the intra-domain path based on its domain topology 161 information. 163 [Stateful H-PCE] presents general considerations for stateful PCE(s) 164 in hierarchical PCE architecture. In particular, the behavior 165 changes and additions to the existing stateful PCE mechanisms 166 (including PCE-initiated LSP setup and active PCE usage) in the 167 context of networks using the H-PCE architecture. 169 [PCEP-LS] describes a mechanism by which Link State and TE 170 information can be collected from packet networks and shared with 171 PCE with the PCEP itself. This is achieved using a new PCEP message 172 format. 174 This draft describes an optical extension of [PCEP-LS] and explains 175 how encodings suggested by [PCEP-LS] can be used in the optical 176 network contexts. 178 2. Applicability 180 There are three main applicability of this alternative proposed by 181 this draft: 183 - Case 1: Where there is IGP running in optical network but 184 there is a need for a faster link-state and TE resource 185 collection at the PCE directly from an optical node (PCC) via 186 a PCC-PCE interface. 188 o A PCE may receive an incremental update (as opposed to 189 the entire TE information of the node/link). 191 Note: A PCE may receive full information from IGP using 192 existing mechanism. In some cases, the convergence of full 193 link-state and TE resource information of the entire network 194 may not be appropriate for certain applications. Incremental 195 update capability will enhance the accuracy of the TE 196 information at a given time. 198 - Case 2: Where there is no IGP running in the optical network 199 and there is a need for link-state and TE resource collections 200 at the PCE directly from an optical node (PCC) via a PCC-PCE 201 interface. 203 - Case 3: Where there is a need for transporting abstract 204 optical link-state and TE information from child PCE and to a 205 parent PCE in H-PCE [RFC6805] and [Stateful H-PCE] as well as 206 for Physical Network Controller (PNC) to Multi-Domain Service 207 Coordinator (MDSC) in Abstraction and Control of TE Networks 208 (ACTN) [RFC8345]. 210 Note: The applicability for Case 3 may arise as a consequence 211 of Case 1 and Case 2. When TE information changes occur in the 212 optical network, this may also affect abstracted TE 213 information and thus needs to be updated to Parent PCE/MSDC 214 from each child PCE/PNC. 216 3. Requirements for PCEP extension 218 The key requirements associated with link-state (and TE) 219 distribution are identified for PCEP and listed in Section 4 of 220 [PCEP-LS]. These new functions required in PCEP to support 221 distribution of link-state (and TE) information are described in 222 Section 5 of [PCEP-LS]. Details of PCEP messages and related 223 Objects/TLVs are specified in Sections 8 and 9 of [PCEP-LS]. The key 224 requirements and new functions specified in [PCEP-LS] are equally 225 applicable to optical networks. 227 Besides the generic requirements specified in [PCEP-LS], optical 228 specific features also need to be considered in this document. As 229 connection-based network, there are specific parameters such as 230 reachable table, optical latency, wavelength consistency and some 231 other parameters that need to be included during the topology 232 collection. Without these restrictions, the path computation may be 233 inaccurate or infeasible for deployment, therefore these information 234 MUST be included in the PCEP. 236 The procedure on how the optical parameters are used is described in 237 following sections. 239 3.1. Reachable source-destination 241 The reachable source-destination node pair indicates that there are 242 a few number of OCh paths between two nodes. The reachability is 243 restricted by impairment, wavelength consistency and so on. This 244 information is necessary at PCE to promise the path computed between 245 source node and destination node is reachable. In this scenario, the 246 PCE should be responsible to compute how many OCh paths are 247 available to set up connections between source and destination node. 248 Moreover, if a set of optical wavelength is indicated in the path 249 computation request, the PCE should also determine whether a 250 wavelength of the set of preselected optical wavelength is available 251 for the source-destination pair connection. 253 To enable PCE to complete the above functions, the reachable 254 relationship and OMS link information need to be reported to PCE. 255 Once PCE detect that any wavelength is available, the corresponding 256 OMS link should be included in a lambda plane. Then this link can be 257 used for path computation in future. 259 Moreover, in a hierarchical PCE architecture, the information above 260 need to be reported from child PCE to parent PCE, who acts as a 261 service coordinator. 263 3.2. Optical latency 265 It is a usual case that the PCC indicates the latency when 266 requesting the path computation. In optical networks the latency is 267 a very sensitive parameter and there is stricter requirement on 268 latency. Given the maximal number of OCh paths between source- 269 destination nodes, the PCE also need to determine how many OCh path 270 satisfies the indicated latency threshold. 272 There is usually high-performance algorithm running on the PCE to 273 guarantee the performance of the computed path. During the 274 computation, the delay factor may be converted into a kind of link 275 weight. After the algorithm provides a few candidate paths between 276 the source and destination nodes, the PCE SHOULD be capable to 277 selecting one shortest path by computing the total path propagation 278 delay. 280 Optical PCEs are embedded with optimization algorithm, e.g., 281 shortest path algorithm, to improve the performance of computed 282 path. 284 4. PCEP-LS extension for Optical Networks 286 This section provides additional PCEP-LS extension necessary to 287 support optical networks. All Objects/TLVs defined in [PCEP-LS] are 288 applicable to optical networks. 290 4.1. Node Attributes TLV 292 Node-Attributed TLV is defined in Section 9.2.10.1 in [PCEP-LS] as 293 follows. This TLV is applicable for LS Node Object-Type as defined 294 in [PCEP-LS]. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 // Node Attributes Sub-TLVs (variable) // 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 The following 'Node Attribute' sub-TLVs are valid for optical 307 networks: 309 +-----------+------------------+--------------+-------------------+ 310 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference| 311 +-----------+------------------+--------------+---------+---------+ 312 | TBD | Connectivity | 5/14 | variable|[RFC7579]| 313 | | Matrix | | |[RFC7580]| 314 | TBD | Resource Block | 6/1 | variable|[RFC7688]| 315 | | Information | | | | 316 | TBD | Resource Block | 6/2 | variable|[RFC7688]| 317 | | Accessibility | | | | 318 | TBD | Resource Block | 6/3 | variable|[RFC7688]| 319 | | Wavelength Const | | | | 320 | TBD | Resource Block | 6/4 | variable|[RFC7688]| 321 | | Pool State | | | | 322 | TBD | Resource Block | 6/5 | variable|[RFC7688]| 323 | | Shared Access | | | | 324 | | Wavelength Avail.| | | | 325 +------------------------------------------------------=----------+ 327 4.2. Link Attributes TLV 329 Link-Attributes TLV is defined in Section 9.2.10.2 in [PCEP-LS] as 330 follows. This TLV is applicable for LS Link Object-Type as defined 331 in [PCEP-LS]. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 // Link Attributes Sub-TLVs (variable) // 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 The following 'Link Attribute' sub-TLVs are valid for optical 344 networks: 346 +-----------+-----------------+--------------+--------+----------+ 347 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference | 348 | | | | | | 349 +-----------+-----------------+--------------+--------+----------+ 350 | TBD | ISCD | 15 |Variable|[RFC4203] | 351 | | | | | | 352 | TBD | OTN-TDM SCSI | 15/1,2 |Variable|[RFC4203] | 353 | | | | |[RFC7138] | 354 | TBD | WSON-LSC SCSI | 15/1,2 |Variable|[RFC4203] | 355 | | | | |[RFC7688] | 356 | TBD | Flexi-grid SCSI | 15/1 |Variable|[RFC8363] | 357 | | | | | | 358 | TBD | Port Label | 34 |Variable|[RFC7579] | 359 | | Restriction | | |[RFC7580] | 360 | | | | |[RFC8363] | 361 +-----------+-----------------+--------------+--------+----------+ 363 4.3. PCEP-LS for Optical Network Extension 365 This section provides additional PCEP-LS extension necessary to 366 support optical networks parameters discussed in Sections 3.1 and 367 3.2. 369 The link state information collection is usually done before the 370 path computation processing. The procedure can be divided into 1) 371 link state collection by receiving the corresponding topology 372 information in a periodical style; 2) path computation on PCE, 373 triggered by receiving the path computation request message from 374 PCC, and completed by transmitting a path computation reply with the 375 path computation result, per [RFC4655]. 377 For OTN networks, max bandwidth available may be per ODU 0/1/2/3 378 switching level or aggregated across all ODU switching levels (i.e., 379 ODUj/k). 381 For WSON networks, RWA information collected from NEs would be 382 utilized to compute the light path. The list of information can be 383 found in [RFC7688]. More specifically, max bandwidth available may 384 be per lambda/frequency level (OCh) or aggregated across all 385 lambda/frequency level. Per OCh level abstraction gives more 386 detailed data to the P-PCE at the expense of more information 387 processing. Either OCh-level or aggregated level abstraction in the 388 RWA constraint (i.e., wavelength continuity) needs to be taken into 389 account by PCE during path computation. Resource Block Accessibility 390 (i.e., wavelength convert information) in [RFC7688] needs to be 391 taken into account in order to find a feasible optical path. 393 [Editor's Note: Encoding will be provided in the revision, including 394 RFC7688 RWA information] 396 5. Security Considerations 398 This document extends PCEP for LS (and TE) distribution including a 399 set of TLVs. Procedures and protocol extensions defined in this 400 document do not effect the overall PCEP security model. See 401 [RFC5440], [RFC8253]. The PCE implementation SHOULD provide 402 mechanisms to prevent strains created by network flaps and amount of 403 LS (and TE) information. Thus it is suggested that any mechanism 404 used for securing the transmission of other PCEP message be applied 405 here as well. As a general precaution, it is RECOMMENDED that these 406 PCEP extensions only be activated on authenticated and encrypted 407 sessions belonging to the same administrative authority. 409 6. IANA Considerations 411 This document requests IANA actions to allocate code points for the 412 protocol elements defined in this document. 414 6.1. PCEP-LS Sub-TLV Type Indicators 416 This document specifies a set of PCEP-LS Sub-TLVs. IANA is requested 417 to create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV 418 Type Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Node 419 Attributes TLV and Link Attributes TLV). 421 +-----------+------------------+--------------+----------+ 422 | Sub-TLV | Description | Ref Sub-TLV | Reference| 423 +-----------+------------------+--------------+----------+ 424 | TBD | Connectivity | 5/14 | [RFC7579]| 425 | | Matrix | | [RFC7580]| 426 | TBD | Resource Block | 6/1 | [RFC7688]| 427 | | Information | | | 428 | TBD | Resource Block | 6/2 | [RFC7688]| 429 | | Accessibility | | | 430 | TBD | Resource Block | 6/3 | [RFC7688]| 431 | | Wavelength Const | | | 432 | TBD | Resource Block | 6/4 | [RFC7688]| 433 | | Pool State | | | 434 | TBD | Resource Block | 6/5 | [RFC7688]| 435 | | Shared Access | | | 436 | | Wavelength Avail.| | | 437 | TBD | ISCD | 15 |[RFC4203] | 438 | | | | | 439 | TBD | OTN-TDM SCSI | 15/1,2 |[RFC4203] | 440 | | | |[RFC7138] | 441 | TBD | WSON-LSC SCSI | 15/1,2 |[RFC4203] | 442 | | | |[RFC7688] | 443 | TBD | Flexi-grid SCSI | 15/1 |[RFC8363] | 444 | | | | | 445 | TBD | Port Label | 34 |[RFC7579] | 446 | | Restriction | |[RFC7580] | 447 | | | |[RFC8363] | 448 +-----------+------------------+--------------+----------+ 450 7. References 452 7.1. Normative References 454 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 455 Computation Element (PCE)-Based Architecture", RFC 4655, 456 August 2006. 458 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 459 Element (PCE) Discovery", RFC 4674, October 2006. 461 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 462 Zhang, "OSPF Protocol Extensions for Path Computation 463 Element (PCE) Discovery", RFC 5088, January 2008. 465 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 466 Zhang, "IS-IS Protocol Extensions for Path Computation 467 Element (PCE) Discovery", RFC 5089, January 2008. 469 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 470 OSPF Opaque LSA Option", RFC 5250, July 2008. 472 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 473 Engineering", RFC 5305, October 2008. 475 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 476 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 477 March 2009. 479 7.2. Informative References 481 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 482 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 483 September 2003. 485 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 486 in Support of Generalized Multi-Protocol Label Switching 487 (GMPLS)", RFC 4203, October 2005. 489 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 490 Element (PCE)-Based Architecture", RFC 4655, August 2006. 492 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 493 S.Ray, "North-Bound Distribution of Link-State and TE 494 information using BGP", draft-ietf-idr-ls-distribution, 495 work in progress. 497 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 498 Protocol Extensions for Stateful PCE Usage in GMPLS- 499 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 500 gmpls, work in progress. 502 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 503 Computation Element Architecture", RFC 7399, October 2015. 505 [RFC7449] Y. Lee, G. Bernstein, "Path Computation Element 506 Communication Protocol (PCEP) Requirements for Wavelength 507 Switched Optical Network (WSON) Routing and Wavelength 508 Assignment", RFC 7449, February 2015. 510 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 511 Reflection: An Alternative to Full Mesh Internal BGP 512 (IBGP)", RFC 4456, April 2006. 514 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 515 and PCE Control of Wavelength Switched Optical Networks", 516 RFC 6163, 518 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 519 optical network elements, July 2007. 521 [RFC8345] D.Ceccarelli, and Y. Lee (Editors), "Framework for 522 Abstraction and Control of TE Networks", RFC8345, August, 523 2018. 525 [RFC6805] A. Farrel and D. King, "The Application of the Path 526 Computation Element Architecture to the Determination of a 527 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 528 2012. 530 [PCEP-LS-Arch] Y. Lee, D. Dhody and D. Ceccarelli, "Architecture and 531 Requirement for Distribution of Link-State and TE 532 Information via PCEP", draft-leedhody-teas-pcep-ls, work 533 in progress. 535 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 536 Distribution of Link-State and TE Information.", work in 537 progress, September 21, 2015 539 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 540 Extensions for Stateful PCE", RFC8231, September 2017. 542 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., 543 "PCEPS: Usage of TLS to Provide a Secure Transport for the 544 Path Computation Element Communication Protocol", RFC8253, 545 October 2017. 547 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 548 Extensions for PCE-initiated LSP Setup in a Stateful PCE 549 Model", RFC8281, December 2017. 551 [Stateful H-PCE] D. Dhody, Y. Lee and D. Ceccarelli, "Hierarchical 552 Stateful Path Computation Element (PCE)", draft-ietf-pce- 553 stateful-hpce, work-in-progress. 555 [RFC8363] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 556 Ceccarelli, "GMPLS OSPF Extensions in support of Flexi- 557 grid DWDM networks", RFC8363, May 2018. 559 Appendix A. Contributor Addresses 561 Dhruv Dhody 562 Huawei Technologies 563 Divyashree Techno Park, Whitefield 564 Bangalore, Karnataka 560066 565 India 566 Email: dhruv.ietf@gmail.com 568 Author's Addresses 570 Young Lee 571 Huawei Technologies 572 5340 Legacy Drive, Building 3 573 Plano, TX 75023, USA 575 Email: leeyoung@huawei.com 577 Haomian Zheng 578 Huawei Technologies Co., Ltd. 579 F3-1-B R&D Center, Huawei Base, 580 Bantian, Longgang District 581 Shenzhen 518129 P.R.China 583 Email: zhenghaomian@huawei.com 585 Daniele Ceccarelli 586 Ericsson 587 Torshamnsgatan,48 588 Stockholm 589 Sweden 591 EMail: daniele.ceccarelli@ericsson.com 593 Wei Wang 594 Beijing University of Posts and Telecom 595 No. 10, Xitucheng Rd. Haidian District, Beijing 100876, P.R.China 597 Email: weiw@bupt.edu.cn 599 Peter Park 600 KT 601 Email: peter.park@kt.com 603 Bin Yeong Yoon 604 ETRI 605 Email: byyun@etri.re.kr