Internet Engineering Task Force (IETF) A. Sajassi
Request for Comments: 7209 Cisco
Category: Informational R. Aggarwal
ISSN: 2070-1721 Arktan
J. Uttaro
AT&T
N. Bitar
Verizon
W. Henderickx
Alcatel-Lucent
A. Isaac
Bloomberg
May 2014
Internet Engineering Task Force (IETF) A. Sajassi
Request for Comments: 7209 Cisco
Category: Informational R. Aggarwal
ISSN: 2070-1721 Arktan
J. Uttaro
AT&T
N. Bitar
Verizon
W. Henderickx
Alcatel-Lucent
A. Isaac
Bloomberg
May 2014
Requirements for Ethernet VPN (EVPN)
以太网VPN（EVPN）的要求
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, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (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.
以太网L2VPN服务的广泛采用以及该技术的新应用（例如，数据中心互连）的出现导致了一系列新的需求，而这些需求不是当前虚拟专用LAN服务（VPLS）解决方案所能满足的。特别是，不支持具有所有活动转发的多宿主，并且没有现有的解决方案来利用多点到多点（MP2MP）标签交换路径（LSP）来优化多目标帧的交付。此外，即使在基于BGP的自动发现环境中，VPL的供应也需要网络运营商在访问配置的基础上指定各种网络参数。本文档规定了以太网VPN（EVPN）解决方案的要求，该解决方案解决了上述问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7209.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7209.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................4
3. Terminology .....................................................4
4. Redundancy Requirements .........................................5
4.1. Flow-Based Load Balancing ..................................5
4.2. Flow-Based Multipathing ....................................6
4.3. Geo-redundant PE Nodes .....................................7
4.4. Optimal Traffic Forwarding .................................7
4.5. Support for Flexible Redundancy Grouping ...................8
4.6. Multihomed Network .........................................8
5. Multicast Optimization Requirements .............................9
6. Ease of Provisioning Requirements ...............................9
7. New Service Interface Requirements .............................10
8. Fast Convergence ...............................................12
9. Flood Suppression ..............................................12
10. Supporting Flexible VPN Topologies and Policies ...............12
11. Security Considerations .......................................13
12. Normative References ..........................................13
13. Informative References ........................................14
14. Contributors ..................................................15
1. Introduction ....................................................3
2. Specification of Requirements ...................................4
3. Terminology .....................................................4
4. Redundancy Requirements .........................................5
4.1. Flow-Based Load Balancing ..................................5
4.2. Flow-Based Multipathing ....................................6
4.3. Geo-redundant PE Nodes .....................................7
4.4. Optimal Traffic Forwarding .................................7
4.5. Support for Flexible Redundancy Grouping ...................8
4.6. Multihomed Network .........................................8
5. Multicast Optimization Requirements .............................9
6. Ease of Provisioning Requirements ...............................9
7. New Service Interface Requirements .............................10
8. Fast Convergence ...............................................12
9. Flood Suppression ..............................................12
10. Supporting Flexible VPN Topologies and Policies ...............12
11. Security Considerations .......................................13
12. Normative References ..........................................13
13. Informative References ........................................14
14. Contributors ..................................................15
Virtual Private LAN Service (VPLS), as defined in [RFC4664], [RFC4761], and [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).
[RFC4664]、[RFC4761]和[RFC4762]中定义的虚拟专用LAN服务（VPLS）是一种经过验证且广泛部署的技术。然而，现有的解决方案在冗余、多播优化和资源调配简单性方面有很多限制。此外，新的应用程序正在推动对其他L2VPN服务（如以太网树（E-Tree）和虚拟专用线服务（VPWS））的若干新需求。
In the area of multihoming, current VPLS can only support multihoming with the single-active redundancy mode (defined in Section 3), for example, as described in [VPLS-BGP-MH]. Flexible multihoming with all-active redundancy mode (defined in Section 3) cannot be supported by the current VPLS solution.
在多宿领域，当前的VPLS只能支持具有单一主动冗余模式（定义见第3节）的多宿，例如，如[VPLS-BGP-MH]所述。当前的VPLS解决方案不支持具有所有主动冗余模式（定义见第3节）的灵活多宿。
In the area of multicast optimization, [RFC7117] 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.
在多播优化领域，[RFC7117]描述了如何将多播LSP与VPL结合使用。但是，此解决方案仅限于点对多点（P2MP）LSP，因为没有定义用于利用VPL的多点对多点（MP2MP）LSP的解决方案。
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.
在资源调配的简单性方面，当前的VPL通过依赖基于BGP的服务自动发现[RFC4761][RFC6074]提供了一种单边资源调配机制。然而，这仍然需要运营商在接入端以太网配置的基础上配置许多网络端参数。
In the area of data-center interconnect, applications are driving the need for new service interface types that are a hybrid combination of VLAN bundling and VLAN-based service interfaces. These are referred to as "VLAN-aware bundling" service interfaces.
在数据中心互连领域，应用程序正在推动对新服务接口类型的需求，这些类型是VLAN绑定和基于VLAN的服务接口的混合组合。这些被称为“VLAN感知绑定”服务接口。
Virtualization applications are also fueling an increase in the volume of MAC (Media Access Control) addresses that are to be handled by the network; this gives rise to the requirement for having the network reconvergence upon failure be independent of the number of MAC addresses learned by the Provider Edge (PE).
虚拟化应用程序也在推动网络处理的MAC（媒体访问控制）地址数量的增加；这就要求在发生故障时，网络重新会聚独立于提供商边缘（PE）了解到的MAC地址数量。
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 VPLS and Hierarchical VPLS (H-VPLS).
除了VPL和层次化VPL（H-VPL）目前所涵盖的之外，还需要支持灵活的VPN拓扑和策略。
The focus of this document is on defining the requirements for a new solution, namely, Ethernet VPN (EVPN), which addresses the above issues.
本文档的重点是定义新解决方案的需求，即以太网VPN（EVPN），它解决了上述问题。
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.
第4节讨论冗余要求。第5节描述了多播优化需求。第6节阐述了供应需求的易用性。第7节重点介绍了新的服务接口需求。第8节强调了快速收敛要求。第9节描述了洪水抑制需求，最后第10节讨论了支持灵活VPN拓扑和策略的需求。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document is not a protocol specification and the key words in this document are used for clarity and emphasis of requirements language.
本文件不是协议规范，本文件中的关键词用于明确和强调需求语言。
AS: Autonomous System
AS：自治系统
CE: Customer Edge
行政长官：顾客优势
E-Tree: Ethernet Tree
E-Tree：以太网树
MAC address: Media Access Control address - referred to as MAC
MAC地址：媒体访问控制地址-称为MAC
LSP: Label Switched Path
标签交换路径
PE: Provider Edge
PE：提供程序边缘
MP2MP: Multipoint to Multipoint
MP2MP：多点对多点
VPLS: Virtual Private LAN Service
虚拟专用局域网服务
Single-Active Redundancy Mode: When a device or a network is multihomed to a group of two or more PEs and when only a single PE in such a redundancy group can forward traffic to/from the multihomed device or network for a given VLAN, such multihoming is referred to as "Single-Active".
单主动冗余模式：当一个设备或网络被多宿到两个或多个PE的组中，并且当这种冗余组中只有一个PE可以为给定VLAN转发到多宿设备或网络或从多宿设备或网络转发流量时，这种多宿被称为“单主动”。
All-Active Redundancy Mode: When a device is multihomed to a group of two or more PEs and when all PEs in such redundancy group can forward traffic to/from the multihomed device or network for a given VLAN, such multihoming is referred to as "All-Active".
全主动冗余模式：当一个设备被多宿到两个或多个PE的组中，并且当该冗余组中的所有PE可以将流量转发到/从给定VLAN的多宿设备或网络，则这种多宿被称为“全主动”。
A common mechanism for multihoming a CE node to a set of PE nodes involves leveraging multi-chassis Ethernet link aggregation groups (LAGs) 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:
将CE节点多宿到一组PE节点的常见机制涉及利用基于[802.1AX]的多机箱以太网链路聚合组（LAG）。[PWE3-ICCP]描述了一种这样的方案。在以太网链路聚合中，CE通过连接到PEs的连接电路分配流量的负载平衡算法非常灵活。唯一的要求是算法确保给定流量的有序帧交付。在典型实现中，这些算法涉及基于哈希函数在捆绑包内选择出站链路，该哈希函数基于以下一个或多个字段标识流：
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
i. 第2层：源MAC地址、目标MAC地址、VLAN ii。第3层：源IP地址，目标IP地址iii。第4层：UDP或TCP源端口，目标端口
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 multihoming is the ability to accommodate flexible flow-based load balancing from the CE node based on L2, L3, and/or L4 header fields.
这里需要注意的一个关键点是[802.1AX]没有为以太网捆绑包定义标准负载平衡算法，因此，不同的实现行为不同。事实上，即使在链路上存在不对称负载平衡的情况下，bundle也能正常运行。在这种情况下，所有主动多宿主的第一个要求是能够适应来自基于L2、L3和/或L4报头字段的CE节点的灵活的基于流的负载平衡。
(R1a) A solution MUST be capable of supporting flexible flow-based load balancing from the CE as described above.
（R1a）解决方案必须能够支持如上所述的来自CE的灵活的基于流的负载平衡。
(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.
（R1b）解决方案还必须能够支持发往CE的流量的基于流的负载平衡，即使CE连接到多个PE。因此，无论CE连接到多少个PE，解决方案必须能够使用连接到CE的多个链路。
It should be noted that when a CE is multihomed to several PEs, there could be multiple Equal-Cost Multipath (ECMP) paths from each remote PE to each multihoming PE. Furthermore, for an all-active multihomed CE, a remote PE can choose any of the multihoming PEs for sending
应该注意的是，当一个CE多址到多个PE时，从每个远程PE到每个多址PE可能有多个等成本多路径（ECMP）路径。此外，对于全活动多址CE，远程PE可以选择任何多址PE进行发送
traffic destined to the multihomed CE. Therefore, when a solution supports all-active multihoming, it MUST exercise as many of these paths as possible for traffic destined to a multihomed CE.
发送到多址CE的通信量。因此，当一个解决方案支持所有主动多宿时，它必须为发送到多宿CE的流量使用尽可能多的这些路径。
(R1c) A solution SHOULD support flow-based load balancing among PEs that are members of a redundancy group spanning multiple Autonomous Systems.
（R1c）解决方案应支持作为跨越多个自治系统的冗余组成员的PE之间基于流的负载平衡。
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-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 PEs 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].
满足第4.1节所述的所有主动冗余模式（例如，基于流的负载平衡）的任何解决方案也需要在给定的一对PE之间使用多条路径。例如，如果在一个远程PE和一对全活动冗余组中的PE之间存在两个或多个LSP，则该解决方案需要能够在每个流的基础上对这些LSP之间的流量进行负载平衡，以便将流量发送到冗余组中的PE。此外，如果远程PE和冗余组中的一个PE之间存在两条或多条ECMP路径，则解决方案需要利用所有同等成本的LSP。对于后者，该解决方案还可以利用基于熵标签的负载平衡功能[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 multihoming.
（R2a）解决方案必须能够在远程PE和冗余组中的所有PE之间使用所有主动多宿的所有LSP。
(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 multihoming.
（R2b）解决方案必须能够在远程PE和冗余组中的任何PE之间使用所有主动多宿的所有ECMP路径。
For example, consider a scenario in which CE1 is multihomed to PE1 and PE2, and CE2 is multihomed 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 multihomed PEs. Traffic from CE1 to CE2 can be forwarded on twelve different paths over the MPLS/IP core as follows: CE1 load balances traffic to both PE1 and PE2. Each of PE1 and PE2 have three ECMP paths to PE3 and PE4 for a total of twelve paths. Finally, when traffic arrives at PE3 and PE4, it gets forwarded to CE2 over the Ethernet channel (aka link bundle).
例如，考虑CE1是多归属于PE1和PE2的场景，并且CE2是多宿主的，在所有活动冗余模式下运行PE3和PE4。此外，考虑在CE1和CE2的多个归宿PES之间存在三个ECMP路径。从CE1到CE2的流量可以通过MPLS/IP核心在12条不同的路径上转发，如下所示：CE1负载平衡到PE1和PE2的流量。PE1和PE2各有三条通向PE3和PE4的ECMP路径，总共有十二条路径。最后，当流量到达PE3和PE4时，它通过以太网通道（也称为链路包）转发到CE2。
It is worth pointing out that flow-based multipathing complements flow-based load balancing described in the previous section.
值得指出的是，基于流的多路径是对上一节中描述的基于流的负载平衡的补充。
The PE nodes offering multihomed 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 Central Offices (COs) or Points of Presence (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 multihoming 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 multihoming 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.
提供到CE或接入网络的多宿连接的PE节点可以位于相同的物理位置（共址），或者可以在地理上分布（例如，在不同的中央办公室（COs）或存在点（pop））。当提供地理冗余解决方案以确保停电、自然灾害等情况下关键应用程序的业务连续性时，需要后者。全主动多宿机制需要同时支持同地和地理冗余PE放置。后一种情况通常意味着，从成本的角度来看，要求PEs之间的专用链路用于多宿机制的运行并不具有吸引力。此外，在双宿设置中，从远程PEs到成对PEs的IGP成本不能假设在这些PEs是地理冗余的情况下是相同的。
(R3a) A solution MUST support all-active multihoming without the need for a dedicated control/data link among the PEs in the multihomed group.
（R3a）解决方案必须支持所有主动多址，而不需要多址组中各PEs之间的专用控制/数据链路。
(R3b) A solution MUST support different IGP costs from a remote PE to each of the PEs in a multihomed group.
（R3b）解决方案必须支持从远程PE到多址组中每个PE的不同IGP成本。
(R3c) A solution MUST support multihoming across different IGP domains within the same Autonomous System.
（R3c）解决方案必须支持在同一自治系统内跨不同IGP域的多宿主。
(R3d) A solution SHOULD support multihoming across multiple Autonomous Systems.
（R3d）解决方案应支持跨多个自治系统的多宿主。
In a typical network, when considering a designated pair of PEs, it is common to find both single-homed as well as multihomed CEs being connected to those PEs.
在典型网络中，当考虑指定的一对PE时，通常会发现单宿和多宿CE都连接到这些PE。
(R4) An all-active multihoming 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 multihomed group unless the destination CE is attached to one of the multihoming PEs.
（R4）对于以下所有场景，全主动多宿主解决方案应支持单播流量的最佳转发。所谓“最佳转发”，我们的意思是，除非目的地CE连接到其中一个多宿PE，否则作为多宿组成员的PE设备之间不会转发流量。
i. single-homed CE to multihomed CE ii. multihomed CE to single-homed CE iii. multihomed CE to multihomed CE
i. 单宿CE到多宿CE ii。多宿CE到单宿CE iii.多宿CE到多宿CE
This is especially important in the case of geo-redundant PEs, where having traffic forwarded from one PE to another within the same
这在地理冗余PE的情况下尤其重要，在同一个PE中，流量从一个PE转发到另一个PE
multihomed group introduces additional latency, on top of the inefficient use of the PE node's and core nodes' switching capacity. A multihomed group (also known as a multi-chassis LAG) is a group of PEs supporting a multihomed CE.
多宿组在PE节点和核心节点的交换容量使用效率低下的基础上引入了额外的延迟。多宿组（也称为多机箱滞后）是一组支持多宿CE的PE。
(R5) In order to support flexible redundancy grouping, the multihoming mechanism SHOULD allow arbitrary grouping of PE nodes into redundancy groups where each redundancy group represents all multihomed devices/networks that share the same group of PEs.
（R5）为了支持灵活的冗余分组，多宿机制应允许将PE节点任意分组为冗余组，其中每个冗余组表示共享同一组PE的所有多宿设备/网络。
This is best explained with an example: consider three PE nodes -- PE1, PE2, and PE3. The multihoming 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 multihomed to any one of these three redundancy groups.
这最好用一个例子来解释：考虑三个PE节点PE1、PE2和PE3。多宿机制必须允许给定的PE（例如PE1）同时成为多个冗余组的一部分。例如，可以有一个组（PE1，PE2）、一个组（PE1，PE3）和另一个组（PE2，PE3），其中CE可以多址到这三个冗余组中的任何一个。
There are applications that require an Ethernet network, rather than a single device, to be multihomed 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 multihomed network running [802.1Q] or [G.8032], these protocols require that each VLAN to be active only on one of the multihomed links.
有些应用程序需要以太网网络，而不是单个设备，以多址方式连接到一组PE。以太网网络通常会运行弹性机制，如多生成树协议[802.1Q]或以太网环保护交换[G.8032]。PEs可能参与也可能不参与以太网的控制协议。对于运行[802.1Q]或[G.8032]的多宿网络，这些协议要求每个VLAN仅在其中一个多宿链路上处于活动状态。
(R6a) A solution MUST support multihomed network connectivity with single-active redundancy mode where all VLANs are active on one PE.
（R6a）解决方案必须支持具有单一活动冗余模式的多宿网络连接，其中所有VLAN都在一个PE上活动。
(R6b) A solution MUST also support multihomed networks with single-active redundancy mode where disjoint VLAN sets are active on disparate PEs.
（R6b）解决方案还必须支持具有单一活动冗余模式的多宿网络，其中不相交的VLAN集在不同的PE上处于活动状态。
(R6c) A solution SHOULD support single-active redundancy mode among PEs that are members of a redundancy group spanning multiple ASes.
（R6c）解决方案应支持作为跨越多个ASE的冗余组成员的PE之间的单一主动冗余模式。
(R6d) A solution MAY support all-active redundancy mode for a multihomed network with MAC-based load balancing (i.e., different MAC addresses on a VLAN are reachable via different PEs).
（R6d）解决方案可支持基于MAC负载平衡的多宿网络的所有主动冗余模式（即，VLAN上的不同MAC地址可通过不同的PE访问）。
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. [RFC7117] precludes the use of MP2MP LSPs since current VPLS solutions require an egress PE to perform learning when it receives unknown unicast packets over an LSP. This is challenging when MP2MP LSPs are used, as they 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.
在某些环境中，可能需要使用MP2MP LSP来优化多播、广播和未知单播流量，以减少核心路由器中的多播状态量。[RFC7117]禁止使用MP2MP LSP，因为当前的VPLS解决方案需要出口PE在通过LSP接收未知单播数据包时执行学习。当使用MP2MP LSP时，这是一个挑战，因为它们没有识别发送者的固有机制。如果不再需要识别发送者以执行学习，那么使用MP2MP LSP进行多播优化就变得容易处理了。
(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.
（R7a）解决方案必须能够提供一种机制，当通过MP2MP LSP接收数据包时，该机制不需要针对MPLS LSP进行MAC学习。
(R7b) A solution SHOULD be able to provide procedures to use MP2MP LSPs for optimizing delivery of multicast, broadcast, and unknown unicast traffic.
（R7b）解决方案应能够提供使用MP2MP LSP优化多播、广播和未知单播流量交付的程序。
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:
随着L2VPN技术扩展到企业部署，资源调配的易用性变得至关重要。尽管当前的VPLS具有自动发现机制，能够通过MPLS/IP核心网络自动发现属于给定VPN实例的成员PE，但仍需要进一步简化，如下所述：
(R8a) The solution MUST support auto-discovery of VPN member PEs over the MPLS/IP core network, similar to the VPLS auto-discovery mechanism described in [RFC4761] and [RFC6074].
（R8a）解决方案必须支持通过MPLS/IP核心网络自动发现VPN成员PE，类似于[RFC4761]和[RFC6074]中描述的VPLS自动发现机制。
(R8b) The solution SHOULD support auto-discovery of PEs belonging to a given redundancy or multihomed group.
（R8b）该解决方案应支持自动发现属于给定冗余或多址组的PE。
(R8c) The solution SHOULD support auto-sensing of the site ID for a multihomed device or network and support auto-generation of the redundancy group ID based on the site ID.
（R8c）该解决方案应支持自动检测多址设备或网络的站点ID，并支持基于站点ID自动生成冗余组ID。
(R8d) The solution SHOULD support automated Designated Forwarder (DF) election among PEs participating in a redundancy (multihoming) group and be able to divide service instances (e.g., VLANs) among member PEs of the redundancy group.
（R8d）该解决方案应支持参与冗余（多归属）组的PE之间的自动指定转发器（DF）选择，并能够在冗余组的成员PE之间划分服务实例（如VLAN）。
(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
（R8e）对于VLAN标识符在MPLS网络中是全局的部署（即，网络限制为最多4K服务），PE设备应派生MPLS特定的
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.
VLAN标识符中的属性（例如VPN ID、BGP路由目标等）。这样，网络运营商就足以为接入电路配置VLAN标识符，在核心网络上设置服务所需的所有MPLS和BGP参数将自动导出，而无需任何显式配置。
(R8f) Implementations SHOULD revert to using default values for parameters for which no new values are configured.
（R8f）对于未配置新值的参数，实现应恢复为使用默认值。
[MEF] and [802.1Q] have the following services specified:
[MEF]和[802.1Q]指定了以下服务：
- 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.
- 端口模式：在此模式下，端口上的所有流量映射到单个网桥域和单个对应的L2VPN服务实例。保证客户VLAN的端到端透明性。
- 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模式：在此模式下，端口上的每个VLAN映射到唯一的网桥域和相应的L2VPN服务实例。此模式允许通过端口进行服务多路复用，并支持可选的VLAN转换。
- 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.
- VLAN绑定：在此模式下，端口上的一组VLAN被集中映射到唯一的网桥域和相应的L2VPN服务实例。在映射到同一服务实例的所有VLAN中，客户MAC地址必须是唯一的。
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 the number of VLANs coming through these ports.
对于上述每个服务，将为支持关联服务的PE上的每个服务实例分配一个网桥域。例如，在端口模式下，将为属于该服务实例的所有端口分配一个网桥域，而不管通过这些端口的VLAN数量如何。
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.
值得注意的是，上面使用的术语“网桥域”指的是IEEE网桥模型中定义的MAC转发表，并不表示或暗示任何具体实现。
[RFC4762] defines two types of VPLS services based on "unqualified and qualified learning", which in turn maps to port mode and VLAN mode, respectively.
[RFC4762]基于“不合格和合格学习”定义了两种类型的VPLS服务，这两种服务依次映射到端口模式和VLAN模式。
(R9a) A solution MUST support the above three service types (port mode, VLAN mode, and VLAN bundling).
（R9a）解决方案必须支持上述三种服务类型（端口模式、VLAN模式和VLAN绑定）。
For hosted applications for data-center interconnect, 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'.
对于数据中心互连的托管应用程序，网络运营商需要能够使用单个L2VPN实例在WAN上扩展以太网VLAN，同时保持与该实例关联的各种VLAN之间的数据平面分离。这称为“VLAN感知绑定服务”。
(R9b) A solution MAY support VLAN-aware bundling service.
（R9b）解决方案可支持VLAN感知绑定服务。
This gives rise to two new service interface types: VLAN-aware bundling without translation and VLAN-aware bundling with translation.
这就产生了两种新的服务接口类型：不带转换的VLAN感知绑定和带转换的VLAN感知绑定。
The service interface for VLAN-aware bundling without translation has the following characteristics:
用于无转换的VLAN感知绑定的服务接口具有以下特征：
- The service interface provides bundling of customer VLANs into a single L2VPN service instance.
- 服务接口将客户VLAN捆绑到单个L2VPN服务实例中。
- The service interface guarantees customer VLAN transparency end to end.
- 服务接口保证了客户VLAN端到端的透明性。
- The service interface maintains data-plane separation between the customer VLANs (i.e., creates a dedicated bridge-domain per VLAN).
- 服务接口保持客户VLAN之间的数据平面分离（即，为每个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.
在全对一绑定的特殊情况下，服务接口不得假定客户VLAN的任何先验知识。换句话说，客户VLAN不应配置在PE上；相反，接口的配置就像基于端口的服务一样。
The service interface for VLAN-aware bundling with translation has the following characteristics:
支持VLAN的绑定转换服务接口具有以下特征：
- The service interface provides bundling of customer VLANs into a single L2VPN service instance.
- 服务接口将客户VLAN捆绑到单个L2VPN服务实例中。
- The service interface maintains data-plane separation between the customer VLANs (i.e., creates a dedicated bridge-domain per VLAN).
- 服务接口保持客户VLAN之间的数据平面分离（即，为每个VLAN创建一个专用网桥域）。
- The service interface supports customer VLAN ID translation to handle the scenario where different VLAN Identifiers (VIDs) are used on different interfaces to designate the same customer VLAN.
- 服务接口支持客户VLAN ID转换，以处理在不同接口上使用不同VLAN标识符（VID）来指定相同客户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.
在服务提供商资源分配方面，这些新服务类型与之前定义的三种类型之间的主要区别在于，新服务要求每个L2VPN服务实例分配多个网桥域（每个客户VLAN一个），而不是每个L2VPN服务实例分配一个网桥域。
(R10a) A solution MUST provide the ability to recover from PE-CE attachment circuit failures as well as PE node failure for the cases of both multihomed device and multihomed network.
（R10a）对于多宿设备和多宿网络，解决方案必须能够从PE-CE连接电路故障以及PE节点故障中恢复。
(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.
（R10b）恢复机制必须提供收敛时间，该收敛时间与PE学习到的MAC地址数无关。这在虚拟化应用程序中尤其重要，虚拟化应用程序正在推动第2层网络处理的MAC地址数量的增加。
(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.
（R10c）此外，恢复机制应提供与连接电路或PE相关联的服务实例数量无关的收敛时间。
(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.
（R11a）该解决方案应允许网络运营商选择是丢弃未知单播帧还是淹没未知单播帧。此属性需要根据每个服务实例进行配置。
(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 Address Resolution Protocol (ARP) traffic.
（R11b）此外，对于用于数据中心互连的解决方案，该解决方案应尽量减少给定站点范围外广播帧的泛滥。特别令人感兴趣的是定期地址解析协议（ARP）流量。
(R11c) Furthermore, the solution SHOULD eliminate any unnecessary flooding of unicast traffic upon topology changes, especially in the case of a multihomed site where the PEs have a priori knowledge of the backup paths for a given MAC address.
（R11c）此外，该解决方案应消除拓扑变化时单播通信量的任何不必要泛滥，特别是在多址站点的情况下，其中PEs对给定MAC地址的备份路径具有先验知识。
(R12a) A solution MUST be capable of supporting flexible VPN topologies that are not constrained by the underlying mechanisms of the solution.
（R12a）解决方案必须能够支持不受解决方案底层机制约束的灵活VPN拓扑。
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.
其中一个例子是E-Tree拓扑，其中VPN中的一个或多个站点是根，其他站点是叶。根可以向其他根和叶子发送流量，而叶子只能与根通信。解决方案必须提供支持E-Tree拓扑的能力。
(R12b) The solution MAY provide the ability to apply policies at the granularity of the MAC address 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.
（R12b）该解决方案可提供以MAC地址粒度应用策略的能力，以控制VPN中的哪些PE了解哪个MAC地址以及特定MAC地址如何转发。应该可以应用策略，只允许VPN中的一些成员PE发送或接收特定MAC地址的流量。
(R12c) A solution MUST be capable of supporting both inter-AS option-C and inter-AS option-B scenarios as described in [RFC4364].
（R12c）解决方案必须能够支持[RFC4364]中所述的内部AS选项C和内部AS选项B场景。
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 plane, the following additional requirements need to be covered.
为EVPN解决方案开发的任何协议扩展应包括适当的安全分析。除了[RFC4761]和[RFC4762]在数据平面执行MAC学习时以及[RFC4364]在控制平面执行MAC学习时所涵盖的安全要求外，还需要涵盖以下附加要求。
(R13) A solution MUST be capable of detecting and properly handling a situation where the same MAC address appears behind two different Ethernet segments (whether inadvertently or maliciously).
（R13）解决方案必须能够检测并正确处理相同MAC地址出现在两个不同以太网段后面的情况（无论是无意还是恶意）。
(R14) A solution MUST be capable of associating a MAC address to a specific Ethernet segment (aka "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 addresses 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.
（R14）解决方案必须能够将MAC地址与特定以太网段（也称为“粘性MAC”）相关联，以帮助限制进入该MAC地址网络的恶意流量。此功能可以限制网络上伪造MAC地址的出现。启用此功能时，不允许此类粘性MAC地址的MAC移动性，并且必须丢弃来自任何其他以太网段的此类MAC地址流量。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", Std. 802.1AX-2008, IEEE Computer Society, November 2008.
[802.1AX]IEEE，“局域网和城域网的IEEE标准-链路聚合”，标准802.1AX-2008，IEEE计算机学会，2008年11月。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", Std. 802.1Q-2011, 2011.
[802.1Q]IEEE，“局域网和城域网的IEEE标准-虚拟桥接局域网”，标准802.1Q-2011，2011。
[G.8032] ITU-T, "Ethernet ring protection switching", ITU-T Recommendation G.8032, February 2012.
[G.8032]ITU-T，“以太网环保护交换”，ITU-T建议G.8032，2012年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4364] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.
[RFC4364]Bersani，F.和H.Tschofenig，“EAP-PSK协议：预共享密钥可扩展认证协议（EAP）方法”，RFC 4764，2007年1月。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，2007年1月。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，2007年1月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，2011年1月。
[VPLS-BGP-MH] Kothari, B., Kompella, K., Henderickx, W., Balue, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013.
[VPLS-BGP-MH]Kothari，B.，Kompella，K.，Henderickx，W.，Balue，F.，Uttaro，J.，Palislamovic，S.，和W.Lin，“虚拟专用局域网服务中基于BGP的多主服务”，正在进行中，2013年7月。
[PWE3-ICCP] Martini, L., Salam, S., Sajassi, A., and S. Matsushima, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Work in Progress, March 2014.
[PWE3-ICCP]Martini，L.，Salam，S.，Sajassi，A.，和S.Matsushima，“L2VPN PE冗余的机箱间通信协议”，正在进行的工作，2014年3月。
[MEF] Metro Ethernet Forum, "Ethernet Service Definitions", MEF 6.1 Technical Specification, April 2008.
[MEF]城域以太网论坛，“以太网服务定义”，MEF 6.1技术规范，2008年4月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 67902012年11月。
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014.
[RFC7117]Aggarwal，R.，Ed.，Kamite，Y.，Fang，L.，Rekhter，Y.，和C.Kodeboniya，“虚拟专用局域网服务（VPLS）中的多播”，RFC 71172014年2月。
Samer Salam, Cisco, ssalam@cisco.com John Drake, Juniper, jdrake@juniper.net Clarence Filsfils, Cisco, cfilsfil@cisco.com
萨默萨拉姆，思科，ssalam@cisco.com约翰·德雷克，朱尼珀，jdrake@juniper.net克拉伦斯·菲尔斯，思科，cfilsfil@cisco.com
Authors' Addresses
作者地址
Ali Sajassi Cisco EMail: sajassi@cisco.com
Ali Sajassi Cisco电子邮件：sajassi@cisco.com
Rahul Aggarwal Arktan EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Arktan电子邮件：raggarwa_1@yahoo.com
James Uttaro AT&T EMail: uttaro@att.com
James Uttaro AT&T电子邮件：uttaro@att.com
Nabil Bitar Verizon Communications EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon通信电子邮件：Nabil.n。bitar@verizon.com
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim亨德里克斯阿尔卡特朗讯电子邮件：Wim。henderickx@alcatel-朗讯网
Aldrin Isaac Bloomberg EMail: aisaac71@bloomberg.net
Aldrin Isaac Bloomberg电子邮件：aisaac71@bloomberg.net