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