idnits 2.17.1 draft-lee-pce-lsp-stitching-00.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 : ---------------------------------------------------------------------------- ** There are 41 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** 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 201: '...is new LSP-TYPE value MUST be set in a...' RFC 2119 keyword, line 204: '... turn, the C-PCE MUST return a Stitchi...' RFC 2119 keyword, line 208: '... new LSP-TYPE value MUST be set in the...' RFC 2119 keyword, line 211: '...s LSP-TYPE value MUST be used by the C...' RFC 2119 keyword, line 213: '...E. In turn, the PCC of domain(i) MUST...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2017) is 2498 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: 'Stateful-PCE' is mentioned on line 507, but not defined == Missing Reference: 'PCE-CC' is mentioned on line 117, but not defined == Missing Reference: 'BRPC-Stitch' is mentioned on line 226, but not defined == Missing Reference: 'ACTN' is mentioned on line 386, but not defined == Unused Reference: 'RFC4674' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'JMS' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'BGP-LS' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'S-PCE-GMPLS' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC7399' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC7449' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'G.680' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'ACTN-Frame' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'PCEP-LS-Arch' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'PCEP-LS' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'PCE-Initiated' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'FlexOSPF' is defined on line 521, 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 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-flexible-grid-ospf-ext-05 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-03 Summary: 9 errors (**), 0 flaws (~~), 27 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee 2 Dhruv Dhody 3 Internet Draft Huawei 4 Intended Status: Standard 5 Expires: November 2017 Daniele Ceccarelli 6 Ericsson 8 June 23, 2017 10 PCEP Extensions for Stitching LSPs in Hierarchical Stateful PCE 11 Model 13 draft-lee-pce-lsp-stitching-00.txt 15 Abstract 17 This document extends the Path Communication Element Communication 18 Protocol (PCEP) to coordinate an end-to-end inter-domain tunnel 19 setup over a multi-domain networks in the context of Hierarchical 20 Stateful PCE environments. This document uses Stitching Label (SL) 21 to stich per-domain LSPs. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on December 23, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Network Settings and concepts..................................4 64 2.1. Stateful H-PCE Stitching Procedure........................6 65 2.2. Applicability to ACTN....................................10 66 3. Security Considerations.......................................10 67 4. IANA Considerations...........................................10 68 5. References....................................................11 69 5.1. Normative References.....................................11 70 5.2. Informative References...................................11 71 Appendix A. Contributor Addresses................................14 72 Author's Addresses...............................................14 74 1. Introduction 76 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 77 (GMPLS), a Traffic Engineering Database (TED) is used in computing 78 paths for connection oriented packet services and for circuits. The 79 TED contains all relevant information that a Path Computation 80 Element (PCE) needs to perform its computations. It is important 81 that the TED should be complete and accurate anytime so that the PCE 82 can perform path computations. 84 In MPLS and GMPLS networks, Interior Gateway routing Protocols 85 (IGPs) have been used to create and maintain a copy of the TED at 86 each node. One of the benefits of the PCE architecture [RFC4655] is 87 the use of computationally more sophisticated path computation 88 algorithms and the realization that these may need enhanced 89 processing power not necessarily available at each node 90 participating in an IGP. 92 [Stateful-PCE] describes a set of extensions to PCEP to provide 93 stateful control. A stateful PCE has access to not only the 94 information carried by the network's Interior Gateway Protocol 95 (IGP), but also the set of active paths and their reserved resources 96 for its computations. PCC can delegate the rights to modify the LSP 97 parameters to an Active Stateful PCE. 99 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which 100 can be used for computing end-to-end paths for inter-domain MPLS 101 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). 102 Within the Hierarchical PCE (H-PCE) architecture [RFC6805], the 103 Parent PCE (P-PCE) is used to compute a multi-domain path based on 104 the domain connectivity information. A Child PCE (C-PCE) may be 105 responsible for a single domain or multiple domains, it is used to 106 compute the intra-domain path based on its domain topology 107 information. 109 [Stateful H-PCE] presents general considerations for stateful PCE(s) 110 in hierarchical PCE architecture. In particular, the behavior 111 changes and additions to the existing stateful PCE mechanisms 112 (including PCE-initiated LSP setup and active PCE usage) in the 113 context of networks using the H-PCE architecture. Section 3.3.1 of 114 [Stateful H-PCE] describe the per domain stitched LSP mode, where 115 the individual per domain LSP are stitched together. 117 [PCE-CC] introduces the architecture for PCE as a central 118 controller, and examines the motivations and applicability for PCEP 119 as a southbound interface. Section 2.1.3 describes the approach with 120 hierarchical controllers. 122 [BRPC-Stitch] describes how inter-domain labels over the inter- 123 domain interfaces are determined in the multi-domain BRPC-based PCE 124 environments. Further, the document introduces the concept of 125 Stitching Label (SL) and Inter-domain Path Setup Type [PST]. This 126 document also uses these concepts in the hierarchical Stateful PCE 127 model. 129 This document extends the Path Communication Element Communication 130 Protocol (PCEP) to coordinate an end-to-end tunnel for a virtual 131 network over multi-domain networks in the context of Hierarchical 132 Stateful PCE environments. 134 2. Network Settings and concepts 136 This section describes network settings for this draft. Figure 1 137 shows the context of Hierarchical Stateful PCE architecture where 138 multi-domain LSP stitching is required for an end-to-end tunnel 139 associated with a VN member. 141 +-----------+ 142 + Parent + 143 + PCE + 144 +-----------+ 145 . . . 146 . . . 147 . . . 148 . . . 149 Stateful +-----+ . +-----+ +-----+ 150 C-PCE for + PCE + + PCE + + PCE + 151 Domain A +-----+ Domain B +-----+ Domain C +-----+ 152 . . . 153 . . . 154 . . . 155 . . . 156 . . . 157 ___ ___ ___ 158 ( ) ( ) ( ) 159 ( o ) ( o ) ( o--o) 160 ( / \ ) ( |\ ) ( | | ) 161 EP1-------(o-o---o-o)==========(o-o-o-o-o)==========(o--o--o-o)--------EP2 162 |( \ / )| |( \ / )| |( | / )| 163 |( o )| |( o )| |( o-o )| 164 | (___) | | (___) | | (___) | 165 | | | | | | 166 |Domain |Inter-domain|Domain |Inter-domain|Domain | 167 | A | A-B | B | B-C | C | 168 |<----->|<---------->|<----->|<---------->|<------> 170 E2E Tunnel 171 <------------------------------------------------> 173 Figure 1: Multi-domain LSP stitching for an end-to-end tunnel 175 The draft provides PCE mechanisms to identify and isolate an end-to- 176 end tunnel for a virtual network by concatenating a set of 177 LSP/tunnel segments comprising an end-to-end tunnel. From Figure 1, 178 there are a set of segments comprising an end-to-end tunnel: Per 179 Domain LSP A, Inter-domain Link A-B, Per Domain LSP B, Inter-domain 180 Link B-C, and Per Domain C. 182 It is important to realize that this end-to-end tunnel for a virtual 183 network should be identifiable from other tunnels in the networks so 184 as to guarantee its performance objective associated with this 185 particular tunnel. See Section 2.2 for ACTN applicability for 186 detailed discussion on this aspect. 188 As per [BRPC-Stitch], Stitching Label (SL) is defined as a dedicated 189 label that is used to stitch two tunnels (RSVP-TE tunnels or Segment 190 Routing paths). This label is exchanged between exit BN(i) and entry 191 BN(i+1) via PCEP. In case of H-PCE, the SL is conveyed from entry 192 BN(i+1) to the child PCE(i+1) to the parent PCE, and then to child 193 PCE(i) to the entry BN(i). The exit BN(i) learns the SL via the per- 194 domain LSp setup technique (RSVP-TE, SR, PCECC etc). 196 [BRPC-Stitch] define new LSP setup types for BRPC mode, this 197 document also uses the same LSP setup type for the Stateful H-PCE 198 mode. 200 o TBD1: Inter-Domain Traffic engineering end-to-end path is 201 setup using H-PCE method. This new LSP-TYPE value MUST be set in a 202 PCInitiate messages sends by a P-PCE (Parent PCE) to its C-PCE 203 (child PCE) of transit and destination domains to initiate a new 204 inter-domain LSP tunnel. In turn, the C-PCE MUST return a Stitching 205 Label SL in the RRO of the PCRpt message to P-PCE. 207 o TBD2: Inter-Domain Traffic engineering local path is setup 208 using RSVP-TE. This new LSP-TYPE value MUST be set in the 209 PCInitiate message sends by a C-PCE(i) requesting to a PCC of 210 domain(i) to initiate a new local LSP tunnel(i) which is part of an 211 inter-domain LSP tunnel. This LSP-TYPE value MUST be used by the C- 212 PCE(i) only after receiving a PCInitiate message with an LSP-TYPE 213 equal to TBD1 from a P-PCE. In turn, the PCC of domain(i) MUST 214 return a Stitching Label SL in the RRO of the PCRpt message. 216 o TBD3: Inter-Domain Traffic engineering local path is setup 217 using Segment Routing (SR). This new LSP-TYPE value MUST be set in 218 the PCInitiate message sends by a C-PCE(i) requesting to a PCC of 219 domain(i) to initiate a new Segment Routing path which is part of 220 an inter-domain Segment Routing path. This LSP-TYPE value MUST be 221 used by the C-PCE(i) only after receiving a PCInitiate message with 222 an LSP-TYPE equal to TBD1 from a P-PCE. In turn, the PCC MUST 223 return a Stitching Label SL in the RRO of the PCRpt message. 225 [Editor's Note - This draft authors plan to discuss with authors of 226 [BRPC-Stitch] to simplify this, as any new path setup type like 227 PCECC would require another path-setup type to be defined here.] 229 Thus, these LSP-TYPE value MUST be set in PCEP messages sends by a 230 Parent PCE to child PCE as well as between child PCE and the PCCs 231 when SL is used. 233 2.1. Stateful H-PCE Stitching Procedure 235 Taking the sample hierarchical domain topology example from 236 [RFC6805] as the reference topology for the entirety of this 237 document. 239 ----------------------------------------------------------------- 240 | Domain 5 | 241 | ----- | 242 | |PCE 5| | 243 | ----- | 244 | | 245 | ---------------- ---------------- ---------------- | 246 | | Domain 1 | | Domain 2 | | Domain 3 | | 247 | | | | | | | | 248 | | ----- | | ----- | | ----- | | 249 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 250 | | ----- | | ----- | | ----- | | 251 | | | | | | | | 252 | | ----| |---- ----| |---- | | 253 | | |BN11+---+BN21| |BN23+---+BN31| | | 254 | | - ----| |---- ----| |---- - | | 255 | | |S| | | | | |D| | | 256 | | - ----| |---- ----| |---- - | | 257 | | |BN12+---+BN22| |BN24+---+BN32| | | 258 | | ----| |---- ----| |---- | | 259 | | | | | | | | 260 | | ---- | | | | ---- | | 261 | | |BN13| | | | | |BN33| | | 262 | -----------+---- ---------------- ----+----------- | 263 | \ / | 264 | \ ---------------- / | 265 | \ | | / | 266 | \ |---- ----| / | 267 | ----+BN41| |BN42+---- | 268 | |---- ----| | 269 | | | | 270 | | ----- | | 271 | | |PCE 4| | | 272 | | ----- | | 273 | | | | 274 | | Domain 4 | | 275 | ---------------- | 276 | | 277 ----------------------------------------------------------------- 279 Section 3.3.1 of [Stateful H-PCE] describes the per-domain stitched 280 LSP mode and list all the steps needed. To support SL based 281 stitching, the steps are modified as follows - 283 Using the reference architecture described in Figure above: 285 (1) The P-PCE (PCE5) is requested to initiate a LSP. 287 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to 288 determine the end to end path, which are broken into per-domain LSPs 289 say - 291 o S-BN41 293 o BN41-BN33 295 o BN33-D 297 For LSP (BN33-D) 299 (2) The P-PCE (PCE5) sends the initiate request to the child PCE 300 (PCE3) via PCInitiate message for LSP (BN33-D) with ERO=(BN33..D) 301 and LSP-TYPE=TBD1. 303 (3) The PCE3 further propagates the initiate message to BN33 with 304 the ERO and LSP-TYPE=TBD2/TBD3 based on setup type. 306 (4) BN33 initiates the setup of the LSP as per the path and reports 307 to the PCE3 the LSP status ("GOING-UP"). 309 (5) The PCE3 further reports the status of the LSP to the P-PCE 310 (PCE5). 312 (6) The node BN33 notifies the LSP state to PCE3 when the state is 313 "UP" it also carry the stitching label (SL33) in RRO as 314 (SL33,BN33..D). 316 (7) The PCE3 further reports the status of the LSP to the P-PCE 317 (PCE5) as well as carry the stitching label (SL33) in RRO as 318 (SL33,BN33..D). 320 For LSP (BN41-BN33) 322 (8) The P-PCE (PCE5) sends the initiate request to the child PCE 323 (PCE4) via PCInitiate message for LSP (BN41-BN33) with 324 ERO=(BN41..BN42,SL33,BN33) and LSP-TYPE=TBD1. 326 (9) The PCE4 further propagates the initiate message to BN41 with 327 the ERO and LSP-TYPE=TBD2/TBD3 based on setup type. In case of 328 RSVP_TE, the node BN41 encode the stitching label SL33 as part of 329 the ERO to make sure the node BN42 uses the label SL33 towards node 330 BN33. In case of SR, the label SL33 is part of the label stack 331 pushed at node BN41. 333 (10) BN41 initiates the setup of the LSP as per the path and reports 334 to the PCE4 the LSP status ("GOING-UP"). 336 (11) The PCE4 further reports the status of the LSP to the P-PCE 337 (PCE5). 339 (l2) The node BN41 notifies the LSP state to PCE4 when the state is 340 "UP" it also carry the stitching label (SL41) in RRO as 341 (SL41,BN41..BN33). 343 (13) The PCE4 further reports the status of the LSP to the P-PCE 344 (PCE5) as well as carry the stitching label (SL41) in RRO as 345 (SL41,BN41..BN33). 347 For LSP (S-BN41) 349 (14) The P-PCE (PCE5) sends the initiate request to the child PCE 350 (PCE1) via PCInitiate message for LSP (S-BN41) with 351 ERO=(S..BN13,SL41,BN41). 353 (15) The PCE1 further propagates the initiate message to node S 354 with the ERO. In case of RSVP_TE, the node S encode the stitching 355 label SL41 as part of the ERO to make sure the node BN13 uses the 356 label SL41 towards node BN41. In case of SR, the label SL41 is part 357 of the label stack pushed at node S. 359 (16) S initiates the setup of the LSP as per the path and reports 360 to the PCE1 the LSP status ("GOING-UP"). 362 (17) The PCE1 further reports the status of the LSP to the P-PCE 363 (PCE5). 365 (18) The node S notifies the LSP state to PCE1 when the state 366 is"UP". 368 (19) The PCE1 further reports the status of the LSP to the P-PCE 369 (PCE5). 371 In this way, per-domain LSP are stitched together using the 372 stitching label (SL). The per-domain LSP MUST be setup from the 373 destination domain towards the source domain one after the other. 375 Once the per-domain LSP is setup, the entry BN chooses a free label 376 for the Stitching Label SL and add a new entry in its MPLS LFIB with 377 this SL label. The SL from the destination domain is propagated to 378 adjacent transit domain, towards the source domain at each step. 379 This happens through the entry BN to C-PCE to the P-PCE and vice- 380 versa. In case of RSVP-TE, the entry BN further propagates the SL 381 label to the exit BN via RSVP-TE. In case of SR, the SL label is 382 pushed as part of the SR label stack. 384 2.2. Applicability to ACTN 386 [ACTN] describes framework for Abstraction and Control of TE 387 Networks (ACTN), where each Physical Network Controller (PNC) is 388 equivalent to C-PCE and P-PCE is the Multi-Domain Service 389 Coordinator (MDSC). The Per domain stitched LSP as per the 390 Hierarchical PCE architecture described in Section 3.3.1 and Section 391 4.1 of [Stateful H-PCE] is well suited for ACTN. 393 The stitching label (SL) mechanism as described in this document is 394 well suited for ACTN when per domain LSP needs to be stitched to 395 form an E2E tunnel or a VN Member. It is to be noted that certain 396 VNs require isolation from other clients. The stitching label 397 mechanism described in this document can be applicable to the VN 398 isolation use-case by uniquely identifying the concatenated 399 stitching labels across multi-domain only to a certain VN member or 400 an E2E tunnel. 402 3. Security Considerations 404 Procedures and protocol extensions defined in this document do not 405 effect the overall PCEP security model. See [RFC5440], [I-D.ietf- 406 pce-pceps]. It is suggested that any mechanism used for securing the 407 transmission of other PCEP message be applied here as well. As a 408 general precaution, it is RECOMMENDED that these PCEP extensions 409 only be activated on authenticated and encrypted sessions belonging 410 to the same administrative authority. 412 4. IANA Considerations 414 This document requests IANA actions to allocate code points for the 415 protocol elements defined in this document. 417 5. References 419 5.1. Normative References 421 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 422 Computation Element (PCE)-Based Architecture", RFC 4655, 423 August 2006. 425 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 426 Element (PCE) Discovery", RFC 4674, October 2006. 428 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 429 Zhang, "OSPF Protocol Extensions for Path Computation 430 Element (PCE) Discovery", RFC 5088, January 2008. 432 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 433 Zhang, "IS-IS Protocol Extensions for Path Computation 434 Element (PCE) Discovery", RFC 5089, January 2008. 436 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 437 OSPF Opaque LSA Option", RFC 5250, July 2008. 439 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 440 Engineering", RFC 5305, October 2008. 442 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 443 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 444 March 2009. 446 5.2. Informative References 448 [JMS] Java Message Service, Version 1.1, April 2002, Sun 449 Microsystems. 451 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 452 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 453 September 2003. 455 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 456 in Support of Generalized Multi-Protocol Label Switching 457 (GMPLS)", RFC 4203, October 2005. 459 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 460 Element (PCE)-Based Architecture", RFC 4655, August 2006. 462 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 463 S.Ray, "North-Bound Distribution of Link-State and TE 464 information using BGP", draft-ietf-idr-ls-distribution, 465 work in progress. 467 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 468 Protocol Extensions for Stateful PCE Usage in GMPLS- 469 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 470 gmpls, work in progress. 472 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 473 Computation Element Architecture", RFC 7399, October 2015. 475 [RFC7449] Y. Lee, G. Bernstein, "Path Computation Element 476 Communication Protocol (PCEP) Requirements for Wavelength 477 Switched Optical Network (WSON) Routing and Wavelength 478 Assignment", RFC 7449, February 2015. 480 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 481 Reflection: An Alternative to Full Mesh Internal BGP 482 (IBGP)", RFC 4456, April 2006. 484 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 485 and PCE Control of Wavelength Switched Optical Networks", 486 RFC 6163, 488 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 489 optical network elements, July 2007. 491 [ACTN-Frame] D.Ceccarelli, and Y. Lee (Editors), "Framework for 492 Abstraction and Control of TE Networks", draft-ietf-teas- 493 actn-framework, work in progress. 495 [RFC6805] A. Farrel and D. King, "The Application of the Path 496 Computation Element Architecture to the Determination of a 497 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 498 2012. 500 [PCEP-LS-Arch] Y. Lee, D. Dhody and D. Ceccarelli, "Architecture and 501 Requirement for Distribution of Link-State and TE 502 Information via PCEP", draft-leedhody-teas-pcep-ls, work 503 in progress. 505 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 506 Distribution of Link-State and TE Information.", work in 507 progress, September 21, 2015[Stateful-PCE] Crabbe, E., 508 Minei, I., Medved, J., and R. Varga, "PCEP Extensions for 509 Stateful PCE", draft-ietf-pce-stateful-pce, work in 510 progress. 512 [PCE-Initiated] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, 513 "PCEP Extensions for PCE-initiated LSP Setup in a Stateful 514 PCE Model", draft-ietf-pce-pce-initiated-lsp, work in 515 progress. 517 [Stateful H-PCE] D. Dhody, Y. Lee and D. Ceccarelli, "Hierarchical 518 Stateful Path Computation Element (PCE)", draft-ietf-pce- 519 stateful-hpce, work-in-progress. 521 [FlexOSPF] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 522 Ceccarelli, "GMPLS OSPF Extensions in support of Flexi- 523 grid DWDM networks", draft-ietf-ccamp-flexible-grid-ospf- 524 ext-05, work in progress. 526 [PST] Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga, 527 R., Tantsura, J., and J. Hardwick, "Conveying path setup 528 type in PCEP messages", draft-ietf-pce-lsp-setup-type-03 529 work in progress. 531 Appendix A. Contributor Addresses 533 Author's Addresses 535 Young Lee 536 Huawei Technologies 537 5340 Legacy Drive, Building 3 538 Plano, TX 75023, USA 540 Email: leeyoung@huawei.com 542 Dhruv Dhody 543 Huawei Technologies 544 Divyashree Techno Park, Whitefield 545 Bangalore, Karnataka 560066 546 India 547 Email: dhruv.ietf@gmail.com 549 Daniele Ceccarelli 550 Ericsson 551 Torshamnsgatan,48 552 Stockholm 553 Sweden 555 Email: daniele.ceccarelli@ericsson.com