Internet DRAFT - draft-ietf-l2vpn-evpn-req
draft-ietf-l2vpn-evpn-req
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: August 4, 2014 February 4, 2014
Requirements for Ethernet VPN (EVPN)
draft-ietf-l2vpn-evpn-req-07.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) 2014 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 August 4, 2014 [Page 1]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
(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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of requirements . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Normative References . . . . . . . . . . . . . . . . . . . . . 14
14. Informative References . . . . . . . . . . . . . . . . . . . . 15
15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Sajassi, et al. Expires August 4, 2014 [Page 2]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
Sajassi, et al. Expires August 4, 2014 [Page 3]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
1. Introduction
VIrtual Private LAN Service (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 Ethernet-
Tree (E-Tree), and Virtual Private Wire Service (VPWS).
In the area of multi-homing current VPLS can only support multi-
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.
In the area of 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.
Virtualization applications are also 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.
There are requirements for minimizing the amount of flooding of
multi-destination frames and localizing the flooding to the confines
of a given site.
There are also 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.
Sajassi, et al. Expires August 4, 2014 [Page 4]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
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.
2. 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].
This document is not a protocol specification and the key words in
this document are used for clarity and emphasis of requirements
language.
3. 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 Redundancy Mode: When a device or a network is multi-
homed to a group of 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 is referred to as
"Single-Active".
All-Active Redundancy Mode: When a device is multi-homed to a group
of two or more PEs and when all PEs in such redundancy group can
forward traffic to/from the multi-homed device or network for a given
VLAN, then such multi-homing is referred to as "All-Active".
Sajassi, et al. Expires August 4, 2014 [Page 5]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
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 typically 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 SHOULD support flow-based load balancing among PEs
that are members of a redundancy group spanning multiple Autonomous
Systems.
Sajassi, et al. Expires August 4, 2014 [Page 6]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
4.2. Flow-based Multi-pathing
Any solution that meets the all-active redundancy mode (e.g., flow-
based load balancing) described in section 4.1, also needs to
exercise multiple paths between a given pair of PEs. For instance, if
there are two or more LSPs between a remote PE and a pair of PEs in
an all-active redundancy group, then the solution needs to be capable
of load balancing traffic among those LSPs on a per L2-flow basis for
traffic destined to the PEs in the redundancy group. Furthermore, if
there are two or more ECMP paths between a remote PE and one of the
PE in the redundancy group, then the solution needs to leverage all
the equal cost LSPs. For the latter, the solution can also leverage
the load balancing capabilities based on entropy labels [RFC6790].
(R2a) A solution MUST be able to exercise all LSPs between a remote
PE and all the PEs in the redundancy group with all-active multi-
homing.
(R2b) A solution MUST be able to exercise all ECMP paths between a
remote PE and any of the PEs in the redundancy group with all-active
multi-homing.
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
redundancy mode. Furthermore, consider that there exist three ECMP
paths 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 ECMP paths 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 needed 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
needs to 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
Sajassi, et al. Expires August 4, 2014 [Page 7]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
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
need for a dedicated control/data link among the PEs in the multi-
homed group.
(R3b) A solution MUST support different IGP costs from a remote PE to
each of the PEs in a multi-homed group.
(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 support flexible redundancy grouping, the multi-
homing mechanism SHOULD allow arbitrary grouping of PE nodes into
redundancy groups where each redundancy group represents all multi-
homed devices/networks that share the same group of PEs.
Sajassi, et al. Expires August 4, 2014 [Page 8]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
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
these three redundancy groups.
4.6. Multi-homed Network
There are applications, that 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 mode where all VLANs are active on one PE.
(R6b) A solution MUST also support multi-homed network with single-
active redundancy mode where disjoint VLAN sets are active on
disparate PEs.
(R6c) A solution SHOULD support single-active redundancy mode among
PEs that are member of a redundancy group spanning multiple ASes.
(R6d) A solution MAY support all-active redundancy mode for a multi-
homed network with 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 use 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 use 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 use 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
Sajassi, et al. Expires August 4, 2014 [Page 9]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
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
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.
(R8f) Implementations SHOULD revert to using default values for
parameters that no new values are configured for.
7. New Service Interface Requirements
[MEF] and [IEEE 802.1Q] have the following services specified:
Sajassi, et al. Expires August 4, 2014 [Page 10]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
- 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.
- 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.
(R9a) A solution MUST support the above three service types.
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.
(R9b) 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 provides bundling of customer VLANs into a
single L2VPN service instance.
Sajassi, et al. Expires August 4, 2014 [Page 11]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
- The service interface guarantees customer VLAN transparency end-to-
end.
- The service interface maintains 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 provides bundling of customer VLANs into a
single L2VPN service instance.
- The service interface maintains data-plane separation between the
customer VLANs (i.e. create a dedicated bridge-domain per VLAN).
- The service interface supports 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
Sajassi, et al. Expires August 4, 2014 [Page 12]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
instances associated with the attachment circuit or the PE.
9. Flood Suppression
(R11a) 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.
(R11b) In addition, for the case where the solution is used for data-
center interconnect, the solution SHOULD minimize the flooding of
broadcast frames outside the confines of a given site. Of particular
interest is periodic ARP traffic.
(R11c) Furthermore, the solution SHOULD 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
(R12a) 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. Security Considerations
Any protocol extensions developed for the EVPN solution shall include
the appropriate security analysis. Besides the security requirements
covered in [RFC4761] and [RFC4762] when MAC learning is performed in
data-plane and in [RFC4364] when MAC learning is performed in control
Sajassi, et al. Expires August 4, 2014 [Page 13]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
plane, the following additional requirements need to be covered.
(R13) A solution MUST be capable of detecting and properly handling a
situation where the same MAC address appears behind two different
Ethernet Segment (whether inadvertently or maliciously).
(R14) A solution MUST be capable of associating a MAC address to a
specific Ethernet Segment (sticky MAC) in order to help limit
malicious traffic into a network for that MAC address. This
capability can limit the appearance of spoofed MAC address on a
network. When this feature is enabled, the MAC mobility for such
sticky MAC addresses are disallowed and the traffic for such MAC
addresses from any other Ethernet Segment MUST be discarded.
12. Contributors
Samer Salam, Cisco, ssalam@cisco.com
John Drake, Juniper, jdrake@juniper.net
Clarence Filsfils, Cisco, cfilsfil@cisco.com
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.
Sajassi, et al. Expires August 4, 2014 [Page 14]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
[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-13.txt, work in
progress, January, 2014.
[VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf-
l2vpn-vpls-mcast-16.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
Sajassi, et al. Expires August 4, 2014 [Page 15]
INTERNET DRAFT Requirements for Ethernet VPN February 4, 2014
James Uttaro
AT&T
Email: uttaro@att.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Sajassi, et al. Expires August 4, 2014 [Page 16]
