idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- 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 (October 21, 2012) is 4204 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: 'G.8032' is mentioned on line 282, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-multihoming-03 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-11 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group A. Sajassi 3 INTERNET-DRAFT Cisco 4 Category: Standards Track 5 R. Aggarwal 6 W. Henderickx Arktan 7 Alcatel-Lucent 8 N. Bitar 9 S. Salam Verizon 10 C. Filsfils 11 Cisco 12 Aldrin Isaac 13 J. Drake Bloomberg 14 Juniper Networks 15 J. Uttaro 16 AT&T 18 Expires: April 21, 2013 October 21, 2012 20 Requirements for Ethernet VPN (E-VPN) 21 draft-ietf-l2vpn-evpn-req-01.txt 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 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/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Abstract 61 The widespread adoption of Ethernet L2VPN services and the advent of 62 new applications for the technology (e.g. data center interconnect) 63 have culminated in a new set of requirements that are not readily 64 addressable by the current VPLS solution. In particular, multi-homing 65 with all-active forwarding is not supported and there's no existing 66 solution to leverage MP2MP LSPs for optimizing the delivery of multi- 67 destination frames. Furthermore, the provisioning of VPLS, even in 68 the context of BGP-based auto-discovery, requires network operators 69 to specify various network parameters on top of the access 70 configuration. This document specifies the requirements for an 71 Ethernet VPN (E-VPN) solution which addresses the above issues. 73 Table of Contents 75 1. Specification of requirements . . . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Redundancy Requirements . . . . . . . . . . . . . . . . . . . . 5 79 4.1. Flow-based Load Balancing . . . . . . . . . . . . . . . . 5 80 4.2. Flow-based Multi-pathing . . . . . . . . . . . . . . . . . 6 81 4.3. Geo-redundant PE Nodes . . . . . . . . . . . . . . . . . . 6 82 4.4. Optimal Traffic Forwarding . . . . . . . . . . . . . . . . 7 83 4.5. Flexible Redundancy Grouping Support . . . . . . . . . . . 7 84 4.6. Multi-homed Network . . . . . . . . . . . . . . . . . . . 7 85 5. Multicast Optimization Requirements . . . . . . . . . . . . . . 8 86 6. Ease of Provisioning Requirements . . . . . . . . . . . . . . . 8 87 7. New Service Interface Requirements . . . . . . . . . . . . . . 9 88 8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . 10 89 9. Flood Suppression . . . . . . . . . . . . . . . . . . . . . . . 11 90 10. Supporting Flexible VPN Topologies and Policies . . . . . . . 11 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 13. Normative References . . . . . . . . . . . . . . . . . . . . . 12 94 14. Informative References . . . . . . . . . . . . . . . . . . . . 12 95 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Specification of requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 VPLS, as defined in [RFC4664][RFC4761][RFC4762], is a proven and 106 widely deployed technology. However, the existing solution has a 107 number of limitations when it comes to redundancy, multicast 108 optimization and provisioning simplicity. Furthermore, new 109 applications are driving several new requirements for other L2VPN 110 services such as E-TREE, VPWS, and VPMS. 112 In the area of multi-homing current VPLS can only support multi- 113 homing with active/standby resiliency model, for e.g. as described in 114 [VPLS-BGP-MH]. Flexible multi-homing with all-active Attachment 115 Circuits (ACs) cannot be supported by current VPLS solution. 117 In the area of multicast optimization, [VPLS-MCAST] describes how 118 multicast LSPs can be used in conjunction with VPLS. However, this 119 solution is limited to P2MP LSPs, as there's no defined solution for 120 leveraging MP2MP LSPs with VPLS. 122 In the area of provisioning simplicity, current VPLS does offer a 123 mechanism for single-sided provisioning by relying on BGP-based 124 service auto-discovery [RFC4761][RFC6074]. This, however, still 125 requires the operator to configure a number of network-side 126 parameters on top of the access-side Ethernet configuration. 128 Furthermore, data center interconnect applications are driving the 129 need for new service interface types which are a hybrid combination 130 of VLAN Bundling and VLAN-based service interfaces. These are 131 referred to as "VLAN-aware Bundling" service interfaces. 133 Also virtualization applications are fueling an increase in the 134 volume of MAC addresses that are to be handled by the network, which 135 gives rise to the requirement for having the network re-convergence 136 upon failure be independent of the number of MAC addresses learned by 137 the PE. 139 In addition, there are requirements for minimizing the amount of 140 flooding of multi-destination frames and localizing the flooding to 141 the confines of a given site. 143 Moreover, there are requirements for supporting flexible VPN 144 topologies and policies beyond those currently covered by (H-)VPLS. 146 The focus of this document is on defining the requirements for a new 147 solution, namely Ethernet VPN (E-VPN), which addresses the above 148 issues. 150 Section 2 provides a summary of the terminology used. Section 3 151 discusses the redundancy requirements. Section 4 describes the 152 multicast optimization requirements. Section 5 articulates the ease 153 of provisioning requirements. Section 6 focuses on the new service 154 interface requirements. Section 7 highlights the fast convergence 155 requirements. Section 8 describes the flood suppression requirement, 156 and finally section 9 discusses the requirements for supporting 157 flexible VPN topologies and policies. 159 3. Terminology 161 CE: Customer Edge E-VPN: Ethernet Virtual Private Network MHD: Multi- 162 homed Device MHN: Multi-homed Network LACP: Link Aggregation Control 163 Protocol LSP: Label Switched Path PE: Provider Edge PoA: Point of 164 Attachment PW: Pseudowire MP2MP: Multipoint to Multipoint P2MP: Point 165 to Multipoint P2P:Point to Point 167 4. Redundancy Requirements 169 4.1. Flow-based Load Balancing 171 A common mechanism for multi-homing a CE node to a set of PE nodes 172 involves leveraging multi-chassis Ethernet link aggregation groups 173 based on [802.1AX] LACP. [PWE3-ICCP] describes one such scheme. In 174 Ethernet link aggregation, the load-balancing algorithms by which a 175 CE distributes traffic over the Attachment Circuits connecting to the 176 PEs are quite flexible. The only requirement is for the algorithm to 177 ensure in-order frame delivery for a given traffic flow. In typical 178 implementations, these algorithms involve selecting an outbound link 179 within the bundle based on a hash function that identifies a flow 180 based on one or more of the following fields: 182 i. Layer 2: Source MAC Address, Destination MAC Address, VLAN 183 ii. Layer 3: Source IP Address, Destination IP Address 184 iii. Layer 4: UDP or TCP Source Port, Destination Port 186 A key point to note here is that [802.1AX] does not define a standard 187 load-balancing algorithm for Ethernet bundles, and as such different 188 implementations behave differently. As a matter of fact, a bundle 189 operates correctly even in the presence of asymmetric load-balancing 190 over the links. This being the case, the first requirement for 191 active/active multi-homing is the ability to accommodate flexible 192 flow-based load-balancing from the CE node based on L2, L3 and/or L4 193 header fields. 195 A solution MUST be capable of supporting flexible flow-based load 196 balancing from the CE as described above. Further the MPLS network 197 MUST be able to support flow-based load-balancing of traffic destined 198 to the CE, even when the CE is connected to more than one PE. Thus 199 the solution MUST be able to exercise multiple links connected to the 200 CE, irrespective of the number of PEs that the CE is connected to. It 201 should be noted that when a CE is multi-homed to several PEs, there 202 could be multiple IGP ECMP paths from each remote PE to each multi- 203 homed PE. Furthermore, for active/active multi-homed site, a remote 204 PE can choose any of the multi-homed PEs for sending traffic destined 205 to the multi-homed sites. Therefore, when a solution supports 206 active/active multi-homing, it MUST exercise as many of these paths 207 as possible for traffic destined to a multi-homed site. 209 4.2. Flow-based Multi-pathing 211 Any solution that meets the active-active flow based load balancing 212 requirement described in section 3.1 MUST also be able to exercise 213 multiple paths between a given pair of PEs. For instance if there are 214 multiple RSVP-TE LSPs between a pair of PEs then the solution MUST be 215 capable of load balancing traffic between those LSPs on a per flow 216 basis. Similarly if LDP is being used as the transport LSP protocol, 217 then the solution MUST be able to leverage LDP ECMP capabilities. The 218 solution MUST also be able to leverage work in the MPLS WG that is in 219 progress to improve the load balancing capabilities of the network 220 based on entropy labels. 222 It is worth pointing out that flow-based multi-pathing complements 223 flow-based load balancing described in the previous section. 225 4.3. Geo-redundant PE Nodes 227 The PE nodes offering multi-homed connectivity to a CE or access 228 network may be situated in the same physical location (co-located), 229 or may be spread geographically (e.g. in different COs or POPs). The 230 latter is desirable when offering a geo-redundant solution that 231 ensures business continuity for critical applications in the case of 232 power outages, natural disasters, etc. An active/active multi-homing 233 mechanism SHOULD support both co-located as well as geo-redundant PE 234 placement. The latter scenario often means that requiring a dedicated 235 link between the PEs, for the operation of the multi-homing 236 mechanism, is not appealing from cost standpoint. Furthermore, the 237 IGP cost from remote PEs to the pair of PEs in the multi-homed setup 238 cannot be assumed to be the same when those latter PEs are geo- 239 redundant. 241 4.4. Optimal Traffic Forwarding 243 In a typical network, and considering a designated pair of PEs, it is 244 common to find both single-homed as well as multi-homed CEs being 245 connected to those PEs. An active/active multi-homing solution SHOULD 246 support optimal forwarding of unicast traffic for all the following 247 scenarios: 249 i. single-homed CE to single-homed CE 250 ii. single-homed CE to multi-homed CE 251 iii. multi-homed CE to single-homed CE 252 iv. multi-homed CE to multi-homed CE 254 This is especially important in the case of geo-redundant PEs, where 255 having traffic forwarded from one PE to another within the same 256 multi-homed group introduces additional latency, on top of the 257 inefficient use of the PE node's and core nodes' switching capacity. 258 A multi-homed group (also known as a multi-chassis LACP group) is a 259 group of PEs supporting a multi-homed CE. 261 4.5. Flexible Redundancy Grouping Support 263 In order to simplify service provisioning and activation, the multi- 264 homing mechanism SHOULD allow arbitrary grouping of PE nodes into 265 redundancy groups where each redundancy group represents all multi- 266 homed groups that share the same group of PEs. This is best explained 267 with an example: consider three PE nodes - PE1, PE2 and PE3. The 268 multi-homing mechanism MUST allow a given PE, say PE1, to be part of 269 multiple redundancy groups concurrently. For example, there can be a 270 group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3) 271 where CEs could be multi-homed to any one of these three redundancy 272 groups. 274 4.6. Multi-homed Network 276 There are applications, which require an Ethernet network, rather 277 than a single device, to be multi-homed to a group of PEs. The 278 Ethernet network would typically run a resiliency mechanism such as 279 Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection 280 Switching [G.8032]. The PEs may or may not participate in the control 281 protocol of the Ethernet network. For a multi-homed network running 282 [802.1Q] or [G.8032], these protocols require that each VLAN to be 283 active only on one of the multi-homed links. 285 A solution MUST support multi-homed network connectivity with 286 active/standby redundancy. 288 A solution MUST also support multi-homed network with active/active 289 VLAN-based load balancing (i.e. disjoint VLAN sets active on 290 disparate PEs). 292 A solution MAY support multi-homed network with active/active MAC- 293 based load balancing (i.e. different MAC addresses on a VLAN are 294 reachable via different PEs). 296 5. Multicast Optimization Requirements 298 There are environments where the usage of MP2MP LSPs may be desirable 299 for optimizing multicast, broadcast and unknown unicast traffic. 300 [VPLS-MCAST] precludes the usage of MP2MP LSPs since current VPLS 301 solutions require an egress PE to perform learning when it receives 302 unknown uncast packets over a LSP. This is challenging when MP2MP 303 LSPs are used as MP2MP LSPs do not have inherent mechanisms to 304 identify the sender. The usage of MP2MP LSPs for multicast 305 optimization becomes tractable if the need to identify the sender for 306 performing learning is lifted. A solution MUST be able to provide a 307 mechanism that does not require learning when packets are received 308 over a MP2MP LSP. Further a solution MUST be able to provide 309 procedures to use MP2MP LSPs for optimizing delivery of multicast, 310 broadcast and unknown unicast traffic. 312 6. Ease of Provisioning Requirements 314 As L2VPN technologies expand into enterprise deployments, ease of 315 provisioning becomes paramount. Even though current VPLS has auto- 316 discovery mechanism, which allow for single-sided provisioning, 317 further simplifications are required, as outlined below: 319 - Single-sided provisioning behavior MUST be maintained 321 - For deployments where VLAN identifiers are global across the MPLS 322 network (i.e. the network is limited to a maximum of 4K services), it 323 is required that the devices derive the MPLS specific attributes 324 (e.g. VPN ID, BGP RT, etc.) from the VLAN identifier. This way, it is 325 sufficient for the network operator to configure the VLAN 326 identifier(s) on the access circuit, and all the MPLS and BGP 327 parameters required for setting up the service over the core network 328 would be automatically derived without any need for explicit 329 configuration. 331 - Implementations SHOULD revert to using default values for 332 parameters as and where applicable. 334 7. New Service Interface Requirements 336 [MEF] and [IEEE 802.1Q] have the following services specified: 338 - Port mode: in this mode, all traffic on the port is mapped to a 339 single bridge domain and a single corresponding L2VPN service 340 instance. Customer VLAN transparency is guaranteed end-to-end. 342 - VLAN mode: in this mode, each VLAN on the port is mapped to a 343 unique bridge domain and corresponding L2VPN service instance. This 344 mode allows for service multiplexing over the port and supports 345 optional VLAN translation. 347 - VLAN bundling: in this mode, a group of VLANs on the port are 348 collectively mapped to a unique bridge domain and corresponding L2VPN 349 service instance. Customer MAC addresses must be unique across all 350 VLANs mapped to the same service instance. 352 For each of the above services a single bridge domain is assigned per 353 service instance on the PE supporting the associated service. For 354 example, in case of the port mode, a single bridge domain is assigned 355 for all the ports belonging to that service instance regardless of 356 number of VLANs coming through these ports. 358 It is worth noting that the term 'bridge domain' as used above refers 359 to a MAC forwarding table as defined in the IEEE bridge model, and 360 does not denote or imply any specific implementation. 362 [RFC4762] defines two types of VPLS services based on "unqualified 363 and qualified learning" which in turn maps to port mode and VLAN mode 364 respectively. 366 A solution is required to support the above three service types plus 367 two additional service types which are primarily intended for hosted 368 data center applications and are described below. 370 For hosted data center interconnect applications, network operators 371 require the ability to extend Ethernet VLANs over a WAN using a 372 single L2VPN instance while maintaining data-plane separation between 373 the various VLANs associated with that instance. This gives rise to 374 two new service interface types: VLAN-aware Bundling without 375 Translation, and VLAN-aware Bundling with Translation. 377 The VLAN-aware Bundling without Translation service interface has the 378 following characteristics: 380 - The service interface MUST provide bundling of customer VLANs into 381 a single L2VPN service instance. 383 - The service interface MUST guarantee customer VLAN transparency 384 end-to-end. 386 - The service interface MUST maintain data-plane separation between 387 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 389 - In the special case of all-to-one bundling, the service interface 390 MUST NOT assume any a priori knowledge of the customer VLANs. In 391 other words, the customer VLANs shall not be configured on the PE, 392 rather the interface is configured just like a port-based service. 394 The VLAN-aware Bundling with Translation service interface has the 395 following characteristics: 397 - The service interface MUST provide bundling of customer VLANs into 398 a single L2VPN service instance. 400 - The service interface MUST maintain data-plane separation between 401 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 403 - The service interface MUST support customer VLAN translation to 404 handle the scenario where different VLAN Identifiers (VIDs) are used 405 on different interfaces to designate the same customer VLAN. 407 The main difference, in terms of service provider resource 408 allocation, between these new service types and the previously 409 defined three types is that the new services require several bridge 410 domains to be allocated (one per customer VLAN) per L2VPN service 411 instance as opposed to a single bridge domain per L2VPN service 412 instance. 414 8. Fast Convergence 416 A solution MUST provide the ability to recover from PE-CE attachment 417 circuit failures as well as PE node failure for the case of both 418 multi-homed device and multi-homed network. The recovery mechanism(s) 419 MUST provide convergence time that is independent of the number of 420 MAC addresses learned by the PE. This is particularly important in 421 the context of virtualization applications which are fueling an 422 increase in the number of MAC addresses to be handled by the Layer 2 423 network. Furthermore, the recovery mechanism(s) SHOULD provide 424 convergence time that is independent of the number of service 425 instances associated with the attachment circuit or PE. 427 9. Flood Suppression 429 The solution SHOULD allow the network operator to choose whether 430 unknown unicast frames are to be dropped or to be flooded. This 431 attribute need to be configurable on a per service instance basis. 433 In addition, for the case where the solution is used for data-center 434 interconnect, it is required to minimize the flooding of broadcast 435 frames outside the confines of a given site. Of particular interest 436 is periodic ARP traffic. 438 Furthermore, it is required to eliminate any unnecessary flooding of 439 unicast traffic upon topology changes, especially in the case of 440 multi-homed site where the PEs have a priori knowledge of the backup 441 paths for a given MAC address. 443 10. Supporting Flexible VPN Topologies and Policies 445 A solution MUST be capable of supporting flexible VPN topologies that 446 are not constrained by the underlying mechanisms of the solution. One 447 example of this is E-TREE topology where one or more sites in the VPN 448 are roots and the others as leafs. The roots are allowed to send 449 traffic to other roots and to leafs, while leafs can communicate only 450 with other roots. The solution MUST provide the ability to support E- 451 TREE topology. Further the solution MUST provide the ability to apply 452 policies at the MAC address granularity to control which PEs in the 453 VPN learn which MAC address and how a specific MAC address is 454 forwarded. It MUST be possible to apply policies to allow only some 455 of the member PEs in the VPN to send or receive traffic for a 456 particular MAC address. 458 11. Security Considerations 460 For scenarios where MAC learning is performed in data-plane, there 461 are no additional security aspects beyond those considered in 462 [RFC4761] and [RFC4762]. And for scenarios where MAC learning is 463 performed in control plane (via BGP), there are no additional 464 security aspects beyond those considered in [RFC4364]. 466 12. IANA Considerations 468 None. 470 13. Normative References 471 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 472 August 1996. 474 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 475 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 476 4761, January 2007. 478 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 479 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 480 RFC 4762, January 2007. 482 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", February 483 2006. 485 [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 486 metropolitan area networks - Link Aggregation", IEEE 487 Computer Society, November 2008. 489 [802.1Q] IEEE Std. 802.1Q-2009, "IEEE Standard for Local and 490 metropolitan area networks - Virtual Bridged Local Area 491 Networks", 2009. 493 [RFC6074] E. Rosen and B. Davie, "Provisioning, Auto-Discovery, and 494 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 495 January 2011. 497 14. Informative References 498 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 499 September 2006. 501 [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual 502 Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 503 03, work in progress, November, 2009. 505 [VPLS-MCAST] Aggarwal et al., "Multicast in VPLS", draft-ietf-l2vpn- 506 vpls-mcast-11.txt, work in progress, March, 2010. 508 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for 509 L2VPN PE Redundancy", draft-ietf-pwe3-iccp-09.txt, work in 510 progress, Octoer, 2009. 512 [VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf- 513 l2vpn-vpls-mcast-11.txt, work in progress, July 2012. 515 [MEF] MEF 6.1 Technical Specification, "Ethernet Service 516 Definitions", April 2008. 518 15. Author's Address 520 Ali Sajassi 521 Cisco 522 Email: sajassi@cisco.com 524 Rahul Aggarwal 525 Email: raggarwa_1@yahoo.com 527 Wim Henderickx 528 Alcatel-Lucent 529 e-mail: wim.henderickx@alcatel-lucent.com 531 Aldrin Isaac 532 Bloomberg 533 Email: aisaac71@bloomberg.net 535 James Uttaro 536 AT&T 537 200 S. Laurel Avenue 538 Middletown, NJ 07748 539 USA 540 Email: uttaro@att.com 542 Nabil Bitar 543 Verizon Communications 544 Email : nabil.n.bitar@verizon.com 546 John Drake 547 Juniper Networks 548 1194 N. Mathilda Ave. 549 Sunnyvale, CA 94089 US 550 Email: jdrake@juniper.net 552 Clarence Filsfils 553 Cisco 554 Email: cfilsfil@cisco.com 556 Samer Salam 557 Cisco 558 Email: ssalam@cisco.com