idnits 2.17.1 draft-sajassi-raggarwa-l2vpn-evpn-req-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 10) being 61 lines 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - The service interface MUST guarantee customer VLAN transparency end-to-end. - The service interface MUST maintain data-plane separation between the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). - In the special case of all-to-one bundling, the service interface MUST not assume any a priori knowledge of the customer VLANs. In other words, the customer VLANs shall not be configured on the PE, rather the interface is configured just like a port-based service. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2011) is 4644 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: 'RFC2119' is mentioned on line 118, but not defined == Missing Reference: 'L2VPN-Sig' is mentioned on line 141, but not defined == Missing Reference: 'G.8032' is mentioned on line 303, but not defined == Missing Reference: 'VPLS-LSM' is mentioned on line 322, but not defined == Missing Reference: 'MEF' is mentioned on line 359, but not defined == Missing Reference: 'RFC 4762' is mentioned on line 384, but not defined == Unused Reference: 'PWE3-FAT-PW' is defined on line 519, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4664 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-multihoming-00 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-06 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-02 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-fat-pw-03 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group Ali Sajassi(Editor) 3 Internet Draft Samer Salam 4 Clarence Filsfils 5 Category: Standards Track Cisco 7 R. Aggarwal(Editor) 8 Juniper Networks 10 Nabil Bitar 11 Verizon 13 Jim Uttaro 14 AT&T 16 Aldrin Isaac 17 Bloomberg 19 Wim Henderickx 20 Alcatel-Lucent 22 Expires: January 11, 2012 July 11, 2011 24 Requirements for Ethernet VPN (E-VPN) 25 draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Copyright and License Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Abstract 77 The widespread adoption of Ethernet L2VPN services and the advent of 78 new applications for the technology (e.g. data center interconnect) 79 have culminated in a new set of requirements that are not readily 80 addressable by the current VPLS solution. In particular, multi- 81 homing with all-active forwarding is not supported and there's no 82 existing solution to leverage MP2MP LSPs for optimizing the delivery 83 of multi-destination frames. Furthermore, the provisioning of VPLS, 84 even in the context of BGP-based auto-discovery, requires network 85 operators to specify various network parameters on top of the access 86 configuration. This document specifies the requirements for an 87 Ethernet VPN (E-VPN) solution which addresses the above issues. 89 Table of Contents 91 1. Specification of Requirements................................... 3 92 2. Introduction.................................................... 3 93 3. Terminology..................................................... 4 94 4. Redundancy Requirements......................................... 4 95 4.1. Flow-based Load Balancing..................................... 4 96 4.2. Flow-based Multi-pathing...................................... 5 97 4.3. Geo-redundant PE Nodes........................................ 5 98 4.4. Optimal Traffic Forwarding.................................... 6 99 4.5. Flexible Redundancy Grouping Support.......................... 6 100 4.6. Multi-homed Network........................................... 6 101 5. Multicast Optimization Requirements............................. 7 102 6. Ease of Provisioning Requirements............................... 7 103 7. New Service Interface Requirements.............................. 8 104 8. Fast Convergence................................................ 9 105 9. Flood Suppression............................................... 9 106 10. Supporting Flexible VPN Topologies and Policies............... 10 107 11. Security Considerations....................................... 10 108 12. IANA Considerations........................................... 10 109 13. Normative References.......................................... 10 110 14. Informative References........................................ 11 111 15. Authors' Addresses............................................ 11 113 1. 114 Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. 120 Introduction 122 VPLS, as defined in [RFC4664][RFC4761][RFC4762], is a proven and 123 widely deployed technology. However, the existing solution has a 124 number of limitations when it comes to redundancy, multicast 125 optimization and provisioning simplicity. Furthermore, new 126 applications are driving several new requirements for a VPLS 127 service. 129 In the area of multi-homing current VPLS can only support multi- 130 homing with active/standby resiliency model, for e.g. as described 131 in [VPLS-BGP-MH]. Flexible multi-homing with all-active Attachment 132 Circuits (ACs) cannot be supported by current VPLS solution. 134 In the area of multicast optimization, [VPLS-MCAST] describes how 135 multicast LSPs can be used in conjunction with VPLS. However, this 136 solution is limited to P2MP LSPs, as there's no defined solution for 137 leveraging MP2MP LSPs with VPLS. 139 In the area of provisioning simplicity, current VPLS does offer a 140 mechanism for single-sided provisioning by relying on BGP-based 141 service auto-discovery [RFC4761][L2VPN-Sig]. This, however, still 142 requires the operator to configure a number of network-side 143 parameters on top of the access-side Ethernet configuration. 145 Furthermore, data center interconnect applications are driving the 146 need for new service interface types which are a hybrid combination 147 of VLAN Bundling and VLAN-based service interfaces. These are 148 referred to as "VLAN-aware Bundling" service interfaces. 150 Also virtualization applications are fueling an increase in the 151 volume of MAC addresses that are to be handled by the network, which 152 gives rise to the requirement for having the network re-convergence 153 upon failure be independent of the number of MAC addresses learned 154 by the PE. 156 In addition, there are requirements for minimizing the amount of 157 flooding of multi-destination frames and localizing the flooding to 158 the confines of a given site. 160 Moreover, there are requirements for supporting flexible VPN 161 topologies and policies beyond those currently covered by (H-)VPLS. 163 The focus of this document is on defining the requirements for a new 164 solution, namely Ethernet VPN (E-VPN), which addresses the above 165 issues. 167 Section 2 provides a summary of the terminology used. Section 3 168 discusses the redundancy requirements. Section 4 describes the 169 multicast optimization requirements. Section 5 articulates the ease 170 of provisioning requirements. Section 6 focuses on the new service 171 interface requirements. Section 7 highlights the fast convergence 172 requirements. Section 8 describes the flood suppression requirement, 173 and finally section 9 discusses the requirements for supporting 174 flexible VPN topologies and policies. 176 3. 177 Terminology 179 CE: Customer Edge 180 E-VPN: Ethernet Virtual Private Network 181 MHD: Multi-homed Device 182 MHN: Multi-homed Network 183 LACP: Link Aggregation Control Protocol 184 LSP: Label Switched Path 185 PE: Provider Edge 186 PoA: Point of Attachment 187 PW: Pseudowire 189 4. 190 Redundancy Requirements 192 4.1. 193 Flow-based Load Balancing 195 A common mechanism for multi-homing a CE node to a set of PE nodes 196 involves leveraging multi-chassis Ethernet link aggregation groups 197 based on [802.1AX] LACP. [PWE3-ICCP] describes one such scheme. In 198 Ethernet link aggregation, the load-balancing algorithms by which a 199 CE distributes traffic over the Attachment Circuits connecting to 200 the PEs are quite flexible. The only requirement is for the 201 algorithm to ensure in-order frame delivery for a given traffic 202 flow. In typical implementations, these algorithms involve selecting 203 an outbound link within the bundle based on a hash function that 204 identifies a flow based on one or more of the following fields: 206 i. Layer 2: Source MAC Address, Destination MAC Address, VLAN 207 ii. Layer 3: Source IP Address, Destination IP Address 208 iii. Layer 4: UDP or TCP Source Port, Destination Port 209 iv. Combinations of the above. 211 A key point to note here is that [802.1AX] does not define a 212 standard load-balancing algorithm for Ethernet bundles, and as such 213 different implementations behave differently. As a matter of fact, a 214 bundle operates correctly even in the presence of asymmetric load- 215 balancing over the links. This being the case, the first requirement 216 for active/active multi-homing is the ability to accommodate 217 flexible flow-based load-balancing from the CE node based on L2, L3 218 and/or L4 header fields. 220 A solution MUST be capable of supporting flexible flow-based load 221 balancing from the CE as described above. Further the MPLS network 222 MUST be able to support flow-based load-balancing of traffic 223 destined to the CE, even when the CE is connected to more than one 224 PE. Thus the solution MUST be able to exercise multiple links 225 connected to the CE, irrespective of the number of PEs that the CE 226 is connected to. 228 4.2. 229 Flow-based Multi-pathing 231 Any solution that meets the active-active flow based load balancing 232 requirement described in section 3.1 MUST also be able to exercise 233 multiple paths between a given pair of PEs. For instance if there 234 are multiple RSVP-TE LSPs between a pair of PEs then the solution 235 MUST be capable of load balancing traffic between those LSPs on a 236 per flow basis. Similarly if LDP is being used as the transport LSP 237 protocol, then the solution MUST be able to leverage LDP ECMP 238 capabilities. The solution MUST also be able to leverage work in the 239 MPLS WG that is in progress to improve the load balancing 240 capabilities of the network based on entropy labels. 242 It is worth pointing out that flow-based multi-pathing complements 243 flow-based load balancing described in the previous section. 245 4.3. 246 Geo-redundant PE Nodes 248 The PE nodes offering multi-homed connectivity to a CE or access 249 network may be situated in the same physical location (co-located), 250 or may be spread geographically (e.g. in different COs or POPs). The 251 latter is desirable when offering a geo-redundant solution that 252 ensures business continuity for critical applications in the case of 253 power outages, natural disasters, etc. An active/active multi-homing 254 mechanism SHOULD support both co-located as well as geo-redundant PE 255 placement. The latter scenario often means that requiring a 256 dedicated link between the PEs, for the operation of the multi- 257 homing mechanism, is not appealing from cost standpoint. 258 Furthermore, the IGP cost from remote PEs to the pair of PEs in the 259 multi-homed setup cannot be assumed to be the same when those latter 260 PEs are geo-redundant. 262 4.4. 263 Optimal Traffic Forwarding 265 In a typical network, and considering a designated pair of PEs, it 266 is common to find both single-homed as well as multi-homed CEs being 267 connected to those PEs. An active/active multi-homing solution 268 SHOULD support optimal forwarding of unicast traffic for all the 269 following scenarios: 271 i. single-homed CE to single-homed CE 272 ii. single-homed CE to multi-homed CE 273 iii. multi-homed CE to single-homed CE 274 iv. multi-homed CE to multi-homed CE 276 This is especially important in the case of geo-redundant PEs, where 277 having traffic forwarded from one PE to another within the same 278 multi-homed group introduces additional latency, on top of the 279 inefficient use of the PE node's and core nodes' switching capacity. 280 A multi-homed group (also known as a multi-chassis LACP group) is a 281 group of PEs supporting a multi-homed CE. 283 4.5. 284 Flexible Redundancy Grouping Support 286 In order to simplify service provisioning and activation, the multi- 287 homing mechanism SHOULD allow arbitrary grouping of PE nodes into 288 redundancy groups where each redundancy group represents all multi- 289 homed groups that share the same group of PEs. This is best 290 explained with an example: consider three PE nodes - PE1, PE2 and 291 PE3. The multi-homing mechanism MUST allow a given PE, say PE1, to 292 be part of multiple redundancy groups concurrently. For example, 293 there can be a group (PE1, PE2), a group (PE1, PE3), and another 294 group (PE2, PE3) where CEs could be multi-homed to any one of these 295 three redundancy groups. 297 4.6. 298 Multi-homed Network 300 There are applications which require an Ethernet network, rather 301 than a single device, to be multi-homed to a group of PEs. The 302 Ethernet network would typically run a resiliency mechanism such as 303 MST or [G.8032] Ring Automated Protection Switching. The PEs may or 304 may not participate in the control protocol of the Ethernet network. 306 A solution MUST support multi-homed network connectivity with 307 active/standby redundancy. 309 A solution MUST also support multi-homed network with active/active 310 VLAN-based load-balancing (i.e. disjoint VLAN sets active on 311 disparate PEs). 313 A solution MAY support multi-homed network with active/active MAC- 314 based load-balancing (i.e. different MAC addresses on a VLAN are 315 reachable via different PEs). 317 5. 318 Multicast Optimization Requirements 320 There are environments where the usage of MP2MP LSPs may be 321 desirable for optimizing multicast, broadcast and unknown unicast 322 traffic. [VPLS-LSM] precludes the usage of MP2MP LSPs since current 323 VPLS solutions require an egress PE to perform learning when it 324 receives unknown uncast packets over a LSP. This is challenging when 325 MP2MP LSPs are used as MP2MP LSPs do not have inherent mechanisms to 326 identify the sender. The usage of MP2MP LSPs for multicast 327 optimization becomes tractable if the need to identify the sender 328 for performing learning is lifted. A solution MUST be able to 329 provide a mechanism that does not require learning when packets are 330 received over a MP2MP LSP. Further a solution MUST be able to 331 provide procedures to use MP2MP LSPs for optimizing delivery of 332 multicast, broadcast and unknown unicast traffic. 334 6. 335 Ease of Provisioning Requirements 337 As L2VPN technologies expand into enterprise deployments, ease of 338 provisioning becomes paramount. Even though current VPLS has auto- 339 discovery mechanisms which allow for single-sided provisioning, 340 further simplifications are required, as outlined below: 342 - Single-sided provisioning behavior MUST be maintained 343 - For deployments where VLAN identifiers are global across the MPLS 344 network (i.e. the network is limited to a maximum of 4K services), 345 it is required that the devices derive the MPLS specific attributes 346 (e.g. VPN ID, BGP RT, etc.) from the VLAN identifier. This way, it 347 is sufficient for the network operator to configure the VLAN 348 identifier(s) on the access circuit, and all the MPLS and BGP 349 parameters required for setting up the service over the core network 350 would be automatically derived without any need for explicit 351 configuration. 353 - Implementations SHOULD revert to using default values for 354 parameters as and where applicable. 356 7. 357 New Service Interface Requirements 359 [MEF] and [IEEE 802.1Q] have the following services specified: 360 - Port mode: in this mode, all traffic on the port is mapped to a 361 single bridge domain and a single corresponding L2VPN service 362 instance. Customer VLAN transparency is guaranteed end-to-end. 364 - VLAN mode: in this mode, each VLAN on the port is mapped to a 365 unique bridge domain and corresponding L2VPN service instance. 366 This mode allows for service multiplexing over the port and 367 supports optional VLAN translation. 369 - VLAN bundling: in this mode, a group of VLANs on the port are 370 collectively mapped to a unique bridge domain and corresponding 371 L2VPN service instance. Customer MAC addresses must be unique 372 across all VLANs mapped to the same service instance. 374 For each of the above services a single bridge domain is assigned 375 per service instance on the PE supporting the associated service. 376 For example, in case of the port mode, a single bridge domain is 377 assigned for all the ports belonging to that service instance 378 regardless of number of VLANs coming through these ports. 380 It is worth noting that the term 'bridge domain' as used above 381 refers to a MAC forwarding table as defined in the IEEE bridge 382 model, and does not denote or imply any specific implementation. 384 [RFC 4762] defines two types of VPLS services based on "unqualified 385 and qualified learning" which in turn maps to port mode and VLAN 386 mode respectively. 388 A solution is required to support the above three service types plus 389 two additional service types which are primarily intended for hosted 390 data center applications and are described below. 392 For hosted data center interconnect applications, network operators 393 require the ability to extend Ethernet VLANs over a WAN using a 394 single L2VPN instance while maintaining data-plane separation 395 between the various VLANs associated with that instance. This gives 396 rise to two new service interface types: VLAN-aware Bundling without 397 Translation, and VLAN-aware Bundling with Translation. 399 The VLAN-aware Bundling without Translation service interface has 400 the following characteristics: 401 - The service interface MUST provide bundling of customer VLANs into 402 a single L2VPN service instance. 404 - The service interface MUST guarantee customer VLAN transparency 405 end-to-end. 406 - The service interface MUST maintain data-plane separation between 407 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 408 - In the special case of all-to-one bundling, the service interface 409 MUST not assume any a priori knowledge of the customer VLANs. In 410 other words, the customer VLANs shall not be configured on the PE, 411 rather the interface is configured just like a port-based service. 413 The VLAN-aware Bundling with Translation service interface has the 414 following characteristics: 415 - The service interface MUST provide bundling of customer VLANs into 416 a single L2VPN service instance. 417 - The service interface MUST maintain data-plane separation between 418 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 419 - The service interface MUST support customer VLAN translation to 420 handle the scenario where different VLAN Identifiers (VIDs) are used 421 on different interfaces to designate the same customer VLAN. 423 The main difference, in terms of service provider resource 424 allocation, between these new service types and the previously 425 defined three types is that the new services require several bridge 426 domains to be allocated (one per customer VLAN) per L2VPN service 427 instance as opposed to a single bridge domain per L2VPN service 428 instance. 430 8. 431 Fast Convergence 433 A solution MUST provide the ability to recover from PE-CE attachment 434 circuit failures as well as PE node failure for the case of both 435 multi-homed device and multi-homed network. The recovery 436 mechanism(s) MUST provide convergence time that is independent of 437 the number of MAC addresses learned by the PE. This is particularly 438 important in the context of virtualization applications which are 439 fueling an increase in the number of MAC addresses to be handled by 440 the Layer 2 network. 441 Furthermore, the recovery mechanism(s) SHOULD provide convergence 442 time that is independent of the number of service instances 443 associated with the attachment circuit or PE. 445 9. 446 Flood Suppression 448 The solution SHOULD allow the network operator to choose whether 449 unknown unicast frames are to be dropped or to be flooded. This 450 attribute need to be configurable on a per service instance basis. 452 In addition, for the case where the solution is used for data-center 453 interconnect, it is required to minimize the flooding of broadcast 454 frames outside the confines of a given site. Of particular interest 455 is periodic ARP traffic. 457 Furthermore, it is required to eliminate any unnecessary flooding of 458 unicast traffic upon topology changes, especially in the case of 459 multi-homed site where the PEs have a priori knowledge of the backup 460 paths for a given MAC address. 462 10. 463 Supporting Flexible VPN Topologies and Policies 465 A solution MUST be capable of supporting flexible VPN topologies 466 that are not constrained by the underlying mechanisms of the 467 solution. One example of this is hub and spoke where one or more 468 sites in the VPN are hubs and the others as spokes. The hubs are 469 allowed to send traffic to other hubs and to spokes, while spokes 470 can communicate only with other hubs. The solution MUST provide the 471 ability to support hub and spoke. Further the solution MUST provide 472 the ability to apply policies at the MAC address granularity to 473 control which PEs in the VPN learn which MAC address and how a 474 specific MAC address is forwarded. It MUST be possible to apply 475 policies to allow only some of the member PEs in the VPN to send or 476 receive traffic for a particular MAC address. 478 11. 479 Security Considerations 481 There are no additional security aspects beyond those of VPLS/H-VPLS 482 that need to be discussed here. 484 12. 485 IANA Considerations 487 None. 489 13. 490 Normative References 492 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 493 September 2006. 495 [RFC4761] "Virtual Private LAN Service (VPLS) Using BGP for Auto- 496 discovery and Signaling", January 2007. 498 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label 499 Distribution Protocol (LDP) Signaling", January 2007. 501 [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 502 metropolitan area networks - Link Aggregation", IEEE Computer 503 Society, November, 2008. 505 14. 506 Informative References 508 [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual 509 Private LAN Service", draft-ietf-l2vpn-vpls-multihoming-00, work in 510 progress, November, 2009. 512 [VPLS-MCAST] Aggarwal et al., "Multicast in VPLS", draft-ietf-l2vpn- 513 vpls-mcast-06.txt, work in progress, March, 2010. 515 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol 516 for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-02.txt, work in 517 progress, Octoer, 2009. 519 [PWE3-FAT-PW] Bryant et al., "Flow Aware Transport of Pseudowires 520 over an MPLS PSN", draft-ietf-pwe3-fat-pw-03.txt, work in 521 progress, January 2010. 523 15. 524 Authors' Addresses 526 Ali Sajassi 527 Cisco 528 170 West Tasman Drive 529 San Jose, CA 95134, USA 530 Email: sajassi@cisco.com 532 Samer Salam 533 Cisco 534 595 Burrard Street, Suite 2123 535 Vancouver, BC V7X 1J1, Canada 536 Email: ssalam@cisco.com 538 Rahul Aggarwal 539 Juniper Networks 540 1194 N. Mathilda Ave. 541 Sunnyvale, CA 94089, USA 542 Email: rahul@juniper.net 544 Nabil Bitar 545 Verizon Communications 546 Email : nabil.n.bitar@verizon.com 548 James Uttaro 549 AT&T 550 200 S. Laurel Avenue 551 Middletown, NJ 07748, USA 552 Email: uttaro@att.com 553 Aldrin Isaac 554 Bloomberg 555 Email: aisaac71@bloomberg.net 557 Clarence Filsfils 558 Cisco 559 Email: cfilsfil@cisco.com 561 Wim Henderickx 562 Alcate-lLucent 563 Email: wim.henderickx@alcatel-lucent.be