Internet Working Group A. Sajassi INTERNET-DRAFT Cisco Category: Informational R. Aggarwal J. Uttaro Arktan AT&T N. Bitar W. Henderickx Verizon Alcatel-Lucent Aldrin Isaac Bloomberg Expires: April 15, 2014 October 15, 2013 Requirements for Ethernet VPN (EVPN) draft-ietf-l2vpn-evpn-req-05.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Sajassi, et al. Expires April 15, 2014 [Page 1]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution which addresses the above issues. Table of Contents 1. Specification of requirements . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Redundancy Requirements . . . . . . . . . . . . . . . . . . . . 6 4.1. Flow-based Load Balancing . . . . . . . . . . . . . . . . 6 4.2. Flow-based Multi-pathing . . . . . . . . . . . . . . . . . 7 4.3. Geo-redundant PE Nodes . . . . . . . . . . . . . . . . . . 7 4.4. Optimal Traffic Forwarding . . . . . . . . . . . . . . . . 8 4.5. Flexible Redundancy Grouping Support . . . . . . . . . . . 8 4.6. Multi-homed Network . . . . . . . . . . . . . . . . . . . 9 5. Multicast Optimization Requirements . . . . . . . . . . . . . . 9 6. Ease of Provisioning Requirements . . . . . . . . . . . . . . . 10 7. New Service Interface Requirements . . . . . . . . . . . . . . 10 8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . 12 9. Flood Suppression . . . . . . . . . . . . . . . . . . . . . . . 13 10. Supporting Flexible VPN Topologies and Policies . . . . . . . 13 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 14. Normative References . . . . . . . . . . . . . . . . . . . . . 14 14. Informative References . . . . . . . . . . . . . . . . . . . . 14 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Sajassi, et al. Expires April 15, 2014 [Page 2]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 Sajassi, et al. Expires April 15, 2014 [Page 3]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology AS: Autonomous System CE: Customer Edge E-Tree: Ethernet tree MAC address: Media Access Control address - referred to as MAC LSP: Label Switched Path PE: Provider Edge MP2MP: Multipoint to Multipoint VPLS: Virtual Private LAN Service Single-Active Mode: When a device or a network is multi-homed to two or more PEs and when only a single PE in such redundancy group can forward traffic to/from the multi-homed device or network for a given VLAN, then such multi-homing or redundancy is referred to as "Single- Active". All-Active: When a device is multi-homed to two or more PEs and when all PEs in such redundancy group can forward traffic to/from the multi-homed device for a given VLAN, then such multi-homing or redundancy is referred to as "All-Active". 3. Introduction VPLS, as defined in [RFC4664][RFC4761][RFC4762], is a proven and widely deployed technology. However, the existing solution has a number of limitations when it comes to redundancy, multicast optimization and provisioning simplicity. Furthermore, new applications are driving several new requirements for other L2VPN services such as E-TREE, and VPWS. In the area of multi-homing current VPLS can only support multi- Sajassi, et al. Expires April 15, 2014 [Page 4]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 homing with active/standby resiliency model, for example as described in [VPLS-BGP-MH]. Flexible multi-homing with all-active Attachment Circuits (ACs) cannot be supported by current VPLS solution. In the area of multicast optimization, [VPLS-MCAST] describes how multicast LSPs can be used in conjunction with VPLS. However, this solution is limited to Point-to-Multipoint (P2MP) LSPs, as there's no defined solution for leveraging Multipoint-to-Multipoint (MP2MP) LSPs with VPLS. In the area of provisioning simplicity, current VPLS does offer a mechanism for single-sided provisioning by relying on BGP-based service auto-discovery [RFC4761][RFC6074]. This, however, still requires the operator to configure a number of network-side parameters on top of the access-side Ethernet configuration. Furthermore, data center interconnect applications are driving the need for new service interface types which are a hybrid combination of VLAN Bundling and VLAN-based service interfaces. These are referred to as "VLAN-aware Bundling" service interfaces. Also virtualization applications are fueling an increase in the volume of MAC addresses that are to be handled by the network, which gives rise to the requirement for having the network re-convergence upon failure be independent of the number of MAC addresses learned by the PE. In addition, there are requirements for minimizing the amount of flooding of multi-destination frames and localizing the flooding to the confines of a given site. Moreover, there are requirements for supporting flexible VPN topologies and policies beyond those currently covered by (H-)VPLS. The focus of this document is on defining the requirements for a new solution, namely Ethernet VPN (EVPN), which addresses the above issues. Section 4 discusses the redundancy requirements. Section 5 describes the multicast optimization requirements. Section 6 articulates the ease of provisioning requirements. Section 7 focuses on the new service interface requirements. Section 8 highlights the fast convergence requirements. Section 9 describes the flood suppression requirement, and finally section 10 discusses the requirements for supporting flexible VPN topologies and policies. Sajassi, et al. Expires April 15, 2014 [Page 5]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 4. Redundancy Requirements 4.1. Flow-based Load Balancing A common mechanism for multi-homing a CE node to a set of PE nodes involves leveraging multi-chassis Ethernet link aggregation groups based on [802.1AX]. [PWE3-ICCP] describes one such scheme. In Ethernet link aggregation, the load-balancing algorithms by which a CE distributes traffic over the Attachment Circuits connecting to the PEs are quite flexible. The only requirement is for the algorithm to ensure in-order frame delivery for a given traffic flow. In typical implementations, these algorithms involve selecting an outbound link within the bundle based on a hash function that identifies a flow based on one or more of the following fields: i. Layer 2: Source MAC Address, Destination MAC Address, VLAN ii. Layer 3: Source IP Address, Destination IP Address iii. Layer 4: UDP or TCP Source Port, Destination Port A key point to note here is that [802.1AX] does not define a standard load-balancing algorithm for Ethernet bundles, and as such different implementations behave differently. As a matter of fact, a bundle operates correctly even in the presence of asymmetric load-balancing over the links. This being the case, the first requirement for all- active multi-homing is the ability to accommodate flexible flow-based load-balancing from the CE node based on L2, L3 and/or L4 header fields. (R1a) A solution MUST be capable of supporting flexible flow-based load balancing from the CE as described above. (R1b) A solution MUST also be able to support flow-based load- balancing of traffic destined to the CE, even when the CE is connected to more than one PE. Thus the solution MUST be able to exercise multiple links connected to the CE, irrespective of the number of PEs that the CE is connected to. It should be noted that when a CE is multi-homed to several PEs, there could be multiple ECMP paths from each remote PE to each multi- homed PE. Furthermore, for all-active multi-homed CE, a remote PE can choose any of the multi-homed PEs for sending traffic destined to the multi-homed CE. Therefore, when a solution supports all-active multi- homing, it MUST exercise as many of these paths as possible for traffic destined to a multi-homed CE. (R1c) A solution MAY support flow-based load balancing among PEs that are members of a redundancy group spanning multiple Autonomous Systems. Sajassi, et al. Expires April 15, 2014 [Page 6]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 4.2. Flow-based Multi-pathing Any solution that meets the all-active flow based load balancing requirement described in section 4.1 MUST also be able to exercise multiple paths between a given pair of PEs. For instance, if there are multiple RSVP-TE LSPs between a pair of PEs then the solution MUST be capable of load balancing traffic among those LSPs on a per flow basis. Similarly, if LDP is being used as the signaling protocol for transport LSPs, then the solution MUST be able to leverage LDP signaled equal cost LSPs. The solution MUST also be able to leverage work in the MPLS WG that is in progress to improve the load balancing capabilities of the network based on entropy labels [RFC6790]. (R2) A solution MUST be able to exercise as many ECMP paths as possible between any pair of PEs in conjunction with the all-active load-balancing described above. For example consider a scenario in which CE1 is multi-homed to PE1 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active mode. Furthermore, consider that there exist three ECMPs between any of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can be forwarded on twelve different paths over MPLS/IP core as follow: CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths. Finally, when traffic arrives at PE3 and PE4, it gets forwarded to CE2 over the Ethernet channel (aka link bundle). It is worth pointing out that flow-based multi-pathing complements flow-based load balancing described in the previous section. 4.3. Geo-redundant PE Nodes The PE nodes offering multi-homed connectivity to a CE or access network may be situated in the same physical location (co-located), or may be spread geographically (e.g., in different COs or POPs). The latter is desirable when offering a geo-redundant solution that ensures business continuity for critical applications in the case of power outages, natural disasters, etc. An all-active multi-homing mechanism SHOULD support both co-located as well as geo-redundant PE placement. The latter scenario often means that requiring a dedicated link between the PEs, for the operation of the multi-homing mechanism, is not appealing from a cost standpoint. Furthermore, the IGP cost from remote PEs to the pair of PEs in the dual-homed setup cannot be assumed to be the same when those latter PEs are geo- redundant. (R3a) A solution MUST support all-active multi-homing without the Sajassi, et al. Expires April 15, 2014 [Page 7]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 need for a dedicated control/data link among the PEs in the multi- homed group. (R3b) A solution MUST NOT assume that the IGP cost from a remote PE to each of the PEs in the multi-homed group is the same. (R3c) A solution MUST support multi-homing across different IGP domains within the same Autonomous System. (R3d) A solution SHOULD support multi-homing across multiple Autonomous Systems. 4.4. Optimal Traffic Forwarding In a typical network, and considering a designated pair of PEs, it is common to find both single-homed as well as multi-homed CEs being connected to those PEs. R4: An all-active multi-homing solution SHOULD support optimal forwarding of unicast traffic for all the following scenarios. By "optimal forwarding", we mean that traffic will not be forwarded between PE devices that are members of a multi-home group unless the destination CE is attached to one of the multi-homed PEs. i. single-homed CE to multi-homed CE ii. multi-homed CE to single-homed CE iii. multi-homed CE to multi-homed CE This is especially important in the case of geo-redundant PEs, where having traffic forwarded from one PE to another within the same multi-homed group introduces additional latency, on top of the inefficient use of the PE node's and core nodes' switching capacity. A multi-homed group (also known as a multi-chassis LAG) is a group of PEs supporting a multi-homed CE. 4.5. Flexible Redundancy Grouping Support (R5) In order to simplify service provisioning and activation, the multi-homing mechanism SHOULD allow arbitrary grouping of PE nodes into redundancy groups where each redundancy group represents all multi-homed groups that share the same group of PEs. This is best explained with an example: consider three PE nodes - PE1, PE2 and PE3. The multi-homing mechanism MUST allow a given PE, say PE1, to be part of multiple redundancy groups concurrently. For example, there can be a group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3) where CEs could be multi-homed to any one of Sajassi, et al. Expires April 15, 2014 [Page 8]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 these three redundancy groups. 4.6. Multi-homed Network There are applications, which require an Ethernet network, rather than a single device, to be multi-homed to a group of PEs. The Ethernet network would typically run a resiliency mechanism such as Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection Switching [G.8032]. The PEs may or may not participate in the control protocol of the Ethernet network. For a multi-homed network running [802.1Q] or [G.8032], these protocols require that each VLAN to be active only on one of the multi-homed links. (R6a) A solution MUST support multi-homed network connectivity with active/standby redundancy. (R6b) A solution MUST also support multi-homed network with all- active VLAN-based load balancing (i.e. disjoint VLAN sets active on disparate PEs). (R6c) A solution MAY support VLAN-based load balancing among PEs that are member of a redundancy group spanning multiple ASes. (R6d) A solution MAY support multi-homed network with all-active MAC- based load balancing (i.e. different MAC addresses on a VLAN are reachable via different PEs). 5. Multicast Optimization Requirements There are environments where the usage of MP2MP LSPs may be desirable for optimizing multicast, broadcast and unknown unicast traffic in order to reduce the amount of multicast states in the core routers. [VPLS-MCAST] precludes the usage of MP2MP LSPs since current VPLS solutions require an egress PE to perform learning when it receives unknown unicast packets over a LSP. This is challenging when MP2MP LSPs are used, as MP2MP LSPs do not have inherent mechanisms to identify the sender. The usage of MP2MP LSPs for multicast optimization becomes tractable if the need to identify the sender for performing learning is lifted. (R7a) A solution MUST be able to provide a mechanism that does not require MAC learning against MPLS LSPs when packets are received over a MP2MP LSP. (R7b) A solution SHOULD be able to provide procedures to use MP2MP LSPs for optimizing delivery of multicast, broadcast and unknown Sajassi, et al. Expires April 15, 2014 [Page 9]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 unicast traffic. 6. Ease of Provisioning Requirements As L2VPN technologies expand into enterprise deployments, ease of provisioning becomes paramount. Even though current VPLS has an auto- discovery mechanism, which enables automated discovery of member PEs belonging to a given VPN instance over the MPLS/IP core network, further simplifications are required, as outlined below: (R8a) The solution MUST support auto-discovery of VPN member PEs over MPLS/IP core network similar to VPLS auto-discovery mechanism described in [RFC4761] and [RFC6074]. (R8b) The solution SHOULD support auto-discovery of PEs belonging to a given redundancy or multi-homed group. (R8c) The solution SHOULD support auto-sensing of the site-id for a multi-homed device or network, and support auto-generation of the redundancy group-id based on the site-id. (R8d) The solution SHOULD support automated Designated Forwarder (DF) election among PEs participating in a redundancy (multi-homing) group and to be able to divide service instances (e.g., VLANs) among member PEs of the redundancy group. (R8e) For deployments where VLAN identifiers are global across the MPLS network (i.e. the network is limited to a maximum of 4K services), the PE devices SHOULD derive the MPLS specific attributes (e.g., VPN ID, BGP Route Target, etc.) from the VLAN identifier. This way, it is sufficient for the network operator to configure the VLAN identifier(s) for the access circuit, and all the MPLS and BGP parameters required for setting up the service over the core network would be automatically derived without any need for explicit configuration. Implementations SHOULD revert to using default values for parameters as and where applicable. 7. New Service Interface Requirements [MEF] and [IEEE 802.1Q] have the following services specified: - Port mode: in this mode, all traffic on the port is mapped to a single bridge domain and a single corresponding L2VPN service instance. Customer VLAN transparency is guaranteed end-to-end. Sajassi, et al. Expires April 15, 2014 [Page 10]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 - VLAN mode: in this mode, each VLAN on the port is mapped to a unique bridge domain and corresponding L2VPN service instance. This mode allows for service multiplexing over the port and supports optional VLAN translation. - VLAN bundling: in this mode, a group of VLANs on the port are collectively mapped to a unique bridge domain and corresponding L2VPN service instance. Customer MAC addresses must be unique across all VLANs mapped to the same service instance. For each of the above services a single bridge domain is assigned per service instance on the PE supporting the associated service. For example, in case of the port mode, a single bridge domain is assigned for all the ports belonging to that service instance regardless of number of VLANs coming through these ports. It is worth noting that the term 'bridge domain' as used above refers to a MAC forwarding table as defined in the IEEE bridge model, and does not denote or imply any specific implementation. [RFC4762] defines two types of VPLS services based on "unqualified and qualified learning" which in turn maps to port mode and VLAN mode respectively. A solution is required to support the above three service types plus two additional service types which are primarily intended for hosted data center applications and are described below. For hosted data center interconnect applications, network operators require the ability to extend Ethernet VLANs over a WAN using a single L2VPN instance while maintaining data-plane separation between the various VLANs associated with that instance. This is referred to as VLAN-aware bundling service. (R9) A solution MAY support VLAN-aware bundle service. This gives rise to two new service interface types: VLAN-aware bundling without translation, and VLAN-aware bundling with translation. The VLAN-aware Bundling without Translation service interface has the following characteristics: - The service interface MUST provide bundling of customer VLANs into a single L2VPN service instance. - The service interface MUST guarantee customer VLAN transparency end-to-end. Sajassi, et al. Expires April 15, 2014 [Page 11]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 - 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 VLAN-aware Bundling with Translation service interface has the following characteristics: - The service interface MUST provide bundling of customer VLANs into a single L2VPN service instance. - The service interface MUST maintain data-plane separation between the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). The service interface MUST support customer VLAN translation to handle the scenario where different VLAN Identifiers (VIDs) are used on different interfaces to designate the same customer VLAN. The main difference, in terms of service provider resource allocation, between these new service types and the previously defined three types is that the new services require several bridge domains to be allocated (one per customer VLAN) per L2VPN service instance as opposed to a single bridge domain per L2VPN service instance. 8. Fast Convergence (R10a) A solution MUST provide the ability to recover from PE-CE attachment circuit failures as well as PE node failure for the case of both multi-homed device and multi-homed network. (R10b) The recovery mechanism(s) MUST provide convergence time that is independent of the number of MAC addresses learned by the PE. This is particularly important in the context of virtualization applications which are fueling an increase in the number of MAC addresses to be handled by the Layer 2 network. (R10c) Furthermore, the recovery mechanism(s) SHOULD provide convergence time that is independent of the number of service instances associated with the attachment circuit or the PE. Sajassi, et al. Expires April 15, 2014 [Page 12]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 9. Flood Suppression (R11) The solution SHOULD allow the network operator to choose whether unknown unicast frames are to be dropped or to be flooded. This attribute needs to be configurable on a per service instance basis. In addition, for the case where the solution is used for data-center interconnect, it is required to minimize the flooding of broadcast frames outside the confines of a given site. Of particular interest is periodic ARP traffic. Furthermore, it is required to eliminate any unnecessary flooding of unicast traffic upon topology changes, especially in the case of multi-homed site where the PEs have a priori knowledge of the backup paths for a given MAC address. 10. Supporting Flexible VPN Topologies and Policies (R12) A solution MUST be capable of supporting flexible VPN topologies that are not constrained by the underlying mechanisms of the solution. One example of this is E-TREE topology where one or more sites in the VPN are roots and the others are leaves. The roots are allowed to send traffic to other roots and to leaves, while leaves can communicate only with the roots. The solution MUST provide the ability to support E-TREE topology. (R12b) The solution MAY provide the ability to apply policies at the MAC address granularity to control which PEs in the VPN learn which MAC address and how a specific MAC address is forwarded. It should be possible to apply policies to allow only some of the member PEs in the VPN to send or receive traffic for a particular MAC address. (R12c) A solution MUST be capable of supporting both inter-AS option- C and inter-AS option-B scenarios as described in [RFC4364]. 11. Contributors Samer Salam, Cisco, ssalam@cisco.com John Drake, Juniper, jdrake@juniper.net Clarence Filsfils, Cisco, cfilsfil@cisco.com 12. Security Considerations Any protocol extensions developed for the EVPN solution shall include the appropriate security analysis. The requirement is to introduce no Sajassi, et al. Expires April 15, 2014 [Page 13]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC learning is performed in data-plane and beyond that of [RFC4364] when MAC learning is performed in control plane. 13. IANA Considerations None. 14. Normative References [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", August 1996. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006. [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Computer Society, November 2008. [802.1Q] IEEE Std. 802.1Q-2011, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", 2011. [RFC6074] E. Rosen and B. Davie, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", January 2011. 14. Informative References [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", September 2006. [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 06, work in progress, February, 2013. [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-11.txt, work in Sajassi, et al. Expires April 15, 2014 [Page 14]
INTERNET DRAFT Requirements for Ethernet VPN July 15, 2013 progress, February, 2013. [VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf- l2vpn-vpls-mcast-15.txt, work in progress, July 2013. [MEF] MEF 6.1 Technical Specification, "Ethernet Service Definitions", April 2008. [RFC6790] K. Kompella et al., "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012. 15. Author's Address Ali Sajassi Cisco Email: sajassi@cisco.com Rahul Aggarwal Arktan Email: raggarwa_1@yahoo.com Wim Henderickx Alcatel-Lucent Email: wim.henderickx@alcatel-lucent.com Aldrin Isaac Bloomberg Email: aisaac71@bloomberg.net James Uttaro AT&T Email: uttaro@att.com Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Sajassi, et al. Expires April 15, 2014 [Page 15]