idnits 2.17.1 draft-ietf-bess-evpn-mh-pa-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 : ---------------------------------------------------------------------------- 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 (7 March 2022) is 774 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) == Outdated reference: A later version (-13) exists of draft-ietf-bess-evpn-pref-df-08 == Outdated reference: A later version (-08) exists of draft-ietf-bess-rfc7432bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-bess-evpn-vpws-fxc-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group P. Brissette, Ed. 3 Internet-Draft A. Sajassi 4 Intended status: Standards Track LA. Burdet, Ed. 5 Expires: 8 September 2022 S. Thoria 6 Cisco Systems 7 B. Wen 8 Comcast 9 E. Leyton 10 Verizon Wireless 11 J. Rabadan 12 Nokia 13 7 March 2022 15 EVPN multi-homing port-active load-balancing 16 draft-ietf-bess-evpn-mh-pa-05 18 Abstract 20 The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables 21 establishing a logical link-aggregation connection with a redundant 22 group of independent nodes. The purpose of multi-chassis LAG is to 23 provide a solution to achieve higher network availability, while 24 providing different modes of sharing/balancing of traffic. RFC7432 25 defines EVPN based MC-LAG with single-active and all-active 26 multi-homing load-balancing mode. The current draft expands on 27 existing redundancy mechanisms supported by EVPN and introduces 28 support for port-active load-balancing mode. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Multi-Chassis Link Aggregation . . . . . . . . . . . . . . . 4 66 3. Port-active Load-balancing Procedure . . . . . . . . . . . . 4 67 4. Designated Forwarder Algorithm to Elect per Port-active PE . 5 68 4.1. Capability Flag . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Modulo-based Algorithm . . . . . . . . . . . . . . . . . 6 70 4.3. HRW Algorithm . . . . . . . . . . . . . . . . . . . . . . 6 71 4.4. Preference-based DF Election . . . . . . . . . . . . . . 7 72 4.5. AC-Influenced DF Election . . . . . . . . . . . . . . . . 7 73 5. Convergence considerations . . . . . . . . . . . . . . . . . 8 74 5.1. Primary / Backup per Ethernet-Segment . . . . . . . . . . 8 75 5.2. Backward Compatibility . . . . . . . . . . . . . . . . . 9 76 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Overall Advantages . . . . . . . . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 EVPN, as per [RFC7432], provides all-active per flow load-balancing 89 for multi-homing. It also defines single-active with service carving 90 mode, where one of the PEs, in redundancy relationship, is active per 91 service. 93 While these two multi-homing scenarios are most widely utilized in 94 data center and service provider access networks, there are scenarios 95 where active-standby per interface multi-homing load-balancing is 96 useful and required. The main consideration for this mode of 97 load-balancing is the determinism of traffic forwarding through a 98 specific interface rather than statistical per flow load-balancing 99 across multiple PEs providing multi-homing. The determinism provided 100 by active-standby per interface is also required for certain QOS 101 features to work. While using this mode, customers also expect 102 minimized convergence during failures. 104 A new type of load-balancing mode, port-active load-balancing, is 105 defined. This draft describes how the new load-balancing mode can be 106 supported via EVPN. The new mode may also be referred to as per 107 interface active/standby. 109 +-----+ 110 | PE3 | 111 +-----+ 112 +-----------+ 113 | MPLS/IP | 114 | CORE | 115 +-----------+ 116 +-----+ +-----+ 117 | PE1 | | PE2 | 118 +-----+ +-----+ 119 | | 120 I1 I2 121 \ / 122 \ / 123 +---+ 124 |CE1| 125 +---+ 127 Figure 1: MC-LAG Topology 129 Figure 1 shows a MC-LAG multi-homing topology where PE1 and PE2 are 130 part of the same redundancy group providing multi-homing to CE1 via 131 interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG 132 running LACP protocol. The core, shown as IP or MPLS enabled, 133 provides wide range of L2 and L3 services. MC-LAG multi-homing 134 functionality is decoupled from those services in the core and it 135 focuses on providing multi-homing to the CE. With per-port active/ 136 standby load-balancing, only one of the two interface I1 or I2 would 137 be in forwarding, the other interface will be in standby. This also 138 implies that all services on the active interface are in active mode 139 and all services on the standby interface operate in standby mode. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Multi-Chassis Link Aggregation 151 When a CE is multi-homed to a set of PE nodes using the 152 [IEEE.802.1AX_2014] Link Aggregation Control Protocol (LACP), the PEs 153 must act as if they were a single LACP speaker for the Ethernet links 154 to form and operate as a Link Aggregation Group (LAG). To achieve 155 this, the PEs connected to the same multi-homed CE must synchronize 156 LACP configuration and operational data among them. Interchassis 157 Communication Protocol (ICCP) [RFC7275] has been used for that 158 purpose. EVPN LAG simplifies greatly that solution. Along with the 159 simplification come a few assumptions: 161 * a CE device connected to multi-homing PEs may have a single LAG 162 with all its active links i.e. links in the LAG operate in all- 163 active load-balancing mode. 165 * Same LACP parameters MUST be configured on peering PEs such as 166 system id, port priority and port key. 168 Any discrepancies from this list are out of the scope of this 169 document, as are mis-configuration and mis-wiring detection across 170 peering PEs. 172 3. Port-active Load-balancing Procedure 174 Following steps describe the proposed procedure with EVPN LAG to 175 support port-active load-balancing mode: 177 a. The Ethernet-Segment Identifier (ESI) MUST be assigned per access 178 interface as described in [RFC7432], which may be auto derived or 179 manually assigned. Access interface MAY be a Layer-2 or Layer-3 180 interface. The usage of ESI over Layer-3 interface is newly 181 described in this document. 183 b. Ethernet-Segment (ES) MUST be configured in port-active 184 load-balancing mode on peering PEs for specific access interface. 186 c. Peering PEs MAY exchange only Ethernet-Segment (ES) route 187 (Route Type-4) when ESI is configured on a Layer-3 interface. 189 d. PEs in the redundancy group leverage the DF election defined in 190 [RFC8584] to determine which PE keeps the port in active mode and 191 which one(s) keep it in standby mode. While the DF election 192 defined in [RFC8584] is per [ES, Ethernet Tag] granularity, for 193 port-active mode of multi-homing, the DF election is done per 194 . The details of this algorithm are described in Section 4. 196 e. DF router MUST keep corresponding access interface in up and 197 forwarding active state for that Ethernet-Segment 199 f. Non-DF routers will by default implement a bidirectional blocking 200 scheme for all traffic in line with [RFC7432] Single-Active 201 blocking scheme, albeit across all VLANS. 203 * Non-DF routers MAY bring and keep peering access interface 204 attached to it in operational down state. 206 * If the interface is running LACP protocol, then the non-DF PE 207 MAY also set the LACP state to OOS (Out of Sync) as opposed to 208 interface state down. This allows for better convergence on 209 standby to active transition. 211 g. For EVPN-VPWS service, the usage of primary/backup bits of EVPN 212 Layer-2 attributes extended community [RFC8214] is highly 213 recommended to achieve better convergence. 215 4. Designated Forwarder Algorithm to Elect per Port-active PE 217 The ES routes, running in port-active load-balancing mode, are 218 advertised with the new Port Mode Load-Balancing capability in the DF 219 Election Extended Community defined in [RFC8584]. Moreover, the ES 220 associated to the port leverages existing procedure of Single-Active, 221 and signals Single-Active(RED=01) Multihomed site redundancy mode 222 along with Ethernet-AD per-ES route (Section 7.5 of 223 [I-D.ietf-bess-rfc7432bis]). Finally the ESI-label based split- 224 horizon procedures in [RFC7432] should be used to avoid transient 225 echo'ed packets when Layer-2 circuits are involved. 227 The various algorithms for DF Election are discussed in Sections 4.2 228 to 4.5 for completeness, although the choice of algorithm in this 229 solution doesn't affect complexity or performance as in other load- 230 balancing modes. 232 4.1. Capability Flag 234 [RFC8584] defines a DF Election extended community, and a Bitmap 235 field to encode "capabilities" to use with the DF election algorithm 236 in the DF algorithm field. Bitmap (2 octets) is extended by the 237 following value: 239 1 1 1 1 1 1 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |D|A| |P| | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: Amended Bitmap field in the DF Election Extended Community 247 Bit 0: D bit or 'Don't Preempt' bit, as explained in 248 [I-D.ietf-bess-evpn-pref-df]. 250 Bit 1: AC-DF Capability (AC-Influenced DF election), as explained 251 in [RFC8584]. 253 Bit 5: (corresponds to Bit 29 of the DF Election Extended 254 Community and it is defined by this document): 'Port Mode 255 Load-Balancing' Capability (P bit hereafter), determines 256 that the DF-Algorithm should be modified to consider the 257 port ES only and not the Ethernet Tags. 259 4.2. Modulo-based Algorithm 261 The default DF Election algorithm, or modulus-based algorithm as in 262 [RFC7432] and updated by [RFC8584], is used here, at the granularity 263 of ES only. Given that ES-Import Route Target extended community may 264 be auto-derived and directly inherits its auto-derived value from ESI 265 bytes 1-6, many operators differentiate ESI primarily within these 266 bytes. As a result, bytes 3-6 are used to determine the designated 267 forwarder using Modulo-based DF assignment, achieving good entropy 268 during Modulo calculation across ESIs: 269 Assuming a redundancy group of N PE nodes, the PE with ordinal i is 270 the DF for an when (Es mod N) = i, where Es represents bytes 3-6 271 of that ESI. 273 4.3. HRW Algorithm 275 Highest Random Weight (HRW) algorithm defined in [RFC8584] MAY also 276 be used and signaled, and modified to operate at the granularity of 277 rather than per . 279 Section 3.2 of [RFC8584] describes computing a 32 bit CRC over the 280 concatenation of Ethernet Tag and ESI. For port-active 281 load-balancing mode, the Ethernet Tag is simply removed from the CRC 282 computation. 284 DF(Es) denotes the DF and BDF(Es) denote the BDF for the ESI es; Si 285 is the IP address of PE i; and Weight is a function of Si, and Es. 287 1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the 288 case of a tie, choose the PE whose IP address is numerically the 289 least. Note that 0 <= i,j < number of PEs in the redundancy 290 group. 292 2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, 293 Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose 294 IP address is numerically the least. 296 Where: 298 * DF(Es) is defined to be the address Si (index i) for which 299 Weight(Es, Si) is the highest; 0 <= i < N-1. 301 * BDF(Es) is defined as that PE with address Sk for which the 302 computed Weight is the next highest after the Weight of the DF. j 303 is the running index from 0 to N-1; i and k are selected values. 305 4.4. Preference-based DF Election 307 When the new capability 'Port-Mode' is signaled, the algorithm is 308 modified to consider the port only and not any associated Ethernet 309 Tags. Furthermore, the "port-based" capability MUST be compatible 310 with the "Don't Preempt" bit. When an interface recovers, a peering 311 PE signaling D-bit will enable non-revertive behaviour at the port 312 level. 314 4.5. AC-Influenced DF Election 316 The AC-DF bit MUST be set to 0 when advertising Port Mode Load- 317 Balancing capability (P=1). When an AC (sub-interface) goes down, it 318 does not influence the DF election. The peer's Ethernet A-D per EVI 319 is ignored in all Port Mode DF Election algorthms. 321 Upon receiving AC-DF bit set (A=1) from a remote PE, it MUST be 322 ignored when performing Port-Mode DF Election. 324 5. Convergence considerations 326 To improve the convergence, upon failure and recovery, when 327 port-active load-balancing mode is used, some advanced 328 synchronization between peering PEs may be required. Port-active is 329 challenging in a sense that the "standby" port is in down state. It 330 takes some time to bring a "standby" port in up-state and settle the 331 network. For IRB and L3 services, ARP / ND cache may be 332 synchronized. Moreover, associated VRF tables may also be 333 synchronized. For L2 services, MAC table synchronization may be 334 considered. 336 Finally, for members of a LAG running LACP the ability to set the 337 "standby" port in "out-of-sync" state a.k.a "warm-standby" can be 338 leveraged. 340 5.1. Primary / Backup per Ethernet-Segment 342 The EVPN Layer 2 Attributes Control Flags extended community SHOULD 343 be advertised in Ethernet A-D per ES route for fast convergence. 345 Only the P and B bits are relevant to this document, and only in the 346 context of Ethernet A-D per ES routes: 348 * When advertised, the EVPN Layer 2 Attributes Control Flags 349 extended community SHALL have only P or B bits set and all other 350 bits and fields MUST be zero. 352 * A remote PE receiving the optional EVPN Layer 2 Attributes Control 353 Flags extended community in Ethernet A-D per ES routes SHALL 354 consider only P and B bits. 356 For EVPN Layer 2 Attributes Control Flags extended community sent and 357 received in Ethernet A-D per EVI routes used in [RFC8214], 358 [I-D.ietf-bess-rfc7432bis] and [I-D.ietf-bess-evpn-vpws-fxc]: 360 * P and B bits received are overridden by "parent" bits on Ethernet 361 A-D per ES above. 363 * Other fields and bits of the extended community are used according 364 to the procedures of those documents. 366 5.2. Backward Compatibility 368 Implementations that comply with [RFC7432] or [RFC8214] only (i.e., 369 implementations that predate this document) will not advertise the 370 EVPN Layer 2 Attributes Control Flags extended community in Ethernet 371 A-D per ES routes. That means that all remote PEs in the ES will not 372 receive P and B bit per ES and will continue to receive and honour 373 the P and B bits received in Ethernet A-D per EVI route(s). 374 Similarly, an implementation that complies with [RFC7432] or 375 [RFC8214] only and that receives an EVPN Layer 2 Attributes Control 376 Flags extended community will ignore it and will continue to use the 377 default path resolution algorithm. 379 6. Applicability 381 A common deployment is to provide L2 or L3 service on the PEs 382 providing multi-homing. The services could be any L2 EVPN such as 383 EVPN VPWS, EVPN [RFC7432], etc. L3 service could be in VPN context 384 [RFC4364] or in global routing context. When a PE provides first hop 385 routing, EVPN IRB could also be deployed on the PEs. The mechanism 386 defined in this document is used between the PEs providing L2 and/or 387 L3 services, when per interface single-active load-balancing is 388 desired. 390 A possible alternate solution is the one described in this draft is 391 MC-LAG with ICCP [RFC7275] active-standby redundancy. However, ICCP 392 requires LDP to be enabled as a transport of ICCP messages. There 393 are many scenarios where LDP is not required e.g. deployments with 394 VXLAN or SRv6. The solution defined in this draft with EVPN does not 395 mandate the need to use LDP or ICCP and is independent of the 396 underlay encapsulation. 398 7. Overall Advantages 400 The use of port-active multi-homing brings the following benefits to 401 EVPN networks: 403 a. Open standards based per interface single-active load-balancing 404 mechanism that eliminates the need to run ICCP and LDP (e.g. they 405 may be running VXLAN or SRv6 in the network). 407 b. Agnostic of underlay technology (MPLS, VXLAN, SRv6) and 408 associated services (L2, L3, Bridging, E-LINE, etc). 410 c. Provides a way to enable deterministic QOS over MC-LAG attachment 411 circuits. 413 d. Fully compliant with [RFC7432], does not require any new protocol 414 enhancement to existing EVPN RFCs. 416 e. Can leverage various DF election algorithms e.g. modulo, HRW, 417 etc. 419 f. Replaces legacy MC-LAG ICCP-based solution, and offers following 420 additional benefits: 422 * Efficiently supports 1+N redundancy mode (with EVPN using BGP 423 RR) where as ICCP requires full mesh of LDP sessions among PEs 424 in redundancy group. 426 * Fast convergence with mass-withdraw is possible with EVPN, no 427 equivalent in ICCP. 429 8. IANA Considerations 431 This document solicits the allocation of the following values: 433 * Bit 5 in the [RFC8584] DF Election Capabilities registry, with 434 name "P" for Port Mode Load-Balancing. 436 9. Security Considerations 438 The same Security Considerations described in [RFC7432] and [RFC8584] 439 are valid for this document. 441 By introducing a new capability, a new requirement for unanimity (or 442 lack thereof) between PEs is added. Without consensus on the new DF 443 election procedures and Port Mode, the DF election algorithm falls 444 back to the default DF election as provided in [RFC8584], [RFC7432] 445 and [I-D.ietf-bess-rfc7432bis]. This behavior could be exploited by 446 an attacker that manages to modify the configuration of one PE in the 447 ES so that the DF election algorithm and capabilities in all the PEs 448 in the ES fall back to the default DF election. If that is the case, 449 the PEs will be exposed to the same unfair load balancing, service 450 disruption, and possibly black-holing or duplicate traffic mentioned 451 in those documents and their security sections. 453 10. Acknowledgements 455 The authors thank Anoop Ghanwani for his comments and suggestions and 456 Stephane Litkowski for his careful review. 458 11. References 460 11.1. Normative References 462 [I-D.ietf-bess-evpn-pref-df] 463 Rabadan, J., Sathappan, S., Przygienda, T., Lin, W., 464 Drake, J., Sajassi, A., and satyamoh@cisco.com, 465 "Preference-based EVPN DF Election", Work in Progress, 466 Internet-Draft, draft-ietf-bess-evpn-pref-df-08, 23 467 September 2021, . 470 [I-D.ietf-bess-rfc7432bis] 471 Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan, 472 "BGP MPLS-Based Ethernet VPN", Work in Progress, Internet- 473 Draft, draft-ietf-bess-rfc7432bis-04, 7 March 2022, 474 . 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 483 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 484 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 485 2015, . 487 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 488 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 489 May 2017, . 491 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 492 Rabadan, "Virtual Private Wire Service Support in Ethernet 493 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 494 . 496 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 497 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 498 VPN Designated Forwarder Election Extensibility", 499 RFC 8584, DOI 10.17487/RFC8584, April 2019, 500 . 502 11.2. Informative References 504 [I-D.ietf-bess-evpn-vpws-fxc] 505 Sajassi, A., Brissette, P., Uttaro, J., Drake, J., 506 Boutros, S., and J. Rabadan, "EVPN VPWS Flexible Cross- 507 Connect Service", Work in Progress, Internet-Draft, draft- 508 ietf-bess-evpn-vpws-fxc-05, 8 February 2022, 509 . 512 [IEEE.802.1AX_2014] 513 IEEE, "IEEE Standard for Local and metropolitan area 514 networks -- Link Aggregation", IEEE 802.1AX-2014, 515 DOI 10.1109/IEEESTD.2014.7055197, 24 December 2014, 516 . 519 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 520 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 521 2006, . 523 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., 524 Matsushima, S., and T. Nadeau, "Inter-Chassis 525 Communication Protocol for Layer 2 Virtual Private Network 526 (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, 527 DOI 10.17487/RFC7275, June 2014, 528 . 530 Authors' Addresses 532 Patrice Brissette (editor) 533 Cisco Systems 534 Ottawa ON 535 Canada 536 Email: pbrisset@cisco.com 538 Ali Sajassi 539 Cisco Systems 540 United States of America 541 Email: sajassi@cisco.com 543 Luc Andre Burdet (editor) 544 Cisco Systems 545 Canada 546 Email: lburdet@cisco.com 547 Samir Thoria 548 Cisco Systems 549 United States of America 550 Email: sthoria@cisco.com 552 Bin Wen 553 Comcast 554 United States of America 555 Email: Bin_Wen@comcast.com 557 Edward Leyton 558 Verizon Wireless 559 United States of America 560 Email: edward.leyton@verizonwireless.com 562 Jorge Rabadan 563 Nokia 564 United States of America 565 Email: jorge.rabadan@nokia.com