Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 8388 S. Palislamovic
Category: Informational W. Henderickx
ISSN: 2070-1721 Nokia
A. Sajassi
Cisco
J. Uttaro
AT&T
May 2018
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 8388 S. Palislamovic
Category: Informational W. Henderickx
ISSN: 2070-1721 Nokia
A. Sajassi
Cisco
J. Uttaro
AT&T
May 2018
Usage and Applicability of BGP MPLS-Based Ethernet VPN
基于bgpmpls的以太网VPN的使用及适用性
Abstract
摘要
This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.
本文档讨论了基于BGP MPLS的以太网VPN（EVPN）在简单且相当常见的部署场景中的用法和适用性。示例场景中解释了不同的EVPN程序以及每个选项的好处和权衡。本文件旨在为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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8388.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8388.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Case Scenario Description and Requirements . . . . . . . 5
3.1. Service Requirements . . . . . . . . . . . . . . . . . . 5
3.2. Why EVPN Is Chosen to Address This Use Case . . . . . . . 7
4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . 7
4.1. Common Provisioning Tasks . . . . . . . . . . . . . . . . 8
4.1.1. Non-Service-Specific Parameters . . . . . . . . . . . 8
4.1.2. Service-Specific Parameters . . . . . . . . . . . . . 9
4.2. Service-Interface-Dependent Provisioning Tasks . . . . . 9
4.2.1. VLAN-Based Service Interface EVI . . . . . . . . . . 10
4.2.2. VLAN Bundle Service Interface EVI . . . . . . . . . . 10
4.2.3. VLAN-Aware Bundling Service Interface EVI . . . . . . 10
5. BGP EVPN NLRI Usage . . . . . . . . . . . . . . . . . . . . . 11
6. MAC-Based Forwarding Model Use Case . . . . . . . . . . . . . 11
6.1. EVPN Network Startup Procedures . . . . . . . . . . . . . 12
6.2. VLAN-Based Service Procedures . . . . . . . . . . . . . . 12
6.2.1. Service Startup Procedures . . . . . . . . . . . . . 13
6.2.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 13
6.3. VLAN Bundle Service Procedures . . . . . . . . . . . . . 17
6.3.1. Service Startup Procedures . . . . . . . . . . . . . 17
6.3.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 18
6.4. VLAN-Aware Bundling Service Procedures . . . . . . . . . 18
6.4.1. Service Startup Procedures . . . . . . . . . . . . . 18
6.4.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 19
7. MPLS-Based Forwarding Model Use Case . . . . . . . . . . . . 20
7.1. Impact of MPLS-Based Forwarding on the EVPN Network
Startup . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Case Scenario Description and Requirements . . . . . . . 5
3.1. Service Requirements . . . . . . . . . . . . . . . . . . 5
3.2. Why EVPN Is Chosen to Address This Use Case . . . . . . . 7
4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . 7
4.1. Common Provisioning Tasks . . . . . . . . . . . . . . . . 8
4.1.1. Non-Service-Specific Parameters . . . . . . . . . . . 8
4.1.2. Service-Specific Parameters . . . . . . . . . . . . . 9
4.2. Service-Interface-Dependent Provisioning Tasks . . . . . 9
4.2.1. VLAN-Based Service Interface EVI . . . . . . . . . . 10
4.2.2. VLAN Bundle Service Interface EVI . . . . . . . . . . 10
4.2.3. VLAN-Aware Bundling Service Interface EVI . . . . . . 10
5. BGP EVPN NLRI Usage . . . . . . . . . . . . . . . . . . . . . 11
6. MAC-Based Forwarding Model Use Case . . . . . . . . . . . . . 11
6.1. EVPN Network Startup Procedures . . . . . . . . . . . . . 12
6.2. VLAN-Based Service Procedures . . . . . . . . . . . . . . 12
6.2.1. Service Startup Procedures . . . . . . . . . . . . . 13
6.2.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 13
6.3. VLAN Bundle Service Procedures . . . . . . . . . . . . . 17
6.3.1. Service Startup Procedures . . . . . . . . . . . . . 17
6.3.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 18
6.4. VLAN-Aware Bundling Service Procedures . . . . . . . . . 18
6.4.1. Service Startup Procedures . . . . . . . . . . . . . 18
6.4.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 19
7. MPLS-Based Forwarding Model Use Case . . . . . . . . . . . . 20
7.1. Impact of MPLS-Based Forwarding on the EVPN Network
Startup . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle
Service Procedures . . . . . . . . . . . . . . . . . . . 22
7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 22
8. Comparison between MAC-Based and MPLS-Based Egress Forwarding
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Traffic Flow Optimization . . . . . . . . . . . . . . . . . . 24
9.1. Control-Plane Procedures . . . . . . . . . . . . . . . . 24
9.1.1. MAC Learning Options . . . . . . . . . . . . . . . . 24
9.1.2. Proxy ARP/ND . . . . . . . . . . . . . . . . . . . . 25
9.1.3. Unknown Unicast Flooding Suppression . . . . . . . . 25
9.1.4. Optimization of Inter-Subnet Forwarding . . . . . . . 26
9.2. Packet Walk-Through Examples . . . . . . . . . . . . . . 27
9.2.1. Proxy ARP Example for CE2-to-CE3 Traffic . . . . . . 27
9.2.2. Flood Suppression Example for CE1-to-CE3 Traffic . . 27
9.2.3. Optimization of Inter-subnet Forwarding Example for
CE3-to-CE2 Traffic . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle
Service Procedures . . . . . . . . . . . . . . . . . . . 22
7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 22
8. Comparison between MAC-Based and MPLS-Based Egress Forwarding
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Traffic Flow Optimization . . . . . . . . . . . . . . . . . . 24
9.1. Control-Plane Procedures . . . . . . . . . . . . . . . . 24
9.1.1. MAC Learning Options . . . . . . . . . . . . . . . . 24
9.1.2. Proxy ARP/ND . . . . . . . . . . . . . . . . . . . . 25
9.1.3. Unknown Unicast Flooding Suppression . . . . . . . . 25
9.1.4. Optimization of Inter-Subnet Forwarding . . . . . . . 26
9.2. Packet Walk-Through Examples . . . . . . . . . . . . . . 27
9.2.1. Proxy ARP Example for CE2-to-CE3 Traffic . . . . . . 27
9.2.2. Flood Suppression Example for CE1-to-CE3 Traffic . . 27
9.2.3. Optimization of Inter-subnet Forwarding Example for
CE3-to-CE2 Traffic . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
This document complements [RFC7432] by discussing the applicability of the technology in a simple and fairly common deployment scenario, which is described in Section 3.
本文档对[RFC7432]进行了补充，讨论了该技术在简单且相当常见的部署场景中的适用性，如第3节所述。
After describing the topology and requirements of the use case scenario, Section 4 will describe the provisioning model.
在描述了用例场景的拓扑和需求之后，第4节将描述供应模型。
Once the provisioning model is analyzed, Sections 5, 6, and 7 will describe the control-plane and data-plane procedures in the example scenario for the two potential disposition/forwarding models: MAC-based and MPLS-based models. While both models can interoperate in the same network, each one has different trade-offs that are analyzed in Section 8.
一旦对供应模型进行了分析，第5、6和7节将描述两种可能的部署/转发模型示例场景中的控制平面和数据平面过程：基于MAC和基于MPLS的模型。虽然这两种模型可以在同一个网络中进行互操作，但第8节分析了每种模型的不同权衡。
Finally, EVPN provides some potential traffic flow optimization tools that are also described in Section 9 in the context of the example scenario.
最后，EVPN提供了一些潜在的交通流优化工具，这些工具在第9节的示例场景中也有描述。
The following terminology is used:
使用以下术语：
VID: VLAN Identifier
VID:VLAN标识符
CE: Customer Edge (device)
CE：客户边缘（设备）
EVI: EVPN Instance
EVI:EVPN实例
MAC-VRF: A Virtual Routing and Forwarding (VRF) table for Media Access Control (MAC) addresses on a Provider Edge (PE) router.
MAC-VRF：提供商边缘（PE）路由器上媒体访问控制（MAC）地址的虚拟路由和转发（VRF）表。
ES: An Ethernet Segment is a set of links through which a CE is connected to one or more PEs. Each ES is identified by an Ethernet Segment Identifier (ESI) in the control plane.
ES：以太网段是一组链路，CE通过这些链路连接到一个或多个PE。每个ES由控制平面中的以太网段标识符（ESI）标识。
CE-VIDs: The VLAN Identifier tags being used at CE1, CE2, and CE3 to tag customer traffic sent to the service provider EVPN network.
CE VIDs：在CE1、CE2和CE3处使用的VLAN标识符标签，用于标记发送到服务提供商EVPN网络的客户流量。
CE1-MAC, CE2-MAC, and CE3-MAC: The source MAC addresses "behind" each CE, respectively. These MAC addresses can belong to the CEs themselves or to devices connected to the CEs.
CE1-MAC、CE2-MAC和CE3-MAC：分别位于每个CE后面的源MAC地址。这些MAC地址可以属于CEs本身，也可以属于连接到CEs的设备。
CE1-IP, CE2-IP, and CE3-IP: The IP addresses associated with the above MAC addresses
CE1-IP、CE2-IP和CE3-IP：与上述MAC地址关联的IP地址
LACP: Link Aggregation Control Protocol
链路聚合控制协议
RD: Route Distinguisher
路由识别器
RT: Route Target
路线目标
PE: Provider Edge (router)
PE：提供程序边缘（路由器）
AS: Autonomous System
AS：自治系统
PE-IP: The IP address of a given PE
PE-IP：给定PE的IP地址
Figure 1 depicts the scenario that will be referenced throughout the rest of the document.
图1描述了将在文档其余部分中引用的场景。
+--------------+
| |
+----+ +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE3|
+----+ /| PE1| | IP/MPLS | | PE3| +----+
/ +----+ | Network | +----+
/ | |
/ +----+ | |
+----+/ | | | |
| CE2|-----| PE2| | |
+----+ +----+ | |
+--------------+
+--------------+
| |
+----+ +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE3|
+----+ /| PE1| | IP/MPLS | | PE3| +----+
/ +----+ | Network | +----+
/ | |
/ +----+ | |
+----+/ | | | |
| CE2|-----| PE2| | |
+----+ +----+ | |
+--------------+
Figure 1: EVPN Use Case Scenario
图1:EVPN用例场景
There are three PEs and three CEs considered in this example: PE1, PE2, and PE3, as well as CE1, CE2, and CE3. Broadcast domains must be extended among the three CEs.
本例中考虑了三个PE和三个CE：PE1、PE2和PE3，以及CE1、CE2和CE3。广播域必须在三个CE之间扩展。
The following service requirements are assumed in this scenario:
在这种情况下，假设存在以下服务需求：
o Redundancy requirements:
o 冗余要求：
- CE2 requires multihoming connectivity to PE1 and PE2, not only for redundancy purposes but also for adding more upstream/ downstream connectivity bandwidth to/from the network.
- CE2需要到PE1和PE2的多宿连接，这不仅是为了冗余目的，也是为了向网络添加更多的上游/下游连接带宽。
- Fast convergence. For example, if the link between CE2 and PE1 goes down, a fast convergence mechanism must be supported so that PE3 can immediately send the traffic to PE2, irrespective of the number of affected services and MAC addresses.
- 快速收敛。例如，如果CE2和PE1之间的链路中断，则必须支持快速收敛机制，以便PE3可以立即将流量发送到PE2，而不考虑受影响的服务和MAC地址的数量。
o Service interface requirements:
o 服务接口要求：
- The service definition must be flexible in terms of CE-VID-to-broadcast-domain assignment in the core.
- 服务定义必须在核心的CE-VID到广播域分配方面具有灵活性。
- The following three EVI services are required in this example:
- 本例中需要以下三种EVI服务：
EVI100 uses VLAN-based service interfaces in the three CEs with a 1:1 VLAN-to-EVI mapping. The CE-VIDs at the three CEs can be the same (for example, VID 100) or different at each CE (for instance, VID 101 in CE1, VID 102 in CE2, and VID 103 in CE3). A single broadcast domain needs to be created for EVI100 in any case; therefore, CE-VIDs will require translation at the egress PEs if they are not consistent across the three CEs. The case when the same CE-VID is used across the three CEs for EVI100 is referred to in [RFC7432] as the "Unique VLAN" EVPN case. This term will be used throughout this document too.
EVI100在三个CEs中使用基于VLAN的服务接口，具有1:1的VLAN到EVI映射。三个CE处的CE-VID可以相同（例如，VID 100）或在每个CE处不同（例如，CE1中的VID 101、CE2中的VID 102和CE3中的VID 103）。在任何情况下，都需要为EVI100创建一个广播域；因此，如果CE VID在三个CE之间不一致，则CE VID需要在出口PEs处进行翻译。[RFC7432]将EVI100的三个CE之间使用相同CE-VID的情况称为“唯一VLAN”EVPN情况。本文件中也将使用该术语。
EVI200 uses VLAN bundle service interfaces in CE1, CE2, and CE3 based on an N:1 VLAN-to-EVI mapping. The operator needs to preconfigure a range of CE-VIDs and its mapping to the EVI, and this mapping should be consistent in all the PEs (no translation is supported). A single broadcast domain is created for the customer. The customer is responsible for keeping the separation between users in different CE-VIDs.
EVI200基于N:1 VLAN到EVI映射，在CE1、CE2和CE3中使用VLAN捆绑服务接口。操作员需要预先配置一系列CE VID及其到EVI的映射，并且该映射应在所有PE中保持一致（不支持翻译）。为客户创建一个广播域。客户负责保持不同CE视频中用户之间的隔离。
EVI300 uses VLAN-aware bundling service interfaces in CE1, CE2, and CE3. As in the EVI200 case, an N:1 VLAN-to-EVI mapping is created at the ingress PEs; however, in this case, a separate broadcast domain is required per CE-VID. The CE-VIDs can be different (hence, CE-VID translation is required).
EVI300在CE1、CE2和CE3中使用支持VLAN的绑定服务接口。与EVI200的情况一样，在入口PEs处创建N:1 VLAN到EVI的映射；然而，在这种情况下，每个CE-VID需要单独的广播域。CE-VID可以不同（因此，需要CE-VID翻译）。
Note that in Section 4.2.1, only EVI100 is used as an example of VLAN-based service provisioning. In Sections 6.2 and 7.2, 4k VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC versus MPLS disposition models in the control plane can be evaluated. In the same way, EVI200 and EVI300 will be described with a 4k:1 mapping (CE-VIDs-to-EVI mapping) in Sections 6.3, 6.4, 7.3, and 7.4.
请注意，在第4.2.1节中，仅EVI100用作基于VLAN的服务供应示例。在第6.2节和第7.2节中，使用了基于4k VLAN的EVI（EVI1到EVI4k），以便可以评估控制平面中MAC与MPLS配置模型的影响。同样，EVI200和EVI300将在第6.3、6.4、7.3和7.4节中用4k:1映射（CE视频到EVI映射）进行描述。
o Broadcast, Unknown Unicast, Multicast (BUM) optimization requirements:
o 广播、未知单播、多播（BUM）优化要求：
- The solution must support ingress replication or P2MP MPLS LSPs on a per EVI service. For example, we can use ingress replication for EVI100 and EVI200, assuming those EVIs will not carry much BUM traffic. On the contrary, if EVI300 is presumably carrying a significant amount of multicast traffic, P2MP MPLS LSPs can be used for this service.
- 该解决方案必须在每EVI服务上支持入口复制或P2MP MPLS LSP。例如，我们可以对EVI100和EVI200使用入口复制，假设这些EVI不会承载太多BUM流量。相反，如果EVI300可能承载大量多播流量，则P2MP MPLS LSP可用于此服务。
- The benefit of ingress replication compared to P2MP LSPs is that the core routers will not need to maintain any multicast states.
- 与P2MP LSP相比，入口复制的好处是核心路由器不需要维护任何多播状态。
Virtual Private LAN Service (VPLS) solutions based on [RFC4761], [RFC4762], and [RFC6074] cannot meet the requirements in Section 3, whereas EVPN can.
基于[RFC4761]、[RFC4762]和[RFC6074]的虚拟专用LAN服务（VPLS）解决方案不能满足第3节的要求，而EVPN可以。
For example:
例如：
o If CE2 has a single CE-VID (or a few CE-VIDs), the current VPLS multihoming solutions (based on load-balancing per CE-VID or service) do not provide the optimized link utilization required in this example. EVPN provides the flow-based, load-balancing, multihoming solution required in this scenario to optimize the upstream/downstream link utilization between CE2 and PE1-PE2.
o 如果CE2有一个CE-VID（或几个CE-VID），当前的VPLS多主解决方案（基于每个CE-VID或服务的负载平衡）不能提供本示例中所需的优化链路利用率。EVPN提供了该场景中所需的基于流量的负载平衡多主解决方案，以优化CE2和PE1-PE2之间的上游/下游链路利用率。
o EVPN provides a fast convergence solution that is independent of the CE-VIDs in the multihomed PEs. Upon failure on the link between CE2 and PE1, PE3 can immediately send the traffic to PE2 based on a single notification message being sent by PE1. This is not possible with VPLS solutions.
o EVPN提供了一种快速收敛的解决方案，它独立于多宿PEs中的CE VID。当CE2和PE1之间的链路出现故障时，PE3可以根据PE1发送的单个通知消息立即向PE2发送流量。这在VPLS解决方案中是不可能的。
o With regard to service interfaces and mapping to broadcast domains, while VPLS might meet the requirements for EVI100 and EVI200, the VLAN-aware bundling service interfaces required by EVI300 are not supported by the current VPLS tools.
o 关于服务接口和到广播域的映射，虽然VPLS可能满足EVI100和EVI200的要求，但当前的VPLS工具不支持EVI300所需的VLAN感知绑定服务接口。
The rest of the document will describe how EVPN can be used to meet the service requirements described in Section 3 and even optimize the network further by:
本文件的其余部分将描述如何使用EVPN来满足第3节所述的服务要求，甚至通过以下方式进一步优化网络：
o providing the user with an option to reduce (and even suppress) ARP (Address Resolution Protocol) flooding; and
o 为用户提供减少（甚至抑制）ARP（地址解析协议）洪泛的选项；和
o supporting ARP termination and inter-subnet forwarding.
o 支持ARP终止和子网间转发。
One of the requirements stated in [RFC7209] is the ease of provisioning. BGP parameters and service context parameters should be auto-provisioned so that the addition of a new MAC-VRF to the EVI requires a minimum number of single-sided provisioning touches. However, this is possible only in a limited number of cases. This section describes the provisioning tasks required for the services described in Section 3, i.e., EVI100 (VLAN-based service interfaces), EVI200 (VLAN bundle service interfaces), and EVI300 (VLAN-aware bundling service interfaces).
[RFC7209]中规定的要求之一是易于设置。BGP参数和服务上下文参数应自动设置，以便将新的MAC-VRF添加到EVI时需要最少数量的单边设置接触。然而，这只有在有限的情况下才可能实现。本节描述了第3节所述服务所需的配置任务，即EVI100（基于VLAN的服务接口）、EVI200（VLAN捆绑服务接口）和EVI300（支持VLAN的捆绑服务接口）。
Regardless of the service interface type (VLAN-based, VLAN bundle, or VLAN-aware), the following subsections describe the parameters to be provisioned in the three PEs.
无论服务接口类型（基于VLAN、VLAN绑定或VLAN感知）如何，以下小节描述了三个PE中要设置的参数。
The multihoming function in EVPN requires the provisioning of certain parameters that are not service specific and that are shared by all the MAC-VRFs in the node using the multihoming capabilities. In our use case, these parameters are only provisioned or auto-derived in PE1 and PE2 and are listed below:
EVPN中的多主功能要求提供某些非服务特定的参数，这些参数由节点中使用多主功能的所有MAC VRF共享。在我们的用例中，这些参数仅在PE1和PE2中配置或自动派生，如下所示：
o Ethernet Segment Identifier (ESI): Only the ESI associated with CE2 needs to be considered in our example. Single-homed CEs such as CE1 and CE3 do not require the provisioning of an ESI (the ESI will be coded as zero in the BGP Network Layer Reachability Information (NLRI)). In our example, a Link Aggregation Group (LAG) is used between CE2 and PE1-PE2 (since all-active multihoming is a requirement); therefore, the ESI can be auto-derived from the LACP information as described in [RFC7432]. Note that the ESI must be unique across all the PEs in the network; therefore, the auto-provisioning of the ESI is recommended only in case the CEs are managed by the operator. Otherwise, the ESI should be manually provisioned (Type 0, as in [RFC7432]) in order to avoid potential conflicts.
o 以太网段标识符（ESI）：在我们的示例中，只需要考虑与CE2相关联的ESI。单宿CE（如CE1和CE3）不需要提供ESI（ESI将在BGP网络层可达性信息（NLRI）中编码为零）。在我们的示例中，在CE2和PE1-PE2之间使用链路聚合组（LAG）（因为需要所有主动多址）；因此，可以根据[RFC7432]中所述的LACP信息自动导出ESI。请注意，ESI在网络中的所有PE中必须是唯一的；因此，只有在CEs由运营商管理的情况下，才建议自动配置ESI。否则，应手动设置ESI（类型0，如[RFC7432]中所示），以避免潜在冲突。
o ES-Import Route Target (ES-Import RT): This is the RT that will be sent by PE1 and PE2, along with the ES route. Regardless of how the ESI is provisioned in PE1 and PE2, the ES-Import RT must always be auto-derived from the 6-byte MAC address portion of the ESI value.
o ES导入路由目标（ES导入RT）：这是将由PE1和PE2与ES路由一起发送的RT。无论如何在PE1和PE2中配置ESI，ES导入RT必须始终从ESI值的6字节MAC地址部分自动派生。
o Ethernet Segment Route Distinguisher (ES RD): This is the RD to be encoded in the ES route, and it is the Ethernet Auto-Discovery (A-D) route to be sent by PE1 and PE2 for the CE2 ESI. This RD should always be auto-derived from the PE-IP address, as described in [RFC7432].
o 以太网段路由识别器（ES RD）：这是要在ES路由中编码的RD，是PE1和PE2为CE2 ESI发送的以太网自动发现（A-D）路由。此RD应始终自动从PE-IP地址派生，如[RFC7432]中所述。
o Multihoming type: The user must be able to provision the multihoming type to be used in the network. In our use case, the multihoming type will be set to all-active for the CE2 ESI. This piece of information is encoded in the ESI Label extended community flags and is sent by PE1 and PE2 along with the Ethernet A-D route for the CE2 ESI.
o 多归属类型：用户必须能够提供网络中使用的多归属类型。在我们的用例中，对于CE2 ESI，多归宿类型将设置为all active。此信息编码在ESI标签扩展社区标志中，并由PE1和PE2与CE2 ESI的以太网A-D路由一起发送。
In addition, the same LACP parameters will be configured in PE1 and PE2 for the ES so that CE2 can send frames to PE1 and PE2 as though they were forming a single system.
此外，将在PE1和PE2中为ES配置相同的LACP参数，以便CE2可以向PE1和PE2发送帧，就好像它们正在形成单个系统一样。
The following parameters must be provisioned in PE1, PE2, and PE3 per EVI service:
每个EVI服务必须在PE1、PE2和PE3中设置以下参数：
o EVI Identifier: The global identifier per EVI that is shared by all the PEs that are part of the EVI, i.e., PE1, PE2, and PE3 will be provisioned with EVI100, 200, and 300. The EVI identifier can be associated with (or be the same value as) the EVI default Ethernet Tag (4-byte default broadcast domain identifier for the EVI). The Ethernet Tag is different from zero in the EVPN BGP routes only if the service interface type (of the source PE) is a VLAN-aware bundle.
o EVI标识符：每个EVI的全局标识符，由作为EVI一部分的所有PE共享，即PE1、PE2和PE3将配备EVI100、200和300。EVI标识符可以与EVI默认以太网标签（EVI的4字节默认广播域标识符）相关联（或与之相同）。仅当（源PE的）服务接口类型为VLAN感知捆绑包时，EVPN BGP路由中的以太网标记不同于零。
o EVI Route Distinguisher (EVI RD): This RD is a unique value across all the MAC-VRFs in a PE. Auto-derivation of this RD might be possible depending on the service interface type being used in the EVI. The next section discusses the specifics of each service interface type.
o EVI路由识别器（EVI RD）：此RD是PE中所有MAC VRF的唯一值。根据EVI中使用的服务接口类型，可能会自动派生此RD。下一节将讨论每种服务接口类型的细节。
o EVI Route Target(s) (EVI RT): One or more RTs can be provisioned per MAC-VRF. The RT(s) imported and exported can be equal or different, just as the RT(s) in IP-VPNs. Auto-derivation of this RT(s) might be possible depending on the service interface type being used in the EVI. The next section discusses the specifics of each service interface type.
o EVI路由目标（EVI RT）：每个MAC-VRF可以配置一个或多个RTs。导入和导出的RT可以相同，也可以不同，就像IP VPN中的RT一样。根据EVI中使用的服务接口类型，可能会自动派生此RT。下一节将讨论每种服务接口类型的细节。
o CE-VID and port/LAG binding to EVI identifier or Ethernet Tag: For more information, please see Section 4.2.
o CE-VID和端口/延迟绑定到EVI标识符或以太网标签：有关更多信息，请参阅第4.2节。
Depending on the service interface type being used in the EVI, a given CE-VID binding provision must be specified.
根据EVI中使用的服务接口类型，必须指定给定的CE-VID绑定规定。
In our use case, EVI100 is a VLAN-based service interface EVI.
在我们的用例中，EVI100是一个基于VLAN的服务接口EVI。
EVI100 can be a "unique-VLAN" service if the CE-VID being used for this service in CE1, CE2, and CE3 is identical (for example, VID 100). In that case, the VID 100 binding must be provisioned in PE1, PE2, and PE3 for EVI100 and the associated port or LAG. The MAC-VRF RD and RT can be auto-derived from the CE-VID:
如果CE1、CE2和CE3中用于此服务的CE-VID相同（例如，VID 100），则EVI100可以是“唯一VLAN”服务。在这种情况下，必须在PE1、PE2和PE3中为EVI100和相关端口或延迟提供VID 100绑定。MAC-VRF RD和RT可从CE-VID自动导出：
o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in [RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID]; where [PE-IP] is the IP address of the PE (a loopback address) and [zero-padded-VID] is a 2-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order 4 bits are zero.
o 自动派生的MAC-VRF RD将是[RFC7432]中建议的类型1 RD，它将由[PE-IP]：[zero padded VID]；其中，[PE-IP]是PE的IP地址（环回地址），[zero padded VID]是2字节值，其中低阶12位是VID（在我们的示例中为VID 100），高阶4位是零。
o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded-VID]; where [AS] is the Autonomous System that the PE belongs to and [zero-padded-VID] is a 2- or 4-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order bits are zero. Note that auto-deriving the RT implies supporting a basic any-to-any topology in the EVI and using the same import and export RT in the EVI.
o 自动导出的MAC-VRF RT将由[AS]：[zero padded VID]；其中，[AS]是PE所属的自治系统，[zero padded VID]是2字节或4字节的值，其中低阶12位为VID（在我们的示例中为VID 100），高阶位为零。请注意，自动派生RT意味着支持EVI中的基本any-to-any拓扑，并在EVI中使用相同的导入和导出RT。
If EVI100 is not a "unique-VLAN" instance, each individual CE-VID must be configured in each PE, and MAC-VRF RDs and RTs cannot be auto-derived; hence, they must be provisioned by the user.
如果EVI100不是“唯一VLAN”实例，则必须在每个PE中配置每个CE-VID，并且不能自动派生MAC-VRF RDs和RTs；因此，它们必须由用户提供。
Assuming EVI200 is a VLAN bundle service interface EVI, and VIDs 200-250 are assigned to EVI200, the CE-VID bundle 200-250 must be provisioned on PE1, PE2, and PE3. Note that this model does not allow CE-VID translation and the CEs must use the same CE-VIDs for EVI200. No auto-derived EVI RDs or EVI RTs are possible.
假设EVI200是VLAN捆绑服务接口EVI，并且VID 200-250分配给EVI200，则必须在PE1、PE2和PE3上配置CE-VID捆绑200-250。请注意，此型号不允许CE-VID转换，CEs必须为EVI200使用相同的CE-VID。不可能自动导出EVI RDs或EVI RTs。
If EVI300 is a VLAN-aware bundling service interface EVI, CE-VID binding to EVI300 does not have to match on the three PEs (only on PE1 and PE2, since they are part of the same ES). For example, PE1 and PE2 CE-VID binding to EVI300 can be set to the range 300-310 and PE3 to 321-330. Note that each individual CE-VID will be assigned to a different broadcast domain, which will be represented by an Ethernet Tag in the control plane.
如果EVI300是支持VLAN的捆绑服务接口EVI，则绑定到EVI300的CE-VID不必在三个PE上匹配（仅在PE1和PE2上，因为它们是相同ES的一部分）。例如，绑定到EVI300的PE1和PE2 CE-VID可以设置为300-310和PE3到321-330的范围。注意，每个单独的CE-VID将被分配到不同的广播域，该广播域将由控制平面中的以太网标签表示。
Therefore, besides the CE-VID bundle range bound to EVI300 in each PE, associations between each individual CE-VID and the corresponding EVPN Ethernet Tag must be provisioned by the user. No auto-derived EVI RDs/RTs are possible.
因此，除了绑定到每个PE中EVI300的CE-VID捆绑范围外，每个单独的CE-VID和相应的EVPN以太网标签之间的关联必须由用户提供。不可能自动导出EVI RDs/RTs。
[RFC7432] defines four different route types and four different extended communities. However, not all the PEs in an EVPN network must generate and process all the different routes and extended communities. Table 1 shows the routes that must be exported and imported in the use case described in this document. "Export", in this context, means that the PE must be capable of generating and exporting a given route, assuming there are no BGP policies to prevent it. In the same way, "Import" means the PE must be capable of importing and processing a given route, assuming the right RTs and policies. "N/A" means neither import nor export actions are required.
[RFC7432]定义了四种不同的路线类型和四种不同的扩展社区。然而，并非EVPN网络中的所有PE都必须生成和处理所有不同的路由和扩展社区。表1显示了在本文档描述的用例中必须导出和导入的路由。在此上下文中，“导出”意味着PE必须能够生成和导出给定路由，前提是没有BGP策略来阻止它。同样，“导入”意味着PE必须能够导入和处理给定的路由，并假设正确的RTs和策略。“不适用”表示不需要进口或出口操作。
+-----------------+---------------+---------------+
| BGP EVPN Routes | PE1-PE2 | PE3 |
+-----------------+---------------+---------------+
| ES | Export/Import | N/A |
| A-D per ESI | Export/Import | Import |
| A-D per EVI | Export/Import | Import |
| MAC | Export/Import | Export/Import |
| Inclusive Mcast | Export/Import | Export/Import |
+-----------------+---------------+---------------+
+-----------------+---------------+---------------+
| BGP EVPN Routes | PE1-PE2 | PE3 |
+-----------------+---------------+---------------+
| ES | Export/Import | N/A |
| A-D per ESI | Export/Import | Import |
| A-D per EVI | Export/Import | Import |
| MAC | Export/Import | Export/Import |
| Inclusive Mcast | Export/Import | Export/Import |
+-----------------+---------------+---------------+
Table 1: Base EVPN Routes and Export/Import Actions
表1：基本EVPN路由和导出/导入操作
PE3 is required to export only MAC and Inclusive Multicast (Mcast) routes and be able to import and process A-D routes as well as MAC and Inclusive Multicast routes. If PE3 did not support importing and processing A-D routes per ESI and per EVI, fast convergence and aliasing functions (respectively) would not be possible in this use case.
PE3只需要导出MAC和包含性多播（Mcast）路由，并且能够导入和处理A-D路由以及MAC和包含性多播路由。如果PE3不支持按照ESI和EVI导入和处理A-D路由，那么在这种情况下，快速收敛和混叠功能（分别）将不可能实现。
This section describes how the BGP EVPN routes are exported and imported by the PEs in our use case as well as how traffic is forwarded assuming that PE1, PE2, and PE3 support a MAC-based forwarding model. In order to compare the control- and data-plane impact in the two forwarding models (MAC-based and MPLS-based) and different service types, we will assume that CE1, CE2, and CE3 need to exchange traffic for up to 4k CE-VIDs.
本节描述了PEs在我们的用例中如何导出和导入BGP EVPN路由，以及假设PE1、PE2和PE3支持基于MAC的转发模型，如何转发流量。为了比较两种转发模型（基于MAC和基于MPLS）和不同服务类型中的控制和数据平面影响，我们假设CE1、CE2和CE3需要为最多4k CE视频交换流量。
Before any EVI is provisioned in the network, the following procedures are required:
在网络中配置任何EVI之前，需要执行以下步骤：
o Infrastructure setup: The proper MPLS infrastructure must be set up among PE1, PE2, and PE3 so that the EVPN services can make use of Point-to-Point (P2P) and P2MP LSPs. In addition to the MPLS transport, PE1 and PE2 must be properly configured with the same LACP configuration to CE2. Details are provided in [RFC7432]. Once the LAG is properly set up, the ESI for the CE2 Ethernet Segment (for example, ESI12) can be auto-generated by PE1 and PE2 from the LACP information exchanged with CE2 (ESI Type 1), as discussed in Section 4.1. Alternatively, the ESI can also be manually provisioned on PE1 and PE2 (ESI Type 0). PE1 and PE2 will auto-configure a BGP policy that will import any ES route matching the auto-derived ES-Import RT for ESI12.
o 基础设施设置：必须在PE1、PE2和PE3之间设置适当的MPLS基础设施，以便EVPN服务可以使用点对点（P2P）和P2MP LSP。除了MPLS传输，PE1和PE2必须正确配置为与CE2相同的LACP配置。有关详细信息，请参见[RFC7432]。正确设置滞后后，PE1和PE2可根据与CE2交换的LACP信息（ESI类型1）自动生成CE2以太网段的ESI（例如，ESI12），如第4.1节所述。或者，也可以在PE1和PE2上手动配置ESI（ESI类型0）。PE1和PE2将自动配置BGP策略，该策略将导入与ESI12的自动派生ES导入RT匹配的任何ES路由。
o Ethernet Segment route exchange and Designated Forwarder (DF) election: PE1 and PE2 will advertise a BGP Ethernet Segment route for ESI12, where the ESI RD and ES-Import RT will be auto-generated as discussed in Section 4.1.1. PE1 and PE2 will import the ES routes of each other and will run the DF election algorithm for any existing EVI (if any, at this point). PE3 will simply discard the route. Note that the DF election algorithm can support service carving so that the downstream BUM traffic from the network to CE2 can be load-balanced across PE1 and PE2 on a per-service basis.
o 以太网段路由交换和指定转发器（DF）选择：PE1和PE2将公布ESI12的BGP以太网段路由，其中ESI RD和ES导入RT将自动生成，如第4.1.1节所述。PE1和PE2将导入彼此的ES路由，并对任何现有EVI（如果有）运行DF选举算法。PE3将简单地放弃该路线。请注意，DF选举算法可以支持服务分割，以便从网络到CE2的下游BUM流量可以在每个服务的基础上跨PE1和PE2进行负载平衡。
At the end of this process, the network infrastructure is ready to start deploying EVPN services. PE1 and PE2 are aware of the existence of a shared Ethernet Segment, i.e., ESI12.
在该过程结束时，网络基础设施已准备好开始部署EVPN服务。PE1和PE2知道存在共享以太网段，即ESI12。
Assuming that the EVPN network must carry traffic among CE1, CE2, and CE3 for up to 4k CE-VIDs, the service provider can decide to implement VLAN-based service interface EVIs to accomplish it. In this case, each CE-VID will be individually mapped to a different EVI. While this means a total number of 4k MAC-VRFs are required per PE, the advantages of this approach are the auto-provisioning of most of the service parameters if no VLAN translation is needed (see Section 4.2.1) and great control over each individual customer broadcast domain. We assume in this section that the range of EVIs from 1 to 4k is provisioned in the network.
假设EVPN网络必须在CE1、CE2和CE3之间承载最多4k CE VID的流量，服务提供商可以决定实现基于VLAN的服务接口EVI来实现它。在这种情况下，每个CE-VID将分别映射到不同的EVI。虽然这意味着每个PE需要总共4k MAC VRF，但这种方法的优点是，如果不需要VLAN转换（参见第4.2.1节），则可以自动提供大多数服务参数，并且可以很好地控制每个客户广播域。在本节中，我们假设在网络中提供了从1到4k的EVI范围。
As soon as the EVIs are created in PE1, PE2, and PE3, the following control-plane actions are carried out:
一旦在PE1、PE2和PE3中创建EVI，将执行以下控制平面操作：
o Flooding tree setup per EVI (4k routes): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per PE) so that the flooding tree per EVI can be set up. Note that ingress replication or P2MP LSPs can be optionally signaled in the Provider Multicast Service Interface (PMSI) Tunnel attribute and the corresponding tree can be created.
o 每个EVI的泛洪树设置（4k路由）：每个PE将每个EVI发送一个包含多播以太网标记路由（每个PE最多4k路由），以便可以设置每个EVI的泛洪树。请注意，入口复制或P2MP LSP可以选择在提供者多播服务接口（PMSI）隧道属性中发出信号，并且可以创建相应的树。
o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of A-D routes with a total list of 4k RTs (one per EVI) for ESI12 will be issued from PE1 and PE2 (it has to be a set of routes so that the total number of RTs can be conveyed). As per [RFC7432], each Ethernet A-D route per ESI is differentiated from the other routes in the set by a different Route Distinguisher (ES RD). This set will also include ESI Label extended communities with the active-standby flag set to zero (all-active multihoming type) and an ESI Label different from zero (used for split-horizon functions). These routes will be imported by the three PEs, since the RTs match the locally configured EVI RTs. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as discussed in [RFC7432].
o 每个ESI的以太网A-D路由（ESI12的一组路由）：将从PE1和PE2发出一组A-D路由，其中ESI12的总列表为4k RTs（每个EVI一个）（必须是一组路由，以便传输RTs的总数）。根据[RFC7432]，每个ESI的每个以太网A-D路由通过不同的路由识别器（ES-RD）与集合中的其他路由进行区分。此集合还将包括ESI标签扩展社区，其主备用标志设置为零（所有主动多主类型）和不同于零的ESI标签（用于拆分地平线功能）。这些路由将由三个PE导入，因为RTs与本地配置的EVI RTs匹配。如[RFC7432]所述，每个ESI的A-D路由将用于快速收敛和分裂地平线函数。
o Ethernet A-D routes per EVI (4k routes): An A-D route per EVI will be sent by PE1 and PE2 for ESI12. Each individual route includes the corresponding EVI RT and an MPLS Label to be used by PE3 for the aliasing function. These routes will be imported by the three PEs.
o 每个EVI的以太网A-D路由（4k路由）：每个EVI的A-D路由将由PE1和PE2为ESI12发送。每个单独的路由包括相应的EVI-RT和一个MPLS标签，供PE3用于别名功能。这些路线将由三个PEs导入。
Once the services are set up, the traffic can start flowing. Assuming there are no MAC addresses learned yet and that MAC learning at the access is performed in the data plane in our use case, this is the process followed upon receiving frames from each CE (for example, EVI1).
一旦服务建立起来，交通就可以开始流动了。假设还没有学习到MAC地址，并且在我们的用例中在数据平面中执行访问时的MAC学习，这是从每个CE（例如EVI1）接收帧之后的过程。
BUM frame example from CE1:
CE1中的BUM框架示例：
a. An ARP request with CE-VID=1 is issued from source MAC CE1-MAC (MAC address coming from CE1 or from a device connected to CE1) to find the MAC address of CE3-IP.
a. CE-VID=1的ARP请求从源MAC CE1-MAC（MAC地址来自CE1或连接到CE1的设备）发出，以查找CE3-IP的MAC地址。
b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 (EVI1) context. A source MAC lookup is done in the MAC FIB, and the sender's CE1-IP is looked up in the proxy ARP table within the MAC-VRF-1 (EVI1) context. If CE1-MAC/CE1-IP are unknown in both tables, three actions are carried out (assuming the source MAC is accepted by PE1):
b. 基于CE-VID，帧被识别为在MAC-VRF-1（EVI1）上下文中转发。源MAC查找在MAC FIB中完成，发送方的CE1-IP在MAC-VRF-1（EVI1）上下文中的代理ARP表中查找。如果两个表中的CE1-MAC/CE1-IP未知，则执行三个操作（假设PE1接受源MAC）：
1. the forwarding state is added for the CE1-MAC associated with the corresponding port and CE-VID;
1. 为与相应端口和CE-VID相关联的CE1-MAC添加转发状态；
2. the ARP request is snooped and the tuple CE1-MAC/CE1-IP is added to the proxy ARP table; and
2. 监听ARP请求，将元组CE1-MAC/CE1-IP添加到代理ARP表中；和
3. a BGP MAC Advertisement route is triggered from PE1 containing the EVI1 RD and RT, ESI=0, Ethernet-Tag=0, and CE1-MAC/CE1-IP, along with an MPLS Label assigned to MAC-VRF-1 from the PE1 Label space. Note that depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one (one containing only the CE1-MAC and another one containing CE1-MAC/CE1-IP).
3. BGP MAC播发路由从PE1触发，其中包含EVI1 RD和RT、ESI=0、以太网标签=0和CE1-MAC/CE1-IP，以及从PE1标签空间分配给MAC-VRF-1的MPLS标签。注意，根据实现，MAC FIB和代理ARP学习过程可以独立地发送两个BGP MAC广告，而不是一个（一个仅包含CE1-MAC，另一个包含CE1-MAC/CE1-IP）。
Since we assume a MAC forwarding model, a label per MAC-VRF is normally allocated and signaled by the three PEs for MAC Advertisement routes. Based on the RT, the route is imported by PE2 and PE3, and the forwarding state plus the ARP entry are added to their MAC-VRF-1 context. From this moment on, any ARP request from CE2 or CE3 destined to CE1-IP can be directly replied to by PE1, PE2, or PE3, and ARP flooding for CE1-IP is not needed in the core.
由于我们假设MAC转发模型，每个MAC-VRF的标签通常由三个PE为MAC广告路由分配和发信号。基于RT，路由由PE2和PE3导入，转发状态加上ARP条目添加到它们的MAC-VRF-1上下文中。从这一刻起，来自CE2或CE3的任何ARP请求都可以直接由PE1、PE2或PE3响应，核心中不需要CE1-IP的ARP洪泛。
c. Since the ARP frame is a broadcast frame, it is forwarded by PE1 using the Inclusive Multicast Tree for EVI1 (CE-VID=1 tag should be kept if translation is required). Depending on the type of tree, the label stack may vary. For example, assuming ingress replication, the packet is replicated to PE2 and PE3 with the downstream allocated labels and the P2P LSP transport labels. No other labels are added to the stack.
c. 由于ARP帧是广播帧，它由PE1使用EVI1的包含式多播树转发（如果需要翻译，则应保留CE-VID=1标记）。根据树的类型，标签堆栈可能会有所不同。例如，假设入口复制，则使用下游分配的标签和P2P LSP传输标签将分组复制到PE2和PE3。不会将其他标签添加到堆栈中。
d. Assuming PE1 is the DF for EVI1 on ESI12, the frame is locally replicated to CE2.
d. 假设PE1是ESI12上EVI1的DF，则该帧在本地复制到CE2。
e. The MPLS-encapsulated frame gets to PE2 and PE3. Since PE2 is non-DF for EVI1 on ESI12, and there is no other CE connected to PE2, the frame is discarded. At PE3, the frame is de-encapsulated and the CE-VID is translated, if needed, and forwarded to CE3.
e. MPLS封装的帧到达PE2和PE3。由于PE2对于ESI12上的EVI1是非DF的，并且没有其他CE连接到PE2，因此该帧被丢弃。在PE3，帧被去封装，CE-VID被翻译（如果需要），并转发到CE3。
Any other type of BUM frame from CE1 would follow the same procedures. BUM frames from CE3 would follow the same procedures too.
来自CE1的任何其他类型的BUM框架将遵循相同的程序。来自CE3的BUM帧也将遵循相同的程序。
BUM frame example from CE2:
CE2中的BUM框架示例：
a. An ARP request with CE-VID=1 is issued from source MAC CE2-MAC to find the MAC address of CE3-IP.
a. CE-VID=1的ARP请求从源MAC CE2-MAC发出，以查找CE3-IP的MAC地址。
b. CE2 will hash the frame and will forward it to, for example, PE2. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB and the sender's CE2-IP is looked up in the proxy ARP table within the MAC-VRF-1 context. If both are unknown, three actions are carried out (assuming the source MAC is accepted by PE2):
b. CE2将对帧进行散列，并将其转发给（例如）PE2。基于CE-VID，帧被标识为在EVI1上下文中转发。源MAC查找在MAC FIB中完成，发送方的CE2-IP在MAC-VRF-1上下文中的代理ARP表中查找。如果两者都未知，则执行三个操作（假设PE2接受源MAC）：
1. the forwarding state is added for the CE2-MAC associated with the corresponding LAG/ESI and CE-VID;
1. 为与相应的LAG/ESI和CE-VID相关联的CE2-MAC添加转发状态；
2. the ARP request is snooped and the tuple CE2-MAC/CE2-IP is added to the proxy ARP table; and
2. 监听ARP请求，将元组CE2-MAC/CE2-IP添加到代理ARP表中；和
3. a BGP MAC Advertisement route is triggered from PE2 containing the EVI1 RD and RT, ESI=12, Ethernet-Tag=0, and CE2-MAC/CE2-IP, along with an MPLS Label assigned from the PE2 Label space (one label per MAC-VRF). Again, depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one.
3. BGP MAC播发路由从PE2触发，其中包含EVI1 RD和RT、ESI=12、以太网标签=0和CE2-MAC/CE2-IP，以及从PE2标签空间分配的MPLS标签（每个MAC-VRF一个标签）。同样，根据实现，MAC FIB和代理ARP学习过程可以独立地发送两个BGP MAC广告，而不是一个。
Note that since PE3 is not part of ESI12, it will install the forwarding state for CE2-MAC as long as the A-D routes for ESI12 are also active on PE3. On the contrary, PE1 is part of ESI12, therefore PE1 will not modify the forwarding state for CE2-MAC if it has previously learned CE2-MAC locally attached to ESI12. Otherwise, it will add the forwarding state for CE2-MAC associated with the local ESI12 port.
注意，由于PE3不是ESI12的一部分，只要ESI12的A-D路由在PE3上也处于活动状态，它就会为CE2-MAC安装转发状态。相反，PE1是ESI12的一部分，因此，如果PE1之前已经了解到CE2-MAC本地连接到ESI12，则不会修改CE2-MAC的转发状态。否则，它将为与本地ESI12端口关联的CE2-MAC添加转发状态。
c. Assuming PE2 does not have the ARP information for CE3-IP yet, and since the ARP is a broadcast frame and PE2 is the non-DF for EVI1 on ESI12, the frame is forwarded by PE2 in the Inclusive Multicast Tree for EVI1, thus adding the ESI Label for ESI12 at the bottom of the stack. The ESI Label has been previously allocated and signaled by the A-D routes for ESI12. Note that, as per [RFC7432], if the result of the CE2 hashing is different and the frame is sent to PE1, PE1 should add the ESI Label too (PE1 is the DF for EVI1 on ESI12).
c. 假设PE2还没有CE3-IP的ARP信息，并且由于ARP是广播帧，PE2是ESI12上EVI1的非DF，该帧由PE2在EVI1的包容性多播树中转发，从而在堆栈底部添加ESI12的ESI标签。ESI标签先前已由ESI12的A-D路由分配和发出信号。注意，根据[RFC7432]，如果CE2散列的结果不同，并且帧被发送到PE1，PE1也应该添加ESI标签（PE1是ESI12上EVI1的DF）。
d. The MPLS-encapsulated frame gets to PE1 and PE3. PE1 de-encapsulates the Inclusive Multicast Tree Label(s) and, based on the ESI Label at the bottom of the stack, it decides to not forward the frame to the ESI12. It will pop the ESI Label and will replicate it to CE1, since CE1 is not part of the ESI identified by the ESI Label. At PE3, the Inclusive Multicast Tree Label is popped and the frame forwarded to CE3. If a P2MP LSP is used as the Inclusive Multicast Tree for EVI1, PE3 will find an ESI Label after popping the P2MP LSP Label. The ESI Label will simply be popped, since CE3 is not part of ESI12.
d. MPLS封装的帧到达PE1和PE3。PE1取消封装包含多播树标签，并基于堆栈底部的ESI标签，决定不将帧转发给ESI12。它将弹出ESI标签并将其复制到CE1，因为CE1不是ESI标签标识的ESI的一部分。在PE3，弹出包含多播树标签，并将帧转发给CE3。如果P2MP LSP用作EVI1的包含多播树，PE3将在弹出P2MP LSP标签后找到ESI标签。ESI标签将简单地弹出，因为CE3不是ESI12的一部分。
Unicast frame example from CE3 to CE1:
从CE3到CE1的单播帧示例：
a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE1-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE1-IP and has added CE3-MAC/CE3-IP to its proxy ARP table).
a. CE-VID=1的单播帧从源MAC CE3-MAC和目标MAC CE1-MAC发出（我们假设PE3之前已解析来自CE3的ARP请求，以查找CE1-IP的MAC，并已将CE3-MAC/CE3-IP添加到其代理ARP表中）。
b. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB within the MAC-VRF-1 context and this time, since we assume CE3-MAC is known, no further actions are carried out as a result of the source lookup. A destination MAC lookup is performed next and the label stack associated with the MAC CE1-MAC is found (including the label associated with MAC-VRF-1 in PE1 and the P2P LSP Label to get to PE1). The unicast frame is then encapsulated and forwarded to PE1.
b. 基于CE-VID，帧被标识为在EVI1上下文中转发。源MAC查找在MAC-VRF-1上下文中的MAC FIB中完成，这一次，由于我们假设已知CE3-MAC，因此源查找不会执行进一步的操作。接下来执行目的地MAC查找，并找到与MAC CE1-MAC相关联的标签堆栈（包括与PE1中的MAC-VRF-1相关联的标签以及到达PE1的P2P LSP标签）。单播帧随后被封装并转发到PE1。
c. At PE1, the packet is identified to be part of EVI1 and a destination MAC lookup is performed in the MAC-VRF-1 context. The labels are popped and the frame is forwarded to CE1 with CE-VID=1.
c. 在PE1，分组被标识为EVI1的一部分，并且在MAC-VRF-1上下文中执行目的地MAC查找。弹出标签并将帧转发至CE-VID=1的CE1。
Unicast frames from CE1 to CE3 or from CE2 to CE3 follow the same procedures described above.
从CE1到CE3或从CE2到CE3的单播帧遵循上述相同的过程。
Unicast frame example from CE3 to CE2:
从CE3到CE2的单播帧示例：
a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE2-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE2-IP).
a. CE-VID=1的单播帧从源MAC CE3-MAC和目标MAC CE2-MAC发出（我们假设PE3先前已解析来自CE3的ARP请求，以查找CE2-IP的MAC）。
b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 context. We assume CE3-MAC is known. A destination MAC lookup is performed next and PE3 finds CE2-MAC associated with PE2 on ESI12, an Ethernet Segment for which PE3 has two active A-D routes per ESI (from PE1 and PE2) and two active A-D routes for EVI1 (from PE1 and PE2). Based on a
b. 基于CE-VID，帧被识别为在MAC-VRF-1上下文中转发。我们假设已知CE3-MAC。接下来执行目的地MAC查找，PE3在ESI12上找到与PE2相关联的CE2-MAC，对于该以太网段，PE3每个ESI有两条活动A-D路由（来自PE1和PE2），EVI1有两条活动A-D路由（来自PE1和PE2）。基于
hashing function for the frame, PE3 may decide to forward the frame using the label stack associated with PE2 (label received from the MAC Advertisement route) or the label stack associated with PE1 (label received from the A-D route per EVI for EVI1). Either way, the frame is encapsulated and sent to the remote PE.
对于帧的哈希函数，PE3可以决定使用与PE2相关联的标签堆栈（从MAC广告路由接收的标签）或与PE1相关联的标签堆栈（对于EVI，每个EVI从A-D路由接收的标签）转发帧。无论哪种方式，帧都被封装并发送到远程PE。
c. At PE2 (or PE1), the packet is identified to be part of EVI1 based on the bottom label, and a destination MAC lookup is performed. At either PE (PE2 or PE1), the FIB lookup yields a local ESI12 port to which the frame is sent.
c. 在PE2（或PE1），基于底部标签将分组标识为EVI1的一部分，并且执行目的地MAC查找。在任何一个PE（PE2或PE1）上，FIB查找都会产生一个本地ESI12端口，将帧发送到该端口。
Unicast frames from CE1 to CE2 follow the same procedures.
从CE1到CE2的单播帧遵循相同的过程。
Instead of using VLAN-based interfaces, the operator can choose to implement VLAN bundle interfaces to carry the traffic for the 4k CE-VIDs among CE1, CE2, and CE3. If that is the case, the 4k CE-VIDs can be mapped to the same EVI (for example, EVI200) at each PE. The main advantage of this approach is the low control-plane overhead (reduced number of routes and labels) and easiness of provisioning at the expense of no control over the customer broadcast domains, i.e., a single Inclusive Multicast Tree for all the CE-VIDs and no CE-VID translation in the provider network.
不使用基于VLAN的接口，运营商可以选择实施VLAN捆绑接口，以在CE1、CE2和CE3之间承载4k CE VID的流量。如果是这种情况，则4k CE vid可以映射到每个PE处的相同EVI（例如EVI200）。该方法的主要优点是低控制平面开销（减少路由和标签的数量）和易于供应，而不以对客户广播域的控制为代价，即，为所有CE-VID提供一个包含多播树，并且在提供商网络中没有CE-VID转换。
As soon as the EVI200 is created in PE1, PE2, and PE3, the following control-plane actions are carried out:
在PE1、PE2和PE3中创建EVI200后，将立即执行以下控制平面操作：
o Flooding tree setup per EVI (one route): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI (hence, only one route per PE) so that the flooding tree per EVI can be set up. Note that ingress replication or P2MP LSPs can optionally be signaled in the PMSI Tunnel attribute and the corresponding tree can be created.
o 每个EVI的泛洪树设置（一条路由）：每个PE将每个EVI发送一条包含多播以太网标记路由（因此，每个PE只有一条路由），以便可以设置每个EVI的泛洪树。注意，入口复制或P2MP LSP可以选择在PMSI隧道属性中发出信号，并且可以创建相应的树。
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D route for ESI12 will be issued from PE1 and PE2. This route will include a single RT (RT for EVI200), an ESI Label extended community with the active-standby flag set to zero (all-active multihoming type), and an ESI Label different from zero (used by the non-DF for split-horizon functions). This route will be imported by the three PEs, since the RT matches the locally configured EVI200 RT. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as described in [RFC7432].
o 每个ESI的以太网A-D路由（ESI12的一条路由）：将从PE1和PE2发出ESI12的一条A-D路由。该路由将包括一个单独的RT（EVI200的RT）、一个ESI标签扩展社区（主动待机标志设置为零）（所有主动多主类型）和一个不同于零的ESI标签（非DF用于分割地平线功能）。由于RT与本地配置的EVI200 RT相匹配，该路由将由三个PE导入。每个ESI的A-D路由将用于快速收敛和拆分地平线功能，如[RFC7432]所述。
o Ethernet A-D routes per EVI (one route): An A-D route (EVI200) will be sent by PE1 and PE2 for ESI12. This route includes the EVI200 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs.
o 每个EVI的以太网A-D路由（一条路由）：PE1和PE2将为ESI12发送A-D路由（EVI200）。此路由包括EVI200 RT和一个MPLS标签，供PE3用于别名功能。这条路线将由三个PEs导入。
The packet walk-through for the VLAN bundle case is similar to the one described for EVI1 in the VLAN-based case except for the way the CE-VID is handled by the ingress PE and the egress PE:
VLAN捆绑情况下的数据包漫游与基于VLAN情况下EVI1的数据包漫游类似，但CE-VID由入口PE和出口PE处理的方式不同：
o No VLAN translation is allowed and the CE-VIDs are kept untouched from CE to CE, i.e., the ingress CE-VID must be kept at the imposition PE and at the disposition PE.
o 不允许VLAN转换，CE-VID在CE之间保持不变，即，入口CE-VID必须保持在强制PE和处置PE。
o The frame is identified to be forwarded in the MAC-VRF-200 context as long as its CE-VID belongs to the VLAN bundle defined in the PE1/PE2/PE3 port to CE1/CE2/CE3. Our example is a special VLAN bundle case since the entire CE-VID range is defined in the ports; therefore, any CE-VID would be part of EVI200.
o 只要帧的CE-VID属于PE1/PE2/PE3端口到CE1/CE2/CE3中定义的VLAN包，则该帧被标识为在MAC-VRF-200上下文中转发。我们的示例是一个特殊的VLAN包案例，因为整个CE-VID范围在端口中定义；因此，任何CE-VID都是EVI200的一部分。
Please refer to Section 6.2.2 for more information about the control-plane and forwarding-plane interaction for BUM and unicast traffic from the different CEs.
有关来自不同CEs的BUM和单播流量的控制平面和转发平面交互的更多信息，请参阅第6.2.2节。
The last potential service type analyzed in this document is VLAN-aware bundling. When this type of service interface is used to carry the 4k CE-VIDs among CE1, CE2, and CE3, all the CE-VIDs will be mapped to the same EVI (for example, EVI300). The difference, compared to the VLAN bundle service type in the previous section, is that each incoming CE-VID will also be mapped to a different "normalized" Ethernet Tag in addition to EVI300. If no translation is required, the Ethernet Tag will match the CE-VID. Otherwise, a translation between CE-VID and Ethernet Tag will be needed at the imposition PE and at the disposition PE. The main advantage of this approach is the ability to control customer broadcast domains while providing a single EVI to the customer.
本文中分析的最后一种潜在服务类型是VLAN感知绑定。当此类型的服务接口用于在CE1、CE2和CE3之间承载4k CE VID时，所有CE VID将映射到同一EVI（例如EVI300）。与上一节中的VLAN捆绑服务类型相比，不同之处在于，除了EVI300之外，每个传入的CE-VID还将映射到不同的“规范化”以太网标签。如果不需要翻译，以太网标签将与CE-VID匹配。否则，在强制PE和处置PE处将需要CE-VID和以太网标签之间的转换。这种方法的主要优点是能够控制客户广播域，同时向客户提供单个EVI。
As soon as the EVI300 is created in PE1, PE2, and PE3, the following control-plane actions are carried out:
在PE1、PE2和PE3中创建EVI300后，将立即执行以下控制平面操作：
o Flooding tree setup per EVI per Ethernet Tag (4k routes): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI and per Ethernet Tag (hence, 4k routes per PE) so that the flooding
o 每个EVI每个以太网标记的泛洪树设置（4k路由）：每个PE将每个EVI和每个以太网标记发送一个包含多播以太网标记路由（因此，每个PE有4k路由），以便泛洪
tree per customer broadcast domain can be set up. Note that ingress replication or P2MP LSPs can optionally be signaled in the PMSI Tunnel attribute and the corresponding tree be created. In the described use case, since all the CE-VIDs and Ethernet Tags are defined on the three PEs, multicast tree aggregation might make sense in order to save forwarding states.
可以设置每个客户广播域的树。注意，入口复制或P2MP LSP可以选择在PMSI隧道属性中发出信号，并创建相应的树。在所描述的用例中，由于所有CE-vid和以太网标签都是在三个pe上定义的，因此多播树聚合可能有助于保存转发状态。
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D route for ESI12 will be issued from PE1 and PE2. This route will include a single RT (RT for EVI300), an ESI Label extended community with the active-standby flag set to zero (all-active multihoming type), and an ESI Label different than zero (used by the non-DF for split-horizon functions). This route will be imported by the three PEs, since the RT matches the locally configured EVI300 RT. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as described in [RFC7432].
o 每个ESI的以太网A-D路由（ESI12的一条路由）：将从PE1和PE2发出ESI12的一条A-D路由。该路由将包括一个单独的RT（EVI300的RT）、一个ESI标签扩展社区（主动待机标志设置为零）（所有主动多主类型）和一个不同于零的ESI标签（非DF用于分割地平线功能）。由于RT与本地配置的EVI300 RT相匹配，该路由将由三个PE导入。每个ESI的A-D路由将用于快速收敛和拆分地平线功能，如[RFC7432]所述。
o Ethernet A-D routes per EVI: A single A-D route (EVI300) may be sent by PE1 and PE2 for ESI12 in case no CE-VID translation is required. This route includes the EVI300 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs. Note that if CE-VID translation is required, an A-D per EVI route is required per Ethernet Tag (4k).
o 每个EVI的以太网A-D路由：如果不需要CE-VID转换，PE1和PE2可以为ESI12发送单个A-D路由（EVI300）。此路由包括EVI300 RT和一个MPLS标签，供PE3用于别名功能。这条路线将由三个PEs导入。注意，如果需要CE-VID转换，则每个以太网标签（4k）需要每个EVI路由的A-D。
The packet walk-through for the VLAN-aware case is similar to the one described before. Compared to the other two cases, VLAN-aware services allow for CE-VID translation and for an N:1 CE-VID to EVI mapping. Both things are not supported at once in either of the two other service interfaces. Some differences compared to the packet walk-through described in Section 6.2.2 are as follows:
VLAN感知案例的数据包遍历与前面描述的类似。与其他两种情况相比，支持VLAN的服务允许CE-VID转换和N:1 CE-VID到EVI映射。在其他两个服务接口中都不同时支持这两种功能。与第6.2.2节中描述的数据包遍历相比，有些差异如下：
o At the ingress PE, the frames are identified to be forwarded in the EVI300 context as long as their CE-VID belong to the range defined in the PE port to the CE. In addition to it, CE-VID=x is mapped to a "normalized" Ethernet-Tag=y at the MAC-VRF-300 (where x and y might be equal if no translation is needed). Qualified learning is now required (a different bridge table is allocated within MAC-VRF-300 for each Ethernet Tag). Potentially, the same MAC could be learned in two different Ethernet Tag bridge tables of the same MAC-VRF.
o 在入口PE处，只要帧的CE-VID属于PE端口到CE中定义的范围，帧就被标识为在EVI300上下文中转发。除此之外，CE-VID=x被映射到MAC-VRF-300上的“标准化”以太网标签=y（其中，如果不需要转换，x和y可能相等）。现在需要合格的学习（MAC-VRF-300中为每个以太网标签分配了不同的桥接表）。潜在地，可以在同一MAC-VRF的两个不同以太网标签桥接表中学习相同的MAC。
o Any new locally learned MAC on the MAC-VRF-300/Ethernet-Tag=y interface is advertised by the ingress PE in a MAC Advertisement route using the now Ethernet Tag field (Ethernet-Tag=y) so that the remote PE learns the MAC associated with the MAC-VRF-300/
o MAC-VRF-300/Ethernet Tag=y接口上的任何新本地学习的MAC由入口PE在MAC广告路由中使用now Ethernet Tag字段（Ethernet Tag=y）进行广告，以便远程PE学习与MAC-VRF-300相关联的MAC/
Ethernet-Tag=y FIB. Note that the Ethernet Tag field is not used in advertisements of MACs learned on VLAN-based or VLAN-bundle service interfaces.
以太网标签=y FIB。请注意，Ethernet Tag字段不用于在基于VLAN或VLAN捆绑服务接口上学习的MAC广告中。
o At the ingress PE, BUM frames are sent to the corresponding flooding tree for the particular Ethernet Tag they are mapped to. Each individual Ethernet Tag can have a different flooding tree within the same EVI300. For instance, Ethernet-Tag=y can use ingress replication to get to the remote PEs, whereas Ethernet-Tag=z can use a P2MP LSP.
o 在入口PE处，BUM帧被发送到对应的泛洪树，用于它们被映射到的特定以太网标签。每个单独的以太网标签可以在同一个EVI300中具有不同的泛洪树。例如，Ethernet Tag=y可以使用入口复制来访问远程PEs，而Ethernet Tag=z可以使用P2MP LSP。
o At the egress PE, Ethernet-Tag=y (for a given broadcast domain within MAC-VRF-300) can be translated to egress CE-VID=x. That is not possible for VLAN bundle interfaces. It is possible for VLAN-based interfaces, but it requires a separate MAC-VRF per CE-VID.
o 在出口PE处，以太网标签＝y（对于MAC-VRF-300内的给定广播域）可被转换为出口CE-VID＝x。这对于VLAN捆绑包接口是不可能的。基于VLAN的接口是可能的，但每个CE-VID需要单独的MAC-VRF。
EVPN supports an alternative forwarding model, usually referred to as the MPLS-based forwarding or disposition model, as opposed to the MAC-based forwarding or disposition model described in Section 6. Using the MPLS-based forwarding model instead of the MAC-based model might have an impact on the following:
EVPN支持替代转发模型，通常称为基于MPLS的转发或部署模型，与第6节中描述的基于MAC的转发或部署模型相反。使用基于MPLS的转发模型而不是基于MAC的模型可能会对以下方面产生影响：
o the number of forwarding states required; and
o 所需的转发状态数；和
o the FIB where the forwarding states are handled (MAC FIB or MPLS Label FIB (LFIB)).
o 处理转发状态的FIB（MAC FIB或MPLS标签FIB（LFIB））。
The MPLS-based forwarding model avoids the destination MAC lookup at the egress PE MAC FIB at the expense of increasing the number of next-hop forwarding states at the egress MPLS LFIB. This also has an impact on the control plane and the label allocation model, since an MPLS-based disposition PE must send as many routes and labels as required next-hops in the egress MAC-VRF. This concept is equivalent to the forwarding models supported in IP-VPNs at the egress PE, where an IP lookup in the IP-VPN FIB may or may not be necessary depending on the available next-hop forwarding states in the LFIB.
基于MPLS的转发模型避免了在出口PE MAC FIB处查找目的地MAC，代价是增加出口MPLS LFIB处的下一跳转发状态的数目。这也会对控制平面和标签分配模型产生影响，因为基于MPLS的部署PE必须在出口MAC-VRF的下一跳发送所需数量的路由和标签。此概念相当于出口PE的IP VPN中支持的转发模型，其中IP-VPN FIB中的IP查找可能是必要的，也可能不是必要的，这取决于LFIB中可用的下一跳转发状态。
The following subsections highlight the impact on the control- and data-plane procedures described in Section 6 when an MPLS-based forwarding model is used.
以下小节重点介绍了使用基于MPLS的转发模型时对第6节中描述的控制和数据平面过程的影响。
Note that both forwarding models are compatible and interoperable in the same network. The implementation of either model in each PE is a local decision to the PE node.
请注意，这两种转发模型在同一网络中兼容且可互操作。每个PE中任一模型的实现都是PE节点的本地决定。
The MPLS-based forwarding model has no impact on the procedures explained in Section 6.1.
基于MPLS的转发模型对第6.1节中解释的过程没有影响。
7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service Procedures
7.2. 基于MPLS的转发对基于VLAN的服务过程的影响
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of routes when all the service interfaces are based on VLAN. The differences for the use case described in this document are summarized in the following list:
与基于MAC的转发模型相比，当所有服务接口都基于VLAN时，基于MPLS的转发模型在路由数量上没有影响。本文档中描述的用例的差异总结在以下列表中：
o Flooding tree setup per EVI (4k routes per PE): There is no impact when compared to the MAC-based model.
o 每个EVI的泛洪树设置（每个PE 4k路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per ESI (one set of routes for ESI12 per PE): There is no impact compared to the MAC-based model.
o 每个ESI的以太网A-D路由（每个PE一组ESI12路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per EVI (4k routes per PE/ESI): There is no impact compared to the MAC-based model.
o 每个EVI的以太网A-D路由（每个PE/ESI的4k路由）：与基于MAC的模型相比没有影响。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. For example, if CE2 sends traffic from two different MACs to PE1, CE2-MAC1, and CE2-MAC2, the same MPLS Label=x can be re-used for both MAC advertisements, since they both share the same source ESI12. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough).
o MAC播发路由：不是为在同一MAC-VRF上本地学习的所有新MAC分配和播发相同的MPLS标签，而是必须为每个CE下一跳或MAC播发不同的标签，以便在出口PE不需要MAC FIB查找。通常，这意味着必须通告不同的标签（至少每个CE），尽管如果在转发状态方面需要更大的粒度（因此，更小的可伸缩性），PE可以决定实现每个MAC的标签。例如，如果CE2从两个不同的MAC向PE1、CE2-MAC1和CE2-MAC2发送通信量，则相同的MPLS标签=x可用于两个MAC广告，因为它们共享相同的源ESI12。由PE1实现在同一ES内为每个MAC使用不同的标签（即使每个ESI只有一个标签就足够了）。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane but will rather add forwarding states to the MPLS LFIB.
o 在数据平面上学习新的本地CE MAC地址时，PE1、PE2和PE3不会向MAC FIB添加转发状态，而是向MPLS LFIB添加转发状态。
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle Service Procedures
7.3. 基于MPLS的转发对VLAN包服务过程的影响
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of number of routes when all the service interfaces are VLAN bundle type. The differences for the use case described in this document are summarized in the following list:
与基于MAC的转发模型相比，当所有服务接口都是VLAN捆绑类型时，基于MPLS的转发模型在路由数量方面没有影响。本文档中描述的用例的差异总结在以下列表中：
o Flooding tree setup per EVI (one route): There is no impact compared to the MAC-based model.
o 每个EVI的泛洪树设置（一条路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model.
o 每个ESI的以太网A-D路由（每个PE一条ESI12路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per EVI (one route per PE/ESI): There is no impact compared to the MAC-based model since no VLAN translation is required.
o 每个EVI的以太网A-D路由（每个PE/ESI一条路由）：与基于MAC的模型相比没有影响，因为不需要VLAN转换。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough).
o MAC播发路由：不是为在同一MAC-VRF上本地学习的所有新MAC分配和播发相同的MPLS标签，而是必须为每个CE下一跳或MAC播发不同的标签，以便在出口PE不需要MAC FIB查找。通常，这意味着必须通告不同的标签（至少每个CE），尽管如果在转发状态方面需要更大的粒度（因此，更小的可伸缩性），PE可以决定实现每个MAC的标签。由PE1实现在同一ES内为每个MAC使用不同的标签（即使每个ESI只有一个标签就足够了）。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane, but will rather add forwarding states to the MPLS LFIB.
o 在数据平面上学习新的本地CE MAC地址时，PE1、PE2和PE3不会向MAC FIB添加转发状态，而是向MPLS LFIB添加转发状态。
7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service Procedures
7.4. 基于MPLS的转发对VLAN感知服务过程的影响
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of A-D routes when all the service interfaces are of the VLAN-aware bundle type. The differences for the use case described in this document are summarized in the following list:
与基于MAC的转发模型相比，当所有服务接口都是VLAN感知包类型时，基于MPLS的转发模型在A-D路由数量方面没有影响。本文档中描述的用例的差异总结在以下列表中：
o Flooding tree setup per EVI (4k routes per PE): There is no impact compared to the MAC-based model.
o 每个EVI的泛洪树设置（每个PE 4k路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model.
o 每个ESI的以太网A-D路由（每个PE一条ESI12路由）：与基于MAC的模型相比没有影响。
o Ethernet A-D routes per EVI (1 route per ESI or 4k routes per PE/ ESI): PE1 and PE2 may send one route per ESI if no CE-VID translation is needed. However, 4k routes are normally sent for EVI300, one per <ESI, Ethernet Tag ID> tuple. This allows the egress PE to find out all the forwarding information in the MPLS LFIB and even support Ethernet Tag to CE-VID translation at the egress.
o 每个EVI的以太网A-D路由（每个ESI 1个路由或每个PE/ESI 4k路由）：如果不需要CE-VID转换，PE1和PE2可以每个ESI发送一个路由。然而，通常为EVI300发送4k路由，每个<ESI，以太网标签ID>元组一条。这允许出口PE找出MPLS LFIB中的所有转发信息，甚至在出口处支持以太网标签到CE-VID的转换。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. It is up to the PE1 implementation to use a different label per individual MAC within the same ES. Note that the Ethernet Tag will be set to a non-zero value for the MAC Advertisement routes. The same MAC address can be announced with a different Ethernet Tag value. This will make the advertising PE install two different forwarding states in the MPLS LFIB.
o MAC播发路由：不是为在同一MAC-VRF上本地学习的所有新MAC分配和播发相同的MPLS标签，而是必须为每个CE下一跳或MAC播发不同的标签，以便在出口PE不需要MAC FIB查找。通常，这意味着必须通告不同的标签（至少每个CE），尽管如果在转发状态方面需要更大的粒度（因此，更小的可伸缩性），PE可以决定实现每个MAC的标签。由PE1实现在同一ES内为每个MAC使用不同的标签。注意，以太网标签将被设置为MAC广告路由的非零值。相同的MAC地址可以用不同的以太网标签值来宣布。这将使广告PE在MPLS LFIB中安装两种不同的转发状态。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane but will rather add forwarding states to the MPLS LFIB.
o 在数据平面上学习新的本地CE MAC地址时，PE1、PE2和PE3不会向MAC FIB添加转发状态，而是向MPLS LFIB添加转发状态。
Both forwarding models are possible in a network deployment, and each one has its own trade-offs.
这两种转发模式在网络部署中都是可能的，并且每种转发模式都有自己的权衡。
Both forwarding models can save A-D routes per EVI when VLAN-aware bundling services are deployed and no CE-VID translation is required. While this saves a significant amount of routes, customers normally require CE-VID translation; hence, we assume an A-D per EVI route per <ESI, Ethernet Tag> is needed.
当部署支持VLAN的捆绑服务且不需要CE-VID转换时，这两种转发模型都可以为每个EVI节省A-D路由。虽然这节省了大量的路线，但客户通常需要CE-VID翻译；因此，我们假设需要A-D per EVI route per<ESI，Ethernet Tag>。
The MAC-based model saves a significant amount of MPLS Labels compared to the MPLS-based forwarding model. All the MACs and A-D routes for the same EVI can signal the same MPLS Label, saving labels from the local PE space. A MAC FIB lookup at the egress PE is required in order to do so.
与基于MPLS的转发模型相比，基于MAC的模型节省了大量MPLS标签。同一EVI的所有MAC和A-D路由可以发送相同MPLS标签的信号，从而从本地PE空间保存标签。为此，需要在出口PE处进行MAC FIB查找。
The MPLS-based forwarding model can save forwarding states at the egress PEs if labels per next-hop CE (as opposed to per MAC) are implemented. No egress MAC lookup is required. Also, a different label per next-hop CE per MAC-VRF is consumed, as opposed to a single label per MAC-VRF.
如果实现每下一跳CE（而不是每MAC）的标签，则基于MPLS的转发模型可以在出口PE处保存转发状态。不需要出口MAC查找。此外，与每个MAC-VRF使用一个标签不同，每个MAC-VRF使用一个不同的标签。
Table 2 summarizes the resource implementation details of both models.
表2总结了两种模型的资源实现细节。
+-----------------------------+-----------------+------------------+
| Resources | MAC-Based Model | MPLS-Based Model |
+-----------------------------+-----------------+------------------+
| MPLS Labels Consumed | 1 per MAC-VRF | 1 per CE/EVI |
| Egress PE Forwarding States | 1 per MAC | 1 per Next-Hop |
| Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) |
+-----------------------------+-----------------+------------------+
+-----------------------------+-----------------+------------------+
| Resources | MAC-Based Model | MPLS-Based Model |
+-----------------------------+-----------------+------------------+
| MPLS Labels Consumed | 1 per MAC-VRF | 1 per CE/EVI |
| Egress PE Forwarding States | 1 per MAC | 1 per Next-Hop |
| Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) |
+-----------------------------+-----------------+------------------+
Table 2: Resource Comparison between MAC-Based and MPLS-Based Models
表2：基于MAC和基于MPLS的模型之间的资源比较
The egress forwarding model is an implementation local to the egress PE and is independent of the model supported on the rest of the PEs; i.e., in our use case, PE1, PE2, and PE3 could have either egress forwarding model without any dependencies.
出口转发模型是出口PE的本地实现，并且独立于其他PE支持的模型；i、 例如，在我们的用例中，PE1、PE2和PE3都可以具有出口转发模型，而没有任何依赖关系。
In addition to the procedures described across Sections 3 through 8, EVPN [RFC7432] procedures allow for optimized traffic handling in order to minimize unnecessary flooding across the entire infrastructure. Optimization is provided through specific ARP termination and the ability to block unknown unicast flooding. Additionally, EVPN procedures allow for intelligent, close to the source, inter-subnet forwarding and solves the commonly known suboptimal routing problem. Besides the traffic efficiency, ingress-based inter-subnet forwarding also optimizes packet forwarding rules and implementation at the egress nodes as well. Details of these procedures are outlined in Sections 9.1 and 9.2.
除了第3节至第8节所述的程序外，EVPN[RFC7432]程序还允许优化流量处理，以最大限度地减少整个基础设施中不必要的洪水。通过特定的ARP终止和阻止未知单播泛洪的能力提供优化。此外，EVPN程序允许智能、接近源的子网间转发，并解决了常见的次优路由问题。除了流量效率，基于入口的子网间转发还优化了分组转发规则和出口节点的实现。第9.1节和第9.2节概述了这些程序的细节。
The fundamental premise of [RFC7432] is the notion of a different approach to MAC address learning compared to traditional IEEE 802.1 bridge learning methods; specifically, EVPN differentiates between data and control-plane-driven learning mechanisms.
[RFC7432]的基本前提是，与传统的IEEE 802.1网桥学习方法相比，MAC地址学习采用不同的方法；具体而言，EVPN区分了数据和控制平面驱动的学习机制。
Data-driven learning implies that there is no separate communication channel used to advertise and propagate MAC addresses. Rather, MAC addresses are learned through IEEE-defined bridge learning procedures as well as by snooping on DHCP and ARP requests. As different MAC addresses show up on different ports, the Layer 2 (L2) FIB is populated with the appropriate MAC addresses.
数据驱动学习意味着没有单独的通信信道用于公布和传播MAC地址。相反，MAC地址是通过IEEE定义的网桥学习过程以及监听DHCP和ARP请求来学习的。由于不同的MAC地址显示在不同的端口上，第2层（L2）FIB将填充相应的MAC地址。
Control-plane-driven learning implies a communication channel that could be either a control-plane protocol or a management-plane mechanism. In the context of EVPN, two different learning procedures are defined: local and remote procedures.
控制平面驱动学习意味着一个通信通道，可以是控制平面协议或管理平面机制。在EVPN的上下文中，定义了两种不同的学习过程：本地过程和远程过程。
o Local learning defines the procedures used for learning the MAC addresses of network elements locally connected to a MAC-VRF. Local learning could be implemented through all three learning procedures: control plane, management plane, and data plane. However, the expectation is that for most of the use cases, local learning through the data plane should be sufficient.
o 本地学习定义了用于学习本地连接到MAC-VRF的网络元件的MAC地址的过程。本地学习可以通过所有三个学习过程来实现：控制平面、管理平面和数据平面。然而，期望对于大多数用例，通过数据平面进行局部学习就足够了。
o Remote learning defines the procedures used for learning MAC addresses of network elements remotely connected to a MAC-VRF, i.e., far-end PEs. Remote learning procedures defined in [RFC7432] advocate using only control-plane learning, BGP specifically. Through the use of BGP EVPN NLRIs, the remote PE has the capability of advertising all the MAC addresses present in its local FIB.
o 远程学习定义了用于学习远程连接到MAC-VRF（即远端PEs）的网络元件MAC地址的过程。[RFC7432]中定义的远程学习程序提倡仅使用控制平面学习，特别是BGP。通过使用BGP EVPN NLRIs，远程PE能够公布其本地FIB中存在的所有MAC地址。
In EVPN, MAC addresses are advertised via the MAC/IP Advertisement route, as discussed in [RFC7432]. Optionally, an IP address can be advertised along with the MAC address advertisement. However, there are certain rules put in place in terms of IP address usage: if the MAC/IP Route contains an IP address, this particular IP address correlates directly with the advertised MAC address. Such advertisement allows us to build a proxy ARP / Neighbor Discovery (ND) table populated with the IP<->MAC bindings received from all the remote nodes.
在EVPN中，MAC地址通过MAC/IP播发路由播发，如[RFC7432]中所述。可选地，IP地址可以与MAC地址广告一起广告。但是，在IP地址使用方面有一些规则：如果MAC/IP路由包含IP地址，则此特定IP地址与公布的MAC地址直接相关。这样的广告允许我们构建一个代理ARP/邻居发现（ND）表，该表由从所有远程节点接收的IP<->MAC绑定填充。
Furthermore, based on these bindings, a local MAC-VRF can now provide proxy ARP/ND functionality for all ARP requests and ND solicitations directed to the IP address pool learned through BGP. Therefore, the amount of unnecessary L2 flooding (ARP/ND requests/solicitations in this case) can be further reduced by the introduction of proxy ARP/ND functionality across all EVI MAC-VRFs.
此外，基于这些绑定，本地MAC-VRF现在可以为所有ARP请求和通过BGP学习到的IP地址池的ND请求提供代理ARP/ND功能。因此，通过在所有EVI MAC VRF中引入代理ARP/ND功能，可以进一步减少不必要的L2洪泛量（在这种情况下为ARP/ND请求/请求）。
Given that all locally learned MAC addresses are advertised through BGP to all remote PEs, suppressing flooding of any unknown unicast traffic towards the remote PEs is a feasible network optimization.
考虑到所有本地学习的MAC地址都通过BGP播发到所有远程PE，抑制任何未知单播流量向远程PE的泛滥是一种可行的网络优化。
The assumption in the use case is made that any network device that appears on a remote MAC-VRF will somehow signal its presence to the network. This signaling can be done through, for example, gratuitous
用例中的假设是，出现在远程MAC-VRF上的任何网络设备都会以某种方式向网络发送其存在的信号。这种信号可以通过，例如，无偿的
ARPs. Once the remote PE acknowledges the presence of the node in the MAC-VRF, it will do two things: install its MAC address in its local FIB and advertise this MAC address to all other BGP speakers via EVPN NLRI. Therefore, we can assume that any active MAC address is propagated and learned through the entire EVI. Given that MAC addresses become prepopulated -- once nodes are alive on the network -- there is no need to flood any unknown unicast towards the remote PEs. If the owner of a given destination MAC is active, the BGP route will be present in the local RIB and FIB, assuming that the BGP import policies are successfully applied; otherwise, the owner of such destination MAC is not present on the network.
ARP。一旦远程PE确认MAC-VRF中存在该节点，它将做两件事：在其本地FIB中安装其MAC地址，并通过EVPN NLRI向所有其他BGP扬声器公布该MAC地址。因此，我们可以假设任何活动MAC地址都是通过整个EVI传播和学习的。一旦网络上的节点处于活动状态，MAC地址就会被预先填充，就不需要向远程PEs发送任何未知的单播。如果给定目的地MAC的所有者处于活动状态，则假定成功应用了BGP导入策略，则BGP路由将出现在本地RIB和FIB中；否则，该目的地MAC的所有者不在网络上。
It is worth noting that unknown unicast flooding must not be suppressed unless (at least) one of the following two statements is given: a) control- or management-plane learning is performed throughout the entire EVI for all the MACs or b) all the EVI-attached devices signal their presence when they come up (Gratuitous ARP (GARP) packets or similar).
值得注意的是，除非（至少）给出以下两种声明中的一种，否则不得抑制未知单播泛洪：a）在整个EVI中对所有mac执行控制或管理平面学习，或b）所有EVI连接的设备在出现时发出信号（免费ARP（GARP）数据包或类似信息）.
In a scenario in which both L2 and L3 services are needed over the same physical topology, some interaction between EVPN and IP-VPN is required. A common way of stitching the two service planes is through the use of an Integrated Routing and Bridging (IRB) interface, which allows for traffic to be either routed or bridged depending on its destination MAC address. If the destination MAC address is the one from the IRB interface, traffic needs to be passed through a routing module and potentially be either routed to a remote PE or forwarded to a local subnet. If the destination MAC address is not the one from the IRB interface, the MAC-VRF follows standard bridging procedures.
在同一物理拓扑上同时需要L2和L3服务的场景中，EVPN和IP-VPN之间需要一些交互。缝合两个服务平面的常用方法是使用集成路由和桥接（IRB）接口，该接口允许根据其目标MAC地址路由或桥接流量。如果目标MAC地址是来自IRB接口的地址，则通信量需要通过路由模块传递，并可能路由到远程PE或转发到本地子网。如果目标MAC地址不是来自IRB接口的地址，MAC-VRF遵循标准桥接程序。
A typical example of EVPN inter-subnet forwarding would be a scenario in which multiple IP subnets are part of a single or multiple EVIs, and they all belong to a single IP-VPN. In such topologies, it is desired that inter-subnet traffic can be efficiently routed without any tromboning effects in the network. Due to the overlapping physical and service topology in such scenarios, all inter-subnet connectivity will be locally routed through the IRB interface.
EVPN子网间转发的一个典型示例是，多个IP子网是单个或多个EVI的一部分，并且它们都属于单个IP-VPN。在这种拓扑中，期望子网间通信能够有效地路由，而不会在网络中产生任何长号效应。由于此类场景中的物理和服务拓扑重叠，所有子网间连接将通过IRB接口在本地路由。
In addition to optimizing the traffic patterns in the network, local inter-subnet forwarding also greatly optimizes the amount of processing needed to cross the subnets. Through EVPN MAC advertisements, the local PE learns the real destination MAC address associated with the remote IP address and the inter-subnet forwarding
除了优化网络中的流量模式外，本地子网间转发还极大地优化了跨子网所需的处理量。通过EVPN MAC播发，本地PE学习与远程IP地址和子网间转发相关联的真实目的地MAC地址
can happen locally. When the packet is received at the egress PE, it is directly mapped to an egress MAC-VRF and bypasses any egress IP-VPN processing.
可能在本地发生。当在出口PE处接收到分组时，分组直接映射到出口MAC-VRF并绕过任何出口IP-VPN处理。
Please refer to [EVPN-INTERSUBNET] for more information about the IP inter-subnet forwarding procedures in EVPN.
有关EVPN中IP子网间转发过程的更多信息，请参阅[EVPN-INTERSUBNET]。
Assuming that the services are set up according to Figure 1 in Section 3, the following flow optimization processes will take place in terms of creating, receiving, and forwarding packets across the network.
假设服务是根据第3节中的图1设置的，则将在网络上创建、接收和转发数据包方面进行以下流优化过程。
Using Figure 1 in Section 3, consider EVI400 residing on PE1, PE2, and PE3 connecting CE2 and CE3 networks. Also, consider that PE1 and PE2 are part of the all-active multihoming ES for CE2, and that PE2 is elected designated forwarder for EVI400. We assume that all the PEs implement the proxy ARP functionality in the MAC-VRF-400 context.
在第3节中使用图1，考虑EVI400驻留在PE1、PE2和PE3连接CE2和CE3网络上。此外，考虑PE1和PE2是CE2的所有有源多归属ES的一部分，并且PE2被选举为EVI400指定的转发器。我们假设所有PEs都在MAC-VRF-400上下文中实现代理ARP功能。
In this scenario, PE3 will not only advertise the MAC addresses through the EVPN MAC Advertisement route but also IP addresses of individual hosts (i.e., /32 prefixes) behind CE3. Upon receiving the EVPN routes, PE1 and PE2 will install the MAC addresses in the MAC-VRF-400 FIB and, based on the associated received IP addresses, PE1 and PE2 can now build a proxy ARP table within the context of MAC-VRF-400.
在这种情况下，PE3不仅会通过EVPN MAC公布路由公布MAC地址，还会公布CE3后面各个主机的IP地址（即/32前缀）。收到EVPN路由后，PE1和PE2将在MAC-VRF-400 FIB中安装MAC地址，并且根据相关接收到的IP地址，PE1和PE2现在可以在MAC-VRF-400的上下文中构建代理ARP表。
From the forwarding perspective, when a node behind CE2 sends a frame destined to a node behind CE3, it will first send an ARP request to, for example, PE2 (based on the result of the CE2 hashing). Assuming that PE2 has populated its proxy ARP table for all active nodes behind the CE3, and that the IP address in the ARP message matches the entry in the table, PE2 will respond to the ARP request with the actual MAC address on behalf of the node behind CE3.
从转发的角度来看，当CE2后面的节点发送一个目的地为CE3后面的节点的帧时，它将首先向例如PE2发送一个ARP请求（基于CE2散列的结果）。假设PE2已经为CE3后面的所有活动节点填充了其代理ARP表，并且ARP消息中的IP地址与表中的条目匹配，PE2将代表CE3后面的节点使用实际MAC地址响应ARP请求。
Once the nodes behind CE2 learn the actual MAC address of the nodes behind CE3, all the MAC-to-MAC communications between the two networks will be unicast.
一旦CE2后面的节点了解到CE3后面的节点的实际MAC地址，两个网络之间的所有MAC到MAC通信都将是单播的。
Using Figure 1 in Section 3, consider EVI500 residing on PE1 and PE3 connecting CE1 and CE3 networks. Consider that both PE1 and PE3 have disabled unknown unicast flooding for this specific EVI context. Once the network devices behind CE3 come online, they will learn
在第3节中使用图1，考虑EVI500驻留在PE1和PE3连接CE1和CE3网络上。考虑到PE1和PE3都为这个特定的EVI上下文禁用了未知的单播洪泛。一旦CE3背后的网络设备上线，他们就会学习
their MAC addresses and create local FIB entries for these devices. Note that local FIB entries could also be created through either a control or management plane between PE and CE as well. Consequently, PE3 will automatically create EVPN Type 2 MAC Advertisement routes and advertise all locally learned MAC addresses. The routes will also include the corresponding MPLS Label.
他们的MAC地址并为这些设备创建本地FIB条目。注意，本地FIB条目也可以通过PE和CE之间的控制或管理平面创建。因此，PE3将自动创建EVPN类型2 MAC播发路由，并播发所有本地学习的MAC地址。路由还将包括相应的MPLS标签。
Given that PE1 automatically learns and installs all MAC addresses behind CE3, its MAC-VRF FIB will already be prepopulated with the respective next-hops and label assignments associated with the MAC addresses behind CE3. As such, as soon as the traffic sent by CE1 to nodes behind CE3 is received into the context of EVI500, PE1 will push the MPLS Label(s) onto the original Ethernet frame and send the packet to the MPLS network. As usual, once PE3 receives this packet, and depending on the forwarding model, PE3 will either do a next-hop lookup in the EVI500 context or just forward the traffic directly to the CE3. In the case that PE1 MAC-VRF-500 does not have a MAC entry for a specific destination that CE1 is trying to reach, PE1 will drop the frame since unknown unicast flooding is disabled.
鉴于PE1自动学习并安装CE3后面的所有MAC地址，其MAC-VRF FIB将已预填充与CE3后面MAC地址相关的下一跳和标签分配。因此，一旦CE1发送到CE3后面的节点的通信量被接收到EVI500的上下文中，PE1将把MPLS标签推到原始以太网帧上，并将数据包发送到MPLS网络。通常，一旦PE3接收到该数据包，并且根据转发模式，PE3将在EVI500上下文中执行下一跳查找，或者直接将流量转发给CE3。在PE1 MAC-VRF-500没有针对CE1试图到达的特定目的地的MAC条目的情况下，PE1将丢弃帧，因为未知单播泛洪被禁用。
Based on the assumption that all the MAC entries behind the CEs are prepopulated through gratuitous ARP and/or DHCP requests, if one specific MAC entry is not present in the MAC-VRF-500 FIB on PE1, the owner of that MAC is not alive on the network behind the CE3; hence, the traffic can be dropped at PE1 instead of flooding and consuming network bandwidth.
基于CEs后面的所有MAC条目都通过免费ARP和/或DHCP请求预填充的假设，如果PE1上的MAC-VRF-500 FIB中不存在一个特定MAC条目，则该MAC的所有者在CE3后面的网络上不存在；因此，可以在PE1处丢弃流量，而不是淹没和消耗网络带宽。
9.2.3. Optimization of Inter-subnet Forwarding Example for CE3-to-CE2 Traffic
9.2.3. CE3-to-CE2流量的子网间转发优化示例
Using Figure 1 in Section 3, consider that there is an IP-VPN 666 context residing on PE1, PE2, and PE3, which connects CE1, CE2, and CE3 into a single IP-VPN domain. Also consider that there are two EVIs present on the PEs, EVI600 and EVI60. Each IP subnet is associated with a different MAC-VRF context. Thus, there is a single subnet (subnet 600) between CE1 and CE3 that is established through EVI600. Similarly, there is another subnet (subnet 60) between CE2 and CE3 that is established through EVI60. Since both subnets are part of the same IP-VPN, there is a mapping of each EVI (or individual subnet) to a local IRB interface on the three PEs.
在第3节中使用图1，考虑存在驻留在PE1、PE2和PE3上的IP-VPN 666上下文，其将CE1、CE2和CE3连接到单个IP-VPN域中。还考虑在PES、EVI600和EVI60上存在两个EVIS。每个IP子网都与不同的MAC-VRF上下文相关联。因此，在CE1和CE3之间存在通过EVI600建立的单个子网（子网600）。类似地，通过EVI60在CE2和CE3之间建立另一个子网（子网60）。由于两个子网都是同一IP-VPN的一部分，因此每个EVI（或单个子网）都映射到三个PE上的本地IRB接口。
If a node behind CE2 wants to communicate with a node on the same subnet seating behind CE3, the communication flow will follow the standard EVPN procedures, i.e., FIB lookup within the PE1 (or PE2) after adding the corresponding EVPN label to the MPLS Label stack (downstream label allocation from PE3 for EVI60).
如果CE2后面的节点希望与位于CE3后面的同一子网上的节点通信，则通信流将遵循标准EVPN过程，即在将相应的EVPN标签添加到MPLS标签堆栈（从PE3为EVI60分配下游标签）后，在PE1（或PE2）内进行FIB查找。
When it comes to crossing the subnet boundaries, the ingress PE implements local inter-subnet forwarding. For example, when a node behind CE2 (EVI60) sends a packet to a node behind CE1 (EVI600), the destination IP address will be in the subnet 600, but the destination MAC address will be the address of the source node's default gateway, which in this case will be an IRB interface on PE1 (connecting EVI60 to IP-VPN 666). Once PE1 sees the traffic destined to its own MAC address, it will route the packet to EVI600, i.e., it will change the source MAC address to the one of the IRB interface in EVI600 and change the destination MAC address to the address belonging to the node behind CE1, which is already populated in the MAC-VRF-600 FIB, either through data- or control-plane learning.
当涉及到跨越子网边界时，入口PE实现本地子网间转发。例如，当CE2（EVI60）后面的节点向CE1（EVI600）后面的节点发送数据包时，目标IP地址将在子网600中，但目标MAC地址将是源节点的默认网关的地址，在这种情况下，该网关将是PE1上的IRB接口（将EVI60连接到IP-VPN 666）。一旦PE1看到目的地为其自身MAC地址的流量，它将把数据包路由到EVI600，即将源MAC地址更改为EVI600中的IRB接口之一，并将目标MAC地址更改为属于CE1后面节点的地址，该地址已填充在MAC-VRF-600 FIB中，通过数据或控制平面学习。
An important optimization to be noted is the local inter-subnet forwarding in lieu of IP-VPN routing. If the node from subnet 60 (behind CE2) is sending a packet to the remote end-node on subnet 600 (behind CE3), the mechanism in place still honors the local inter-subnet (inter-EVI) forwarding.
需要注意的一个重要优化是本地子网间转发，而不是IP-VPN路由。如果来自子网60（在CE2后面）的节点正在向子网600（在CE3后面）上的远程终端节点发送分组，则适当的机制仍然支持本地子网间（inter-EVI）转发。
In our use case, therefore, when the node from subnet 60 behind CE2 sends traffic to the node on subnet 600 behind CE3, the destination MAC address is the PE1 MAC-VRF-60 IRB MAC address. However, once the traffic locally crosses EVIs to EVI600 (via the IRB interface on PE1), the source MAC address is changed to that of the IRB interface and the destination MAC address is changed to the one advertised by PE3 via EVPN and already installed in MAC-VRF-600. The rest of the forwarding through PE1 is using the MAC-VRF-600 forwarding context and label space.
因此，在我们的用例中，当来自CE2后面的子网60的节点向CE3后面的子网600上的节点发送通信量时，目标MAC地址是PE1 MAC-VRF-60 IRB MAC地址。然而，一旦通信量在本地通过EVIs到达EVI600（通过PE1上的IRB接口），源MAC地址将更改为IRB接口的MAC地址，目标MAC地址将更改为PE3通过EVPN公布并已安装在MAC-VRF-600中的MAC地址。通过PE1的其余转发使用MAC-VRF-600转发上下文和标签空间。
Another very relevant optimization is due to the fact that traffic between PEs is forwarded through EVPN rather than through IP-VPN. In the example described above for traffic from EVI60 on CE2 to EVI600 on CE3, there is no need for IP-VPN processing on the egress PE3. Traffic is forwarded either to the EVI600 context in PE3 for further MAC lookup and next-hop processing or directly to the node behind CE3, depending on the egress forwarding model being used.
另一个非常相关的优化是由于PEs之间的流量是通过EVPN而不是通过IP-VPN转发的。在上面描述的从CE2上的EVI60到CE3上的EVI600的流量的示例中，不需要在出口PE3上进行IP-VPN处理。流量被转发到PE3中的EVI600上下文，用于进一步的MAC查找和下一跳处理，或者直接转发到CE3后面的节点，具体取决于所使用的出口转发模型。
Please refer to the "Security Considerations" section in [RFC7432]. The standards produced by the SIDR Working Group address secure route origin authentication (e.g., RFCs 6480 through 6493) and route advertisement security (e.g., RFCs 8205 through 8211). They protect the integrity and authenticity of IP address advertisements and ASN/ IP prefix bindings. This document and [RFC7432] use BGP to convey other info (e.g., MAC addresses); thus, the protections offered by the SIDR WG RFCs are not applicable in this context.
请参阅[RFC7432]中的“安全注意事项”部分。SIDR工作组制定的标准涉及安全路由来源认证（如RFCs 6480至6493）和路由公告安全（如RFCs 8205至8211）。它们保护IP地址播发和ASN/IP前缀绑定的完整性和真实性。本文件和[RFC7432]使用BGP传达其他信息（例如MAC地址）；因此，SIDR工作组RFC提供的保护不适用于这种情况。
This document has no IANA actions.
本文档没有IANA操作。
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.
[RFC7209]Sajassi，A.，Aggarwal，R.，Uttaro，J.，Bitar，N.，Henderickx，W.，和A.Isaac，“以太网VPN（EVPN）的要求”，RFC 7209，DOI 10.17487/RFC7209，2014年5月<https://www.rfc-editor.org/info/rfc7209>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432]Sajassi，A.，Ed.，Aggarwal，R.，Bitar，N.，Isaac，A.，Uttaro，J.，Drake，J.，和W.Henderickx，“基于BGP MPLS的以太网VPN”，RFC 7432，DOI 10.17487/RFC7432，2015年2月<https://www.rfc-editor.org/info/rfc7432>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<https://www.rfc-editor.org/info/rfc4762>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，DOI 10.17487/RFC6074，2011年1月<https://www.rfc-editor.org/info/rfc6074>.
[EVPN-INTERSUBNET] Sajassi, A., Salam, S., Thoria, S., Drake, J., Rabadan, J., and L. Yong, "Integrated Routing and Bridging in EVPN", Work in Progress, draft-ietf-bess-evpn-inter-subnet-forwarding-03, February 2017.
[EVPN-INTERSUBNET]Sajassi，A.，Salam，S.，Thoria，S.，Drake，J.，Rabadan，J.，和L.Yong，“EVPN中的集成路由和桥接”，正在进行的工作，草稿-ietf-bess-EVPN-inter-subnet-forwarding-032017年2月。
Acknowledgments
致谢
The authors want to thank Giles Heron for his detailed review of the document. We also thank Stefan Plug and Eric Wunan for their comments.
作者要感谢Giles Heron对该文件的详细审查。我们也感谢Stefan Plug和Eric Wunan的评论。
Contributors
贡献者
The following people contributed substantially to the content of this document and should be considered coauthors:
以下人员对本文件的内容做出了重大贡献，应被视为合著者：
Florin Balus Keyur Patel Aldrin Isaac Truman Boyes
Florin Balus Keyur Patel Aldrin Isaac Truman Boyes
Authors' Addresses
作者地址
Jorge Rabadan (editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States America
豪尔赫·拉巴丹（编辑）诺基亚777 E.米德尔菲尔德路山景城，加利福尼亚州94043
Email: jorge.rabadan@nokia.com
Email: jorge.rabadan@nokia.com
Senad Palislamovic Nokia
诺基亚塞纳德帕利斯拉莫维奇酒店
Email: senad.palislamovic@nokia.com
Email: senad.palislamovic@nokia.com
Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
Wim Henderickx诺基亚哥白尼50 2018比利时安特卫普
Email: wim.henderickx@nokia.com
Email: wim.henderickx@nokia.com
Ali Sajassi Cisco
阿里·萨贾西·思科
Email: sajassi@cisco.com
Email: sajassi@cisco.com
James Uttaro AT&T
詹姆斯·乌塔罗AT&T
Email: uttaro@att.com
Email: uttaro@att.com