idnits 2.17.1 draft-ietf-l2vpn-evpn-req-03.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 (May 30, 2013) is 3977 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.8032' is mentioned on line 309, but not defined == Missing Reference: 'RFC 4364' is mentioned on line 490, 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: November 30, 2013 May 30, 2013 16 Requirements for Ethernet VPN (E-VPN) 17 draft-ietf-l2vpn-evpn-req-03.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 Virtual Private LAN Service (VPLS) 61 solution. In particular, multi-homing with all-active forwarding is 62 not supported and there's no existing solution to leverage 63 Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of 64 multi-destination frames. Furthermore, the provisioning of VPLS, even 65 in the context of BGP-based auto-discovery, requires network 66 operators to specify various network parameters on top of the access 67 configuration. This document specifies the requirements for an 68 Ethernet VPN (E-VPN) solution which addresses the above issues. 70 Table of Contents 72 1. Specification of requirements . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Redundancy Requirements . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Flow-based Load Balancing . . . . . . . . . . . . . . . . 5 77 4.2. Flow-based Multi-pathing . . . . . . . . . . . . . . . . . 6 78 4.3. Geo-redundant PE Nodes . . . . . . . . . . . . . . . . . . 7 79 4.4. Optimal Traffic Forwarding . . . . . . . . . . . . . . . . 7 80 4.5. Flexible Redundancy Grouping Support . . . . . . . . . . . 8 81 4.6. Multi-homed Network . . . . . . . . . . . . . . . . . . . 8 82 5. Multicast Optimization Requirements . . . . . . . . . . . . . . 9 83 6. Ease of Provisioning Requirements . . . . . . . . . . . . . . . 9 84 7. New Service Interface Requirements . . . . . . . . . . . . . . 9 85 8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . 11 86 9. Flood Suppression . . . . . . . . . . . . . . . . . . . . . . . 11 87 10. Supporting Flexible VPN Topologies and Policies . . . . . . . 12 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 14. Normative References . . . . . . . . . . . . . . . . . . . . . 12 92 14. Informative References . . . . . . . . . . . . . . . . . . . . 13 93 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Specification of requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Terminology 103 AS: Autonomous System 104 CE: Customer Edge 105 E-Tree: Ethernet tree 106 E-VPN: Ethernet Virtual Private Network 107 MAC address: Media Access Control address - simply referred to as MAC 108 MHD: Multi-homed Device 109 MHN: Multi-homed Network 110 LACP: Link Aggregation Control Protocol 111 LSP: Label Switched Path 112 PE: Provider Edge 113 MP2MP: Multipoint to Multipoint 114 P2MP: Point to Multipoint 115 P2P:Point to Point 116 RT: Route Target 117 VPLS: Virtual Private LAN Service 118 VPMS: Virtual Private Multicast Service 120 3. 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 other L2VPN 127 services such as E-TREE, VPWS, and VPMS. 129 In the area of multi-homing current VPLS can only support multi- 130 homing with active/standby resiliency model, for example 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][RFC6074]. 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 by 154 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 4 discusses the redundancy requirements. Section 5 describes 168 the multicast optimization requirements. Section 6 articulates the 169 ease of provisioning requirements. Section 7 focuses on the new 170 service interface requirements. Section 8 highlights the fast 171 convergence requirements. Section 9 describes the flood suppression 172 requirement, and finally section 10 discusses the requirements for 173 supporting flexible VPN topologies and policies. 175 4. Redundancy Requirements 177 4.1. Flow-based Load Balancing 179 A common mechanism for multi-homing a CE node to a set of PE nodes 180 involves leveraging multi-chassis Ethernet link aggregation groups 181 based on [802.1AX] LACP. [PWE3-ICCP] describes one such scheme. In 182 Ethernet link aggregation, the load-balancing algorithms by which a 183 CE distributes traffic over the Attachment Circuits connecting to the 184 PEs are quite flexible. The only requirement is for the algorithm to 185 ensure in-order frame delivery for a given traffic flow. In typical 186 implementations, these algorithms involve selecting an outbound link 187 within the bundle based on a hash function that identifies a flow 188 based on one or more of the following fields: 190 i. Layer 2: Source MAC Address, Destination MAC Address, VLAN 191 ii. Layer 3: Source IP Address, Destination IP Address 192 iii. Layer 4: UDP or TCP Source Port, Destination Port 194 A key point to note here is that [802.1AX] does not define a standard 195 load-balancing algorithm for Ethernet bundles, and as such different 196 implementations behave differently. As a matter of fact, a bundle 197 operates correctly even in the presence of asymmetric load-balancing 198 over the links. This being the case, the first requirement for 199 active/active multi-homing is the ability to accommodate flexible 200 flow-based load-balancing from the CE node based on L2, L3 and/or L4 201 header fields. 203 A solution MUST be capable of supporting flexible flow-based load 204 balancing from the CE as described above. Further the MPLS network 205 MUST be able to support flow-based load-balancing of traffic destined 206 to the CE, even when the CE is connected to more than one PE. Thus 207 the solution MUST be able to exercise multiple links connected to the 208 CE, irrespective of the number of PEs that the CE is connected to. It 209 should be noted that when a CE is multi-homed to several PEs, there 210 could be multiple ECMP paths from each remote PE to each multi-homed 211 PE. Furthermore, for active/active multi-homed site, a remote PE can 212 choose any of the multi-homed PEs for sending traffic destined to the 213 multi-homed sites. Therefore, when a solution supports active/active 214 multi-homing, it MUST exercise as many of these paths as possible for 215 traffic destined to a multi-homed site. 217 A solution MAY support flow-based load balancing among PEs that are 218 members of a redundancy group spanning multiple ASes. 220 4.2. Flow-based Multi-pathing 222 Any solution that meets the active-active flow based load balancing 223 requirement described in section 4.1 MUST also be able to exercise 224 multiple paths between a given pair of PEs. For instance, if there 225 are multiple RSVP-TE LSPs between a pair of PEs then the solution 226 MUST be capable of load balancing traffic among those LSPs on a per 227 flow basis. Similarly, if LDP is being used as the signaling protocol 228 for transport LSPs, then the solution MUST be able to leverage those 229 LDP signaled equal cost LSPs. The solution MUST also be able to 230 leverage work in the MPLS WG that is in progress to improve the load 231 balancing capabilities of the network based on entropy labels 232 [RFC6790]. 234 It is worth pointing out that flow-based multi-pathing complements 235 flow-based load balancing described in the previous section. 237 4.3. Geo-redundant PE Nodes 239 The PE nodes offering multi-homed connectivity to a CE or access 240 network may be situated in the same physical location (co-located), 241 or may be spread geographically (e.g., in different COs or POPs). The 242 latter is desirable when offering a geo-redundant solution that 243 ensures business continuity for critical applications in the case of 244 power outages, natural disasters, etc. An active/active multi-homing 245 mechanism SHOULD support both co-located as well as geo-redundant PE 246 placement. The latter scenario often means that requiring a dedicated 247 link between the PEs, for the operation of the multi-homing 248 mechanism, is not appealing from a cost standpoint. Furthermore, the 249 IGP cost from remote PEs to the pair of PEs in the dual-homed setup 250 cannot be assumed to be the same when those latter PEs are geo- 251 redundant. 253 A solution MUST support active/active multi-homing without the need 254 for a dedicated control/data link among the PEs in the multi-homed 255 group. 257 A solution MUST NOT assume that the IGP cost from a remote PE to each 258 of the PEs in the multi-homed group is the same. 260 A solution MUST support multi-homing across different IGP domains 261 within the same Autonomous System. 263 A solution SHOULD support multi-homing across multiple Autonomous 264 Systems. 266 4.4. Optimal Traffic Forwarding 268 In a typical network, and considering a designated pair of PEs, it is 269 common to find both single-homed as well as multi-homed CEs being 270 connected to those PEs. An active/active multi-homing solution SHOULD 271 support optimal forwarding of unicast traffic for all the following 272 scenarios. By "optimal forwarding", we mean that traffic will not to 273 be forwarded between PE devices that are members of a multi-home 274 group unless the destination CE is attached to one of the multi-homed 275 PEs. 277 i. single-homed CE to single-homed CE 278 ii. single-homed CE to multi-homed CE 279 iii. multi-homed CE to single-homed CE 280 iv. multi-homed CE to multi-homed CE 281 This is especially important in the case of geo-redundant PEs, where 282 having traffic forwarded from one PE to another within the same 283 multi-homed group introduces additional latency, on top of the 284 inefficient use of the PE node's and core nodes' switching capacity. 285 A multi-homed group (also known as a multi-chassis LAG) is a group of 286 PEs supporting a multi-homed CE. 288 4.5. Flexible Redundancy Grouping Support 290 In order to simplify service provisioning and activation, the multi- 291 homing mechanism SHOULD allow arbitrary grouping of PE nodes into 292 redundancy groups where each redundancy group represents all multi- 293 homed groups that share the same group of PEs. This is best explained 294 with an example: consider three PE nodes - PE1, PE2 and PE3. The 295 multi-homing mechanism MUST allow a given PE, say PE1, to be part of 296 multiple redundancy groups concurrently. For example, there can be a 297 group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3) 298 where CEs could be multi-homed to any one of these three redundancy 299 groups. 301 4.6. Multi-homed Network 303 There are applications, which require an Ethernet network, rather 304 than a single device, to be multi-homed to a group of PEs. The 305 Ethernet network would typically run a resiliency mechanism such as 306 Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection 307 Switching [G.8032]. The PEs may or may not participate in the control 308 protocol of the Ethernet network. For a multi-homed network running 309 [802.1Q] or [G.8032], these protocols require that each VLAN to be 310 active only on one of the multi-homed links. 312 A solution MUST support multi-homed network connectivity with 313 active/standby redundancy. 315 A solution MUST also support multi-homed network with active/active 316 VLAN-based load balancing (i.e. disjoint VLAN sets active on 317 disparate PEs). 319 A solution MAY support VLAN-based load balancing among PEs that are 320 member of a redundancy group spanning multiple ASes. 322 A solution MAY support multi-homed network with active/active MAC- 323 based load balancing (i.e. different MAC addresses on a VLAN are 324 reachable via different PEs). 326 5. Multicast Optimization Requirements 328 There are environments where the usage of MP2MP LSPs may be desirable 329 for optimizing multicast, broadcast and unknown unicast traffic in 330 order to reduce the amount of multicast states in the core routers. 331 [VPLS-MCAST] precludes the usage of MP2MP LSPs since current VPLS 332 solutions require an egress PE to perform learning when it receives 333 unknown unicast packets over a LSP. This is challenging when MP2MP 334 LSPs are used as MP2MP LSPs do not have inherent mechanisms to 335 identify the sender. The usage of MP2MP LSPs for multicast 336 optimization becomes tractable if the need to identify the sender for 337 performing learning is lifted. A solution MUST be able to provide a 338 mechanism that does not require learning when packets are received 339 over a MP2MP LSP. Further a solution MUST be able to provide 340 procedures to use MP2MP LSPs for optimizing delivery of multicast, 341 broadcast and unknown unicast traffic. 343 6. Ease of Provisioning Requirements 345 As L2VPN technologies expand into enterprise deployments, ease of 346 provisioning becomes paramount. Even though current VPLS has an auto- 347 discovery mechanism, which enables for single-sided provisioning, 348 further simplifications are required, as outlined below: 350 - Single-sided provisioning behavior MUST be maintained. 352 - For deployments where VLAN identifiers are global across the MPLS 353 network (i.e. the network is limited to a maximum of 4K services), it 354 is required that the devices derive the MPLS specific attributes 355 (e.g., VPN ID, BGP RT, etc.) from the VLAN identifier. This way, it 356 is sufficient for the network operator to configure the VLAN 357 identifier(s) for the access circuit, and all the MPLS and BGP 358 parameters required for setting up the service over the core network 359 would be automatically derived without any need for explicit 360 configuration. 362 - Implementations SHOULD revert to using default values for 363 parameters as and where applicable. 365 7. New Service Interface Requirements 367 [MEF] and [IEEE 802.1Q] have the following services specified: 369 - Port mode: in this mode, all traffic on the port is mapped to a 370 single bridge domain and a single corresponding L2VPN service 371 instance. Customer VLAN transparency is guaranteed end-to-end. 373 - VLAN mode: in this mode, each VLAN on the port is mapped to a 374 unique bridge domain and corresponding L2VPN service instance. This 375 mode allows for service multiplexing over the port and supports 376 optional VLAN translation. 378 - VLAN bundling: in this mode, a group of VLANs on the port are 379 collectively mapped to a unique bridge domain and corresponding L2VPN 380 service instance. Customer MAC addresses must be unique across all 381 VLANs mapped to the same service instance. 383 For each of the above services a single bridge domain is assigned per 384 service instance on the PE supporting the associated service. For 385 example, in case of the port mode, a single bridge domain is assigned 386 for all the ports belonging to that service instance regardless of 387 number of VLANs coming through these ports. 389 It is worth noting that the term 'bridge domain' as used above refers 390 to a MAC forwarding table as defined in the IEEE bridge model, and 391 does not denote or imply any specific implementation. 393 [RFC4762] defines two types of VPLS services based on "unqualified 394 and qualified learning" which in turn maps to port mode and VLAN mode 395 respectively. 397 A solution is required to support the above three service types plus 398 two additional service types which are primarily intended for hosted 399 data center applications and are described below. 401 For hosted data center interconnect applications, network operators 402 require the ability to extend Ethernet VLANs over a WAN using a 403 single L2VPN instance while maintaining data-plane separation between 404 the various VLANs associated with that instance. This gives rise to 405 two new service interface types: VLAN-aware Bundling without 406 Translation, and VLAN-aware Bundling with Translation. 408 The VLAN-aware Bundling without Translation service interface has the 409 following characteristics: 411 - The service interface MUST provide bundling of customer VLANs into 412 a single L2VPN service instance. 414 - The service interface MUST guarantee customer VLAN transparency 415 end-to-end. 417 - The service interface MUST maintain data-plane separation between 418 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 420 - In the special case of all-to-one bundling, the service interface 421 MUST NOT assume any a priori knowledge of the customer VLANs. In 422 other words, the customer VLANs shall not be configured on the PE, 423 rather the interface is configured just like a port-based service. 425 The VLAN-aware Bundling with Translation service interface has the 426 following characteristics: 428 - The service interface MUST provide bundling of customer VLANs into 429 a single L2VPN service instance. 431 - The service interface MUST maintain data-plane separation between 432 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 434 - The service interface MUST support customer VLAN translation to 435 handle the scenario where different VLAN Identifiers (VIDs) are used 436 on different interfaces to designate the same customer VLAN. 438 The main difference, in terms of service provider resource 439 allocation, between these new service types and the previously 440 defined three types is that the new services require several bridge 441 domains to be allocated (one per customer VLAN) per L2VPN service 442 instance as opposed to a single bridge domain per L2VPN service 443 instance. 445 8. Fast Convergence 447 A solution MUST provide the ability to recover from PE-CE attachment 448 circuit failures as well as PE node failure for the case of both 449 multi-homed device and multi-homed network. The recovery mechanism(s) 450 MUST provide convergence time that is independent of the number of 451 MAC addresses learned by the PE. This is particularly important in 452 the context of virtualization applications which are fueling an 453 increase in the number of MAC addresses to be handled by the Layer 2 454 network. Furthermore, the recovery mechanism(s) SHOULD provide 455 convergence time that is independent of the number of service 456 instances associated with the attachment circuit or the PE. 458 9. Flood Suppression 460 The solution SHOULD allow the network operator to choose whether 461 unknown unicast frames are to be dropped or to be flooded. This 462 attribute needs to be configurable on a per service instance basis. 464 In addition, for the case where the solution is used for data-center 465 interconnect, it is required to minimize the flooding of broadcast 466 frames outside the confines of a given site. Of particular interest 467 is periodic ARP traffic. 469 Furthermore, it is required to eliminate any unnecessary flooding of 470 unicast traffic upon topology changes, especially in the case of 471 multi-homed site where the PEs have a priori knowledge of the backup 472 paths for a given MAC address. 474 10. Supporting Flexible VPN Topologies and Policies 476 A solution MUST be capable of supporting flexible VPN topologies that 477 are not constrained by the underlying mechanisms of the solution. One 478 example of this is E-TREE topology where one or more sites in the VPN 479 are roots and the others as leaves. The roots are allowed to send 480 traffic to other roots and to leaves, while leaves can communicate 481 only with the roots. The solution MUST provide the ability to support 482 E-TREE topology. Further the solution MUST provide the ability to 483 apply policies at the MAC address granularity to control which PEs in 484 the VPN learn which MAC address and how a specific MAC address is 485 forwarded. It MUST be possible to apply policies to allow only some 486 of the member PEs in the VPN to send or receive traffic for a 487 particular MAC address. 489 A solution MUST be capable of supporting both inter-AS option-C and 490 inter-AS option-B scenarios as described in [RFC 4364]. 492 11. Contributors 494 Samer Salam, Cisco, ssalam@cisco.com 495 John Drake, Juniper, jdrake@juniper.net 496 Clarence Filsfils, Cisco, cfilsfil@cisco.com 498 12. Security Considerations 500 For scenarios where MAC learning is performed in the data-plane, 501 there are no additional security aspects beyond those considered in 502 [RFC4761] and [RFC4762]. And for scenarios where MAC learning is 503 performed in the control plane (via BGP), there are no additional 504 security aspects beyond those considered in [RFC4364]. 506 13. IANA Considerations 508 None. 510 14. Normative References 511 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 512 August 1996. 514 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 515 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 516 4761, January 2007. 518 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 519 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 520 RFC 4762, January 2007. 522 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", February 523 2006. 525 [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 526 metropolitan area networks - Link Aggregation", IEEE 527 Computer Society, November 2008. 529 [802.1Q] IEEE Std. 802.1Q-2011, "IEEE Standard for Local and 530 metropolitan area networks - Virtual Bridged Local Area 531 Networks", 2011. 533 [RFC6074] E. Rosen and B. Davie, "Provisioning, Auto-Discovery, and 534 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 535 January 2011. 537 14. Informative References 538 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 539 September 2006. 541 [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual 542 Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 543 03, work in progress, November, 2009. 545 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for 546 L2VPN PE Redundancy", draft-ietf-pwe3-iccp-09.txt, work in 547 progress, Octoer, 2009. 549 [VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf- 550 l2vpn-vpls-mcast-11.txt, work in progress, July 2012. 552 [MEF] MEF 6.1 Technical Specification, "Ethernet Service 553 Definitions", April 2008. 555 [RFC6790] K. Kompella et al., "The Use of Entropy Labels in MPLS 556 Forwarding", RFC 6790, November 2012. 558 15. Author's Address 559 Ali Sajassi 560 Cisco 561 Email: sajassi@cisco.com 563 Rahul Aggarwal 564 Arktan 565 Email: raggarwa_1@yahoo.com 567 Wim Henderickx 568 Alcatel-Lucent 569 Email: wim.henderickx@alcatel-lucent.com 571 Aldrin Isaac 572 Bloomberg 573 Email: aisaac71@bloomberg.net 575 James Uttaro 576 AT&T 577 Email: uttaro@att.com 579 Nabil Bitar 580 Verizon Communications 581 Email : nabil.n.bitar@verizon.com