idnits 2.17.1 draft-ietf-teas-gmpls-resource-sharing-proc-04.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 (February 10, 2016) is 2998 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group X. Zhang 3 Internet-Draft H. Zheng, Ed. 4 Intended Status: Informational Huawei 5 Expires: August 13, 2016 R. Gandhi, Ed. 6 Z. Ali 7 G. Galimberti 8 Cisco Systems, Inc. 9 P. Brzozowski 10 ADVA Optical 11 February 10, 2016 13 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and 14 Resource Sharing 15 draft-ietf-teas-gmpls-resource-sharing-proc-04 17 Abstract 19 In transport networks, there are requirements where Generalized 20 Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme 21 needs to employ restoration Label Switched Path (LSP) while keeping 22 resources for the working and/or protecting LSPs reserved in the 23 network after the failure occurs. 25 This document reviews how the LSP association is to be provided using 26 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 27 signaling in the context of GMPLS end-to-end recovery scheme when 28 using restoration LSP where failed LSP is not torn down. In 29 addition, this document discusses resource sharing-based setup and 30 teardown of LSPs as well as LSP reversion procedures for transport 31 networks. No new signaling extensions are defined by this document, 32 and it is strictly informative in nature. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 75 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 76 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 77 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 7 78 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 7 79 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 80 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9 81 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9 82 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 10 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines 94 a set of protocols, including Open Shortest Path First - Traffic 95 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 96 Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used 97 to setup Label Switched Paths (LSPs) in transport networks. The 98 GMPLS protocol extends MPLS to support interfaces capable of Time 99 Division Multiplexing (TDM), Lambda Switching and Fiber Switching. 100 These switching technologies provide several protection schemes 101 [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). 103 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 104 signaling has been extended to support various GMPLS recovery 105 schemes, such as end-to-end recovery [RFC4872] and segment recovery 106 [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used 107 to identify the LSPs for restoration using Association Type set to 108 "Recovery" [RFC4872] and also identify the LSPs for resource sharing 109 using Association Type set to "Resource Sharing" [RFC4873]. 110 [RFC6689] Section 2.2 reviews the procedure for providing LSP 111 associations for GMPLS end-to-end recovery and Section 2.4 reviews 112 the procedure for providing LSP associations for sharing resources. 114 In GMPLS end-to-end recovery schemes generally considered, 115 restoration LSP is signaled after the failure has been detected and 116 notified on the working LSP. For revertive recovery mode, a 117 restoration LSP is signaled while working LSP and/or protecting LSP 118 are not torn down in control plane due to a failure. In transport 119 networks, as working LSPs are typically signaled over a nominal path, 120 service providers would like to keep resources associated with the 121 working LSPs reserved. This is to make sure that the service 122 (working LSP) can be reverted to the nominal path when the failure is 123 repaired to provide deterministic behavior and guaranteed Service 124 Level Agreement (SLA). 126 In this document, procedures for transport networks are reviewed for 127 LSP associations, resource sharing based LSP setup, teardown and LSP 128 reversion, including following: 130 o Review the procedure for providing LSP associations for the GMPLS 131 end-to-end recovery using restoration LSP where working and 132 protecting LSPs are not torn down and resources are kept reserved in 133 the network after the failure. 135 o In [RFC3209], the make-before-break (MBB) method assumes the old 136 and new LSPs share the SESSION object and signal Shared Explicit (SE) 137 flag in SESSION_ATTRIBUTE object for sharing resources. According to 139 [RFC6689], ASSOCIATION object with Association Type "Resource 140 Sharing" enables the sharing of resources across LSPs with different 141 SESSION objects. Procedure for resource sharing using the SE flag in 142 conjunction with ASSOCIATION object is discussed in this document. 144 o When using end-to-end recovery with revertive mode, methods for 145 LSP reversion and resource sharing are summarized in this document. 147 This document is strictly informative in nature and does not define 148 any RSVP-TE signaling extensions. 150 2. Overview 152 The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and 153 being considered in this document, "fully dynamic rerouting switches 154 normal traffic to an alternate LSP that is not even partially 155 established only after the working LSP failure occurs. The new 156 alternate route is selected at the LSP head-end node, it may reuse 157 resources of the failed LSP at intermediate nodes and may include 158 additional intermediate nodes and/or links". Two examples, 1+R and 159 1+1+R are described in the following sections. 161 2.1. 1+R Restoration 163 One example of the recovery scheme considered in this document is 1+R 164 recovery. The 1+R recovery is exemplified in Figure 1. In this 165 example, working LSP on path A-B-C-Z is pre-established. Typically 166 after a failure detection and notification on the working LSP, a 167 second LSP on path A-H-I-J-Z is established as a restoration LSP. 168 Unlike protection LSP, restoration LSP is signaled per need basis. 170 +-----+ +-----+ +-----+ +-----+ 171 | A +----+ B +-----+ C +-----+ Z | 172 +--+--+ +-----+ +-----+ +--+--+ 173 \ / 174 \ / 175 +--+--+ +-----+ +--+--+ 176 | H +-------+ I +--------+ J | 177 +-----+ +-----+ +-----+ 179 Figure 1: An Example of 1+R Recovery Scheme 181 During failure switchover with 1+R recovery scheme, in general, 182 working LSP resources are not released so that working and 183 restoration LSPs coexist in the network. Nonetheless, working and 184 restoration LSPs can share network resources. Typically when failure 185 is recovered on the working LSP, restoration LSP is no longer 186 required and torn down, while the traffic is reverted to the original 187 working LSP. 189 2.2. 1+1+R Restoration 191 Another example of the recovery scheme considered in this document is 192 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 193 and/or the protecting LSP after the failure has been detected, and 194 this recovery is exemplified in Figure 2. 196 +-----+ +-----+ +-----+ 197 | D +-------+ E +--------+ F | 198 +--+--+ +-----+ +--+--+ 199 / \ 200 / \ 201 +--+--+ +-----+ +-----+ +--+--+ 202 | A +----+ B +-----+ C +-----+ Z | 203 +--+--+ +-----+ +-----+ +--+--+ 204 \ / 205 \ / 206 +--+--+ +-----+ +--+--+ 207 | H +-------+ I +--------+ J | 208 +-----+ +-----+ +-----+ 210 Figure 2: An Example of 1+1+R Recovery Scheme 212 In this example, working LSP on path A-B-C-Z and protecting LSP on 213 path A-D-E-F-Z are pre-established. After a failure detection and 214 notification on a working LSP or protecting LSP, a third LSP on path 215 A-H-I-J-Z is established as a restoration LSP. The restoration LSP 216 in this case provides protection against a second order failure. 217 During failure switchover with 1+1+R recovery scheme, in general, 218 failed LSP resources are not released so that working, protecting and 219 restoration LSPs coexist in the network. Nonetheless, restoration 220 LSP with working LSP it is restoring as well as restoration LSP with 221 protecting LSP it is restoring can share network resources. 222 Typically, restoration LSP is torn down when the failure on the 223 original (working or protecting) LSP is repaired and the traffic is 224 reverted to the original LSP. 226 There are four possible models when using restoration LSP with 1+1+R 227 recovery scheme: 229 o A restoration LSP is signaled after either working or protecting 230 LSP fails. Only one restoration LSP is present at a time. 232 o A restoration LSP is signaled after either working or protecting 233 LSP fails. Two different restoration LSPs may be present, one for 234 the working LSP and one for the protecting LSP. 236 o A restoration LSP is signaled after both working and protecting 237 LSPs fail. Only one restoration LSP is present. 239 o Two different restoration LSPs are signaled after both working and 240 protecting LSPs fail, one for the working LSP and one for the 241 protecting LSP. 243 In all models discussed, if the restoration LSP also fails, it is 244 torn down and a new restoration LSP is signaled. 246 2.3. Resource Sharing By Restoration LSP 248 +-----+ +-----+ 249 | F +------+ G +--------+ 250 +--+--+ +-----+ | 251 | | 252 | | 253 +-----+ +-----+ +--+--+ +-----+ +--+--+ 254 | A +----+ B +-----+ C +--X---+ D +-----+ E | 255 +-----+ +-----+ +-----+ +-----+ +-----+ 257 Figure 3: Resource Sharing in 1+R Recovery Scheme 259 Using the network shown in Figure 3 as an example, LSP1 (A-B-C-D-E) 260 is the working LSP and it allows for resource sharing when the LSP 261 traffic is dynamically restored after the link failure. Upon 262 detecting the failure of a link along the LSP1, e.g. Link C-D, node A 263 needs to decide which alternative path it will use to signal 264 restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is 265 chosen as the restoration LSP path and the resources on the path 266 segment A-B-C are re-used by this LSP when the working LSP is not 267 torn down (e.g. in 1+R recovery scheme). 269 3. RSVP-TE Signaling Procedure 271 3.1. Restoration LSP Association 273 Where GMPLS end-to-end recovery scheme needs to employ a restoration 274 LSP while keeping resources for the working and/or protecting LSPs 275 reserved in the network after the failure, the restoration LSP is 276 signaled with an ASSOCIATION object that has Association Type set to 277 "Recovery" [RFC4872], the Association ID and the Association Source 278 set to the corresponding Association ID and the Association Source 279 signaled in the LSP it is restoring. For example, when a restoration 280 LSP is signaled for a failed working LSP, the ASSOCIATION object in 281 the restoration LSP contains the Association ID and Association 282 Source set to the Association ID and Association Source signaled in 283 the working LSP for the "Recovery" Association Type. Similarly, when 284 a restoration LSP is signaled for a failed protecting LSP, the 285 ASSOCIATION object in the restoration LSP contains the Association ID 286 and Association Source set to the Association ID and Association 287 Source signaled in the protecting LSP for the "Recovery" Association 288 Type. 290 The procedure for signaling the PROTECTION object is specified in 291 [RFC4872]. Specifically, the restoration LSP used for a working LSP 292 is signaled with P bit cleared in the PROTECTION object and the 293 restoration LSP used for a protecting LSP is signaled with P bit set 294 in the PROTECTION object. 296 3.2. Resource Sharing-based Restoration LSP Setup 298 GMPLS LSPs can share resources during LSP setup if they have Shared 299 Explicit (SE) flag set in their SESSION_ATTRIBUTE objects and: 301 o As defined in [RFC3209], LSPs have identical SESSION objects 302 and/or 304 o As defined in [RFC6689], LSPs have matching ASSOCIATION object 305 with Association Type set to "Resource Sharing". LSPs in this case 306 can have different SESSION objects i.e. different Tunnel ID, Source 307 and/or Destination. 309 As described in [RFC3209], Section 2.5, the purpose of make-before- 310 break is "not to disrupt traffic, or adversely impact network 311 operations while TE tunnel rerouting is in progress". In transport 312 networks, the label has a mapping into the data plane resource used 313 and the nodes along the LSP need to send triggering commands to data 314 plane for setting up cross-connections accordingly during the RSVP-TE 315 signaling procedure. Due to the nature of the transport networks, 316 node may not be able to fulfill this purpose when sharing resources 317 in some scenarios. 319 For LSP restoration upon failure, as explained in Section 11 of 320 [RFC4872], reroute procedure may re-use existing resources. The 321 behavior of the intermediate nodes during rerouting process to 322 reconfigure cross-connections does not further impact the traffic 323 since it has been interrupted due to the already failed LSP. 325 The node behavior for setting up the restoration LSP can be 326 categorized into the following three categories: 328 Table 1: Node Behavior during Restoration LSP Setup 330 ---------+--------------------------------------------------------- 331 Category | Node Behavior during Restoration LSP Setup 332 ---------+--------------------------------------------------------- 333 C1 + Reusing existing resource on both input and output 334 + interfaces (node A & B in Figure 3). 335 + 336 + This type of nodes only needs to book the existing 337 + resources and no cross-connection setup 338 + command is needed. 339 ---------+--------------------------------------------------------- 340 C2 + Reusing existing resource only on one of the interfaces, 341 + either input or output interfaces and need to use new 342 + resource on the other interface. (node C & E in Figure 3). 343 + 344 + This type of nodes needs to book the resources and send 345 + the re-configuration cross-connection command to its 346 + corresponding data plane node on the interfaces where new 347 + resources are needed and re-use the 348 + existing resources on the other interfaces. 349 ---------+--------------------------------------------------------- 350 C3 + Using new resources on both interfaces. 351 + (node F & G in Figure 3). 352 + 353 + This type of nodes needs to book the new resources 354 + and send the cross-connection setup 355 + command on both interfaces. 356 ---------+--------------------------------------------------------- 358 Depending on whether the resource is re-used or not, the node 359 behaviors differ. This deviates from normal LSP setup since some 360 nodes do not need to re-configure the cross-connection, and it should 361 not be viewed as an error. Also, the judgment whether the control 362 plane node needs to send a cross-connection setup/modification 363 command to its corresponding data plane node(s) relies on the check 364 whether the LSPs are sharing resources. 366 3.3. LSP Reversion 368 If the end-to-end LSP recovery is revertive, as described in Section 369 2, traffic can be reverted from the restoration LSP to the working or 370 protecting LSP after its failure is recovered. The LSP reversion can 371 be achieved using two methods: 373 1. Make-while-break Reversion, where resources associated with 374 working or protecting LSP are reconfigured while removing 375 reservations for the restoration LSP. 377 2. Make-before-break Reversion, where resources associated with 378 working or protecting LSP are reconfigured before removing 379 reservations for the restoration LSP. 381 In transport networks, both of the above reversion methods will 382 result in some traffic disruption when the restoration LSP and the 383 LSP being restored are sharing resources and the cross-connections 384 need to be reconfigured on intermediate nodes. 386 3.3.1. Make-while-break Reversion 388 In this reversion method, restoration LSP is simply requested to be 389 deleted by the head-end. Removing reservations for restoration LSP 390 triggers reconfiguration of resources associated with working or 391 protecting LSP on every node where resources are shared. Whenever 392 reservation for restoration LSP is removed from a node, data plane 393 configuration changes to reflect reservations of working or 394 protection LSP as signaling progresses. Eventually, after the whole 395 restoration LSP is deleted, data plane configuration will fully match 396 working or protecting LSP reservations on the whole path. Thus 397 reversion is complete. 399 Make-while-break, while being relatively simple in its logic, has few 400 limitations as follows which may not be acceptable in some networks: 402 o No rollback 404 Deletion of restoration LSPs is not a revertive process. If for some 405 reason reconfiguration of data plane on one of the nodes to match 406 working or protection LSP reservations fails, falling back to 407 restoration LSP is no longer an option, as its state might have 408 already been removed from other nodes. 410 o No completion guarantee 412 Deletion of an LSP provides no guarantees of completion. In 413 particular, if RSVP packets are lost due to nodal or DCN failures it 414 is possible for an LSP to be only partially deleted. To mitigate 415 this, RSVP could maintain soft state reservations and hence 416 eventually remove remaining reservations due to refresh timeouts. 417 This approach is not feasible in transport networks however, where 418 control and data channels are often separated and hence soft state 419 reservations are not useful. 421 Finally, one could argue that graceful LSP deletion [RFC3473] would 422 provide guarantee of completion. While this is true for most cases, 423 many implementations will time out graceful deletion if LSP is not 424 removed within certain amount of time, e.g. due to a transit node 425 fault. After that, deletion procedures which provide no completion 426 guarantees will be attempted. Hence, in corner cases completion 427 guarantee cannot be provided. 429 o No explicit notification of completion to head-end node 431 In some cases, it may be useful for a head-end node to know when the 432 data plane has been reconfigured to match working or protection LSP 433 reservations. This knowledge could be used for initiating operations 434 like enabling alarm monitoring, power equalization and others. 435 Unfortunately, for the reasons mentioned above, make-while-break 436 reversion lacks such explicit notification. 438 3.3.2. Make-before-break Reversion 440 This reversion method can be used to overcome limitations of 441 make-while-break reversion. It is similar in spirit to MBB concept 442 used for re-optimization. Instead of relying on deletion of 443 restoration LSP, head-end chooses to establish a new LSP to 444 reconfigure resources on the working or protection LSP path, and uses 445 identical ASSOCIATION and PROTECTION objects from the LSP it is 446 replacing. Only if setup of this LSP is successful will other 447 (restoration and working/protecting) LSPs be deleted by the head-end. 448 MBB reversion consists of two parts: 450 A) Make part: 452 Creating a new reversion LSP following working or protection LSP's 453 path. Reversion LSP is sharing resources both with working and 454 restoration LSPs. As reversion LSP is created, resources are 455 reconfigured to match its reservations. Hence, after reversion LSP 456 is created, data plane configuration essentially reflects working or 457 protecting LSP reservations. 459 B) Break part: 461 After "make" part is finished, working and restoration LSPs are torn 462 down. Removing reservations for working and restoration LSPs does 463 not cause any resource reconfiguration on reversion LSP's path - 464 nodes follow same procedures as for "break" part of any MBB 465 operation. Hence, after working and restoration LSPs are removed, 466 data plane configuration is exactly the same as before starting 467 restoration. Thus, reversion is complete. 469 MBB reversion uses make-before-break characteristics to overcome 470 challenges related to make-while-break reversion as follow: 472 o Rollback 474 If "make" part fails, (existing) restoration LSP will still be used 475 to carry existing traffic. Same logic applies here as for any MBB 476 operation failure. 478 o Completion guarantee 480 LSP setup is resilient against RSVP message loss, as Path and Resv 481 messages are refreshed periodically. Hence, given that network 482 recovers its DCN eventually, reversion LSP setup is guaranteed to 483 finish with either success or failure. 485 o Explicit notification of completion to head-end node 487 Head-end knows that data plane has been reconfigured to match working 488 or protection LSP reservations on intermediate nodes when it receives 489 Resv for the reversion LSP. 491 4. Security Considerations 493 This document reviews procedures defined in [RFC3209] [RFC4872] 494 [RFC4873] and [RFC6689] and does not define any new procedure. This 495 document does not introduce any new security issues other than those 496 already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 498 5. IANA Considerations 500 This informational document does not make any request for IANA 501 action. 503 6. References 505 6.1. Normative References 507 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 508 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 509 Tunnels", RFC 3209, December 2001. 511 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 512 Switching (GMPLS) Signaling Resource ReserVation 513 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 514 3473, January 2003. 516 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 517 Ed., "RSVP-TE Extensions in Support of End-to-End 518 Generalized Multi-Protocol Label Switching (GMPLS) 519 Recovery", RFC 4872, May 2007. 521 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 522 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 524 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 525 6689, July 2012. 527 6.2. Informative References 529 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 530 (GMPLS) Architecture", RFC 3945, October 2004. 532 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 533 Support of Generalized Multi-Protocol Label Switching 534 (GMPLS)", RFC 4203, October 2005. 536 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 537 "Generalized Multiprotocol Label Switching (GMPLS) 538 Recovery Functional Specification", RFC 4426, March 2006. 540 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 541 and Restoration) Terminology for Generalized 542 Multi-Protocol Label Switching", RFC 4427, March 2006. 544 Acknowledgements 546 The authors would like to thank George Swallow for the discussions 547 on the GMPLS restoration. The authors would also like to thank 548 Lou Berger for the review comments and the guidance on this work. 550 Authors' Addresses 552 Xian Zhang 553 Huawei Technologies 554 F3-1-B R&D Center, Huawei Base 555 Bantian, Longgang District 556 Shenzhen 518129 P.R.China 558 EMail: zhang.xian@huawei.com 560 Haomian Zheng (editor) 561 Huawei Technologies 562 F3-1-B R&D Center, Huawei Base 563 Bantian, Longgang District 564 Shenzhen 518129 P.R.China 566 EMail: zhenghaomian@huawei.com 568 Rakesh Gandhi (editor) 569 Cisco Systems, Inc. 571 EMail: rgandhi.ietf@gmail.com 573 Zafar Ali 574 Cisco Systems, Inc. 576 EMail: zali@cisco.com 578 Gabriele Maria Galimberti 579 Cisco Systems, Inc. 581 EMail: ggalimbe@cisco.com 583 Pawel Brzozowski 584 ADVA Optical 586 EMail: PBrzozowski@advaoptical.com