idnits 2.17.1 draft-ram-l2vpn-etree-multiple-pw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 abstract seems to contain references ([RFC4761], [RFC4762], [RFC6074]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 5, 2012) is 4433 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) == Missing Reference: 'RFC 4762' is mentioned on line 210, but not defined == Missing Reference: 'RFC 4761' is mentioned on line 340, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rafi Ram, Orckit-Corrigent 2 Internet Draft Daniel Cohn, Orckit-Corrigent 3 Category: Standard Track Raymond Key, Huawei 4 P. Agarwal, Broadcom 5 Yuqun (Sam) Cao, Ruijie Networks 6 Expires: September 5, 2012 Josh Rogers, TW Cable 8 Mar 5, 2012 10 Extension to VPLS for E-Tree Using Multiple PWs 11 draft-ram-l2vpn-etree-multiple-pw-01 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to publish it 26 as an RFC and to translate it into languages other than English. 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 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire in September 5, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 Abstract 60 This document proposes a solution for Metro Ethernet Forum (MEF) 61 Ethernet Tree (E-Tree) support in Virtual Private LAN Service using 62 LDP Signaling (LDP-VPLS) [RFC4762],BGP signaling (BGP-VPLS) [RFC4761] 63 or BGP auto-discovery (BGP-AD) [RFC6074]. The proposed solution is 64 characterized by the use of two PWs between a pair of PEs. This 65 solution is applicable for both VPLS and H-VPLS. 67 Table of Contents 69 1. Introduction ................................................... 3 70 2. Conventions used in this document............................... 3 71 3. The Problem .................................................... 4 72 4. The 2-PW Solution .............................................. 5 73 5. AC E-Tree Type ................................................. 6 74 6. Extension to LDP-VPLS for E-Tree................................ 6 75 6.1. VSI E-Tree Type and Identifier ..........................6 76 6.1.1. VSI E-Tree Type Encoding........................... 6 77 6.1.2. VSI E-Tree Identifier Encoding .....................7 78 6.2. Root/Leaf PWs Signaling................................. 7 79 6.3. Supporting Remote AC.................................... 8 80 7. Extension to BGP-VPLS for E-Tree................................ 9 81 7.1. Auto-discovery ......................................... 9 82 7.2. PW Setup and Teardown................................... 9 83 7.3. Root/Leaf PWs Signaling................................ 10 84 7.4. Optimization .......................................... 10 85 8. Extension to BGP-AD for E-Tree................................. 10 86 8.1. Auto-discovery ........................................ 10 87 8.2. PW Setup and Teardown.................................. 11 88 8.3. Optimization .......................................... 11 89 9. Data Forwarding Requirements................................... 11 90 10. Backward Compatibility........................................ 12 91 10.1. LDP-VPLS ............................................. 12 92 10.2. BGP-VPLS ............................................. 12 93 10.3. BGP-AD ............................................... 12 95 11. Compliance with Requirements.................................. 12 96 12. Security Considerations....................................... 13 97 13. IANA Considerations .......................................... 13 98 14. Acknowledgements ............................................. 13 99 15. References ................................................... 13 100 15.1. Normative References.................................. 13 101 [RFC6074] Rosen, Davie, Radoaca and Luo, Provisioning, Auto-Discovery, 102 and Signaling in Layer 2 Virtual Private Networks (L2VPNs), January 103 2011 ............................................................. 13 104 15.2. Informative References................................ 13 106 1. Introduction 108 This document proposes a solution for Metro Ethernet Forum (MEF) 109 Tree (E-Tree) support in Virtual Private LAN Service using LDP 110 Signaling (LDP-VPLS) [RFC4762], BGP Signaling (BGP-VPLS) [RFC4761] 111 or BGP auto-discovery (BGP-AD) [RFC6074]. 113 [Draft ETree VPLS Req] is used as requirement specification. 115 The proposed solution is characterized by the use of two PWs between 116 a pair of PEs, which requires extension to the current VPLS 117 standards [RFC4762],[RFC4761] and [RFC6074]. 119 This solution is applicable for both VPLS and H-VPLS. 121 The proposed solution is composed of three main components: 123 o Current VPLS standards: LDP-VPLS [RFC4762],BGP-VPLS [RFC4761] 124 and BGP-AD [RFC6074] 126 o Extensions to the above specified in this document 128 o PE local split horizon mechanism 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [RFC2119]. 136 In this document, these words will appear with that interpretation 137 only when in ALL CAPS. Lower case uses of these words are not to be 138 interpreted as carrying RFC-2119 significance. 140 3. The Problem 142 [Draft ETree VPLS Req] identifies the problem when there are two or 143 more PEs with both Root AC and Leaf AC. 145 <-----------E-Tree----------> 147 +---------+ +---------+ 148 | PE1 | | PE2 | 149 +---+ | +---+ | | +---+ | +---+ 150 |CE1+----AC1----+--+ | | | | +--+----AC3----+CE3| 151 +---+ (Root AC) | | V | | | | V | | (Root AC) +---+ 152 | | S +--+--PW----+--+ S | | 153 +---+ | | I | | | | I | | +---+ 154 |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| 155 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 156 +---------+ +---------+ 158 Figure 1: Problem Scenario for Leaf-to-Leaf Communication 159 Restriction 161 When PE2 receives a frame from PE1 via the Ethernet PW: 163 o PE2 does not know whether the ingress AC is a Leaf AC or not 165 o PE2 does not have sufficient information to enforce the Leaf- 166 to-Leaf communication restriction 168 4. The 2-PW Solution 170 A simple fix is to carry additional information with each frame on 171 the PW, indicating whether the frame is originated from a Leaf AC or 172 a Root AC on the ingress PE. 174 The proposed solution uses a pair of PWs to interconnect two VPLS 175 PEs: 177 o First PW is used for frames originated from Root ACs 179 o Second PW is used for frames originated from Leaf ACs 180 <--------------E-Tree--------------> 181 +---------+ +---------+ 182 | PE1 | | PE2 | 183 +---+ | +---+ | | +---+ | +---+ 184 |CE1+----AC1----+--+ | | | | +--+----AC3----+CE3| 185 +---+ (Root AC) | | V +--+-VSI Root PW -+--+ V | | (Root AC) +---+ 186 | | S | | | | S | | 187 +---+ | | I +--+-VSI Leaf PW -+--+ I | | +---+ 188 |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| 189 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 190 +---------+ +---------+ 192 Figure 2: Two-PW Solution for Leaf-to-Leaf Communication Restriction 194 The next sections specify the required extension to current VPLS 195 standards. 197 5. AC E-Tree Type 199 Each AC connected to a specific VPLS instance on a PE MUST have an 200 AC E-Tree Type attribute, either Leaf AC or Root AC. For backward 201 compatibility, the default AC E-Tree Type MUST be Root. 203 This AC E-Tree Type is locally configured on a PE and no signaling 204 is required between PEs. 206 6. Extension to LDP-VPLS for E-Tree 208 This section specifies extensions to LDP-VPLS [RFC 4762] to support 209 E-Tree requirements. These extensions apply to both FEC types 210 specified in [RFC 4762], namely PWid and generalized PWid. 212 6.1. VSI E-Tree Type and Identifier 214 Two new PW interface parameters (as defined in section 5.5 of 215 [RFC4447]) are defined for use in E-Tree VPLS: VSI E-Tree type and 216 VSI E-Tree identifier. 218 VSI E-Tree type can be either root or leaf and identifies VSI root 219 PW and VSI leaf PW respectively, as defined in section 4. 221 VSI E-tree identifier is a number that is used to identify a pair of 222 root and leaf PW as part of the same logical bridge interface. 224 The pair SHALL be unique 225 among PWs connecting a pair of VPLS PEs for the same VPLS instance. 227 6.1.1. VSI E-Tree Type Encoding 229 The VSI E-Tree type field is encoded as an interface parameters sub- 230 TLV (as defined in section 5.5 of [RFC4447]). 232 The field structure is defined as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type (TBD) | Length (1) | VSI E-Tree Type | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 VSI E-tree Type can take the following values: 242 0 E-Tree Root VSI 244 1 E-Tree Leaf VSI 246 6.1.2. VSI E-Tree Identifier Encoding 248 The VSI E-Tree identifier field is encoded as an interface 249 parameters sub-TLV (as defined in section 5.5 of [RFC4447]). 251 The field structure is defined as follows: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type (TBD) | Length (1) | VSI E-Tree Identifier | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | VSI E-Tree Identifier(cont.) | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 VSI E-tree Identifier is a 32-bit number that is used to identify a 262 pair of root and leaf PW as part of the same logical bridge 263 interface, in the context of a pair of VPLS PEs. 265 The reserved field SHALL be set to zero. 267 6.2. Root/Leaf PWs Signaling 269 Signaling of root and leaf PWs is required only when two PWs are 270 used for interconnecting between pair of VSIs. As explained in 271 section 6.1: 273 o Root VSI E-Tree type SHALL be used to signal a root PW. 275 o Leaf VSI E-Tree type SHALL be used to signal a leaf PW. 277 PW type signaling rules remain as defined in [RFC4447]. 279 When the generalized PWid encoding (FEC 129) is used, AII shall be 280 set to 1 for the leaf PW. 282 It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), 283 the following VSI pair types do not require two interconnecting PWs: 285 Root-only VSI <-> any VSI: only root PW required 287 Leaf-only VSI <-> leaf-only VSI: no PWs required 289 Where root-only VSI is a VSI where all ACs are of the root type, and 290 leaf-only VSI is one where all ACs are of the leaf type. 292 6.3. Supporting Remote AC 294 When PW is used to interconnect between VSI and a remote AC (e.g. 295 the PW1, PW2 in Figure 3), an Ethernet Raw or Ethernet tagged PW 296 types SHALL be used as defined in [RFC4762]. 298 <----------------------E-Tree----------> 299 +-------+ +-------+ 300 +----+ | PE1 | | PE2 | 301 +---+ | | | +---+ | | +---+ | 302 |CE1+---AC1---+----+PW1-+-+ | | | | | | +---+ 303 +---+(Root AC)| | | | | | | | +-+---AC4---+CE4| 304 |PE-r| | | V +-+VSI Root PW-+-+ V | |(Root AC)+---+ 305 +---+ | | | | | | | | | | 306 |CE2+---AC2---+----+PW2-+-+ S | | | | S | | 307 +---+(Leaf AC)| | | | | | | | | | 308 +----+ | | I +-+VSI Leaf PW-+-+ I | | 309 +---+ | | | | | | | | +---+ 310 |CE3+--------AC3--------+-+ | | | | +-+---AC5---+CE5| 311 +---+ (Leaf AC) | +---+ | | +---+ |(Leaf AC)+---+ 312 +-------+ +-------+ 314 Figure 3: VPLS with Remote AC Connectivity 316 In addition, the AC type i.e. Root or leaf, SHALL be locally 317 provisioned on the VSI side to specify the remote AC E-Tree Type per 318 PW. Moreover, such PWs that are used for interconnecting between a 319 remote AC and a VSI SHALL considered as separate logical bridge 320 interfaces with respect to MAC address learning/forwarding e.g. 321 traffic forwarding between such PWs is allowed as long as they are 322 not both defined as Leaf. 324 In Figure 3, AC1 is remotely interconnected to the VPLS service via 325 PW1, and AC2 is remotely interconnected to the VPLS service via PW2. 327 AC1 is a Root AC and therefore the local type for PW1 in PE1 SHALL 328 be Root. 330 AC2 is a Leaf AC and therefore the local type for PW2 in PE1 SHALL 331 be Leaf. 333 7. Extension to BGP-VPLS for E-Tree 335 This section specifies extensions to BGP-VPLS [RFC 4761] to support 336 E-Tree requirements. 338 7.1. Auto-discovery 340 Requirements in section 3.2.2 of [RFC 4761] apply, with the 341 following modifications. 343 A PE SHALL advertise two NLRIs for each E-Tree VPLS instance, with 344 the same VE-ID and non-overlapping label blocks. The PE SHALL 345 indicate that one of the NLRIs signals a root PW and the other one 346 signals a leaf PW by setting the E-Tree type field in the attached 347 Layer2 Info Extended Community, as specified in section 7.2. A 348 special E-tree type is used for the leaf PW when only leaf ACs exist 349 in the VPLS instance, as specified in section 7.2. 351 7.2. PW Setup and Teardown 353 Requirements in section 3.2.3 of [RFC4761] apply, with the following 354 modifications. 356 If a PE receives two VPLS NLRI announcements for an E-Tree VPLS 357 instance from a remote PE with the same VE-ID and different 358 root/leaf indication, the PE SHALL set up two PWs to the remote PE. 360 If a PE with an E-Tree VPLS instance with only leaf ACs receives a 361 VPLS NLRI announcement for this instance from a remote PE with the 362 leaf-only indication, no PWs shall be set up to the remote PE. This 363 rule overrides the previous one. 365 If a PE receives a legacy VPLS NLRI for an E-Tree VPLS instance 366 from a remote PE, it will withdraw the Leaf or leaf-only VPLS NLRI 367 it previously advertised and set up only a root PW to the remote PE. 369 PW setup for each of the PWs follows the rules in 3.2.3 of 370 [RFC4761]. 372 A PW established following the receipt of a VPLS NLRI with root 373 indication will be known as root PW. 375 A PW established following the receipt of a VPLS NLRI with leaf or 376 leaf-only indication will be known as leaf PW. 378 Two PWs established following the receipt of VPLS NLRIs with the 379 same VE-ID SHALL be associated to the same logical bridge interface. 381 7.3. Root/Leaf PWs Signaling 383 The Layer2 Info Extended Community attribute is used to indicate 384 root/leaf assignment for the associated VPLS NLRI. 386 With reference to Figure 4, bits 4-5 in the control flags are 387 defined for E-Tree type (ET) signaling. Bits C, S have been defined 388 in [RFC4761]. 390 0 1 2 3 4 5 6 7 391 +-+-+-+-+-+-+-+-+ 392 | MBZ |ET |C|S| (MBZ = MUST Be Zero) 393 +-+-+-+-+-+-+-+-+ 395 Figure 4 - Control Flags Bit Vector 397 ET can take the following values: 399 0 Legacy VPLS NLRI: This PE does not support E-Tree extensions. 401 1 E-Tree Leaf-only VPLS NLRI: there are only leaf ACs in the VSI, 402 and this is the E-Tree Leaf VPLS NLRI. 404 2 E-Tree Root VPLS NLRI: there are root ACs in the VSI, and this is 405 the E-Tree Root VPLS NLRI. 407 3 E-Tree Leaf VPLS NLRI: there are root ACs in the VSI, and this is 408 the E-Tree Leaf VPLS NLRI. 410 7.4. Optimization 412 As in the LDP case (section 6.2), root and leaf PWs need not be 413 established between every VSI pair. Procedures in this draft avoid 414 the establishment of PWs between leaf-only VSIs, but they do not 415 avoid establishment of leaf PW between root-only VSI and any other 416 VSI. This is a consideration for future versions of the draft. 418 8. Extension to BGP-AD for E-Tree 420 This section specifies extensions to BGP-AD [RFC6074] to support E- 421 Tree requirements. 423 8.1. Auto-discovery 425 Requirements in section 3.3.2.1 of [RFC6074] apply, with the 426 following modifications. 428 Each PE with SHALL advertise two NLRIs for each VPLS instance, with 429 the same VE-ID. 431 The PE SHALL indicate that one of the NLRIs advertises a root 432 attachment and the other one a leaf attachment by setting the 433 PE_addr field to zero and one respectively in the NLRIs. 435 8.2. PW Setup and Teardown 437 Requirements in section 3.3.3 of [RFC6074] apply, with the following 438 modifications. 440 If a PE receives two VPLS NLRI announcements from a remote PE with 441 the same VE-ID and different root/leaf indication, the PE SHALL set 442 up two PWs to the remote PE. PW setup for each of the PWs follows 443 the rules in 3.3.3 of [RFC6074]. 445 A PW established following the receipt of a VPLS NLRI with root 446 indication will be known as root PW. 448 A PW established following the receipt of a VPLS NLRI with leaf 449 indication will be known as leaf PW. 451 Two PWs established following the receipt of VPLS NLRIs with the 452 same VE-ID SHALL be associated to the same logical bridge interface. 454 8.3. Optimization 456 As in the LDP case (section 6.2), root and leaf PWs need not be 457 established between every VSI pair. However, BGP-AD optimization to 458 avoid root or leaf PW setup in these cases is not considered in this 459 draft and is left as a consideration for future versions. 461 9. Data Forwarding Requirements 463 On frame reception, two PWs associated to the same logical bridge 464 interface SHALL be handled as a single bridge interface with respect 465 to MAC address learning/forwarding, e.g. traffic SHALL NOT be 466 forwarded between such PWs and MAC addresses in frames arriving at 467 any of the PWs SHALL be learned on a common logical bridge 468 interface. 470 On transmission, the VPLS processing entity SHALL send root- 471 originated traffic via the root PW, and SHALL send leaf-originated 472 traffic via the leaf PW. 474 An egress PE SHALL NOT deliver a frame originated at a leaf AC to 475 another leaf AC. 477 The following specifies how AC E-Tree type per frame is determined: 479 o A frame received from a root PW indicates that the frame was 480 originated from a root AC. 482 o A frame received from a leaf PW indicates that the frame was 483 originated from a leaf AC. 485 o For the case where both ingress AC and egress AC are on the 486 same PE, local split horizon implementation on the PE will be 487 sufficient, and is not further discussed in this document. 489 10. Backward Compatibility 491 10.1. LDP-VPLS 493 Root or leaf VSI E-Tree type and identifier parameters SHALL be used 494 only in cases where both PEs are VPLS capable and both support E- 495 Tree extensions defined in this document. 497 10.2. BGP-VPLS 499 VPLS NLRIs with root/leaf indication are transmitted only to remote 500 PEs that support E-Tree extensions defined in this document. 502 10.3. BGP-AD 504 VPLS NLRIs with root/leaf indication SHALL be transmitted only to 505 remote PEs that support E-Tree extensions defined in this document. 507 11. Compliance with Requirements 509 This refers to [Draft ETree VPLS Req] Section 5 Requirements. 511 The solution prohibits communication between any two Leaf ACs in a 512 VPLS instance. 514 The solution allows multiple Root ACs in a VPLS instance. 516 The solution allows Root AC and Leaf AC of a VPLS instance to co- 517 exist on any PE. 519 The solution is applicable to LDP-VPLS [RFC4762], BGP-VPLS [RFC4762] 520 and BGP-AD [RFC6074]. 522 The solution is applicable to Case 1: Single technology "VPLS Only". 524 12. Security Considerations 526 This will be added in later version. 528 13. IANA Considerations 530 Additional assignments will be required for the new interface 531 parameter sub-TLV types introduced in Section 4.2. Details will be 532 added in a later version. 534 14. Acknowledgements 536 The authors wish to acknowledge the contributions of Luca Martini 537 and Amir Halperin. 539 15. References 541 15.1. Normative References 543 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 544 Requirement Levels, BCP 14, RFC 2119, March 1997. 546 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 547 Using the Label Distribution Protocol (LDP), April 2006 549 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 550 Using Label Distribution Protocol (LDP) Signaling, January 2007 552 [RFC4761] Rekhter & Kompella, Virtual Private LAN Service (VPLS) 553 Using BGP for Auto-Discovery and Signaling, January 2007 555 [RFC6074] Rosen, Davie, Radoaca and Luo, Provisioning, Auto- 556 Discovery, and Signaling in Layer 2 Virtual Private Networks 557 (L2VPNs), January 2011 559 15.2. Informative References 561 [Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree 562 Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-04, September 2011 564 Authors' Addresses 566 Rafi Ram 567 Orckit-Corrigent 568 126 Yigal Alon St. 569 Tel Aviv, Israel 570 Email: rafir@orckit.com 571 Daniel Cohn 572 Orckit-Corrigent 573 126 Yigal Alon St. 574 Tel Aviv, Israel 575 Email: danielc@orckit.com 577 Raymond Key 578 Huawei 579 Email: raymond.key@ieee.org 581 Puneet Agarwal 582 Broadcom 583 3151 Zanker Road 584 San Jose, CA 95134 585 Email: pagarwal@broadcom.com 587 Yuqun (Sam) Cao 588 Ruijie Networks 589 618 Jinshan Road, Fuzhou 350002, China 590 Email: yuqun.cao@gmail.com 592 Josh Rogers 593 Time Warner Cable 594 11921 N MoPac Expwy 595 Austin, TX 78759 596 USA 597 Email: josh.rogers@twcable.com