Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 8317 S. Salam
Updates: 7385 Cisco
Category: Standards Track J. Drake
ISSN: 2070-1721 Juniper
J. Uttaro
ATT
S. Boutros
VMware
J. Rabadan
Nokia
January 2018
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 8317 S. Salam
Updates: 7385 Cisco
Category: Standards Track J. Drake
ISSN: 2070-1721 Juniper
J. Uttaro
ATT
S. Boutros
VMware
J. Rabadan
Nokia
January 2018
Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)
以太网VPN（EVPN）和提供商主干桥接EVPN（PBB-EVPN）中的以太网树（E树）支持
Abstract
摘要
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.
MEF论坛（MEF）定义了一种称为以太网树（E-Tree）的根多点以太网服务。RFC 7387“多协议标签交换（MPLS）网络上以太网树（E-Tree）服务框架”中描述了在MPLS网络中支持此服务的解决方案框架。本文档讨论了基于RFC 7432“基于BGP MPLS的以太网VPN（EVPN）”的解决方案如何满足这些功能要求，并对此类解决方案如何比RFC 7796“以太网树（E-Tree）”更有效地实现这些功能进行了一些扩展和描述支持虚拟专用局域网服务（VPLS）”。本文档使用由RFC 7385创建的IANA注册表管理的隧道类型字段（在P-多播服务接口（PMSI）隧道属性中）的最高有效位；因此，它相应地更新了RFC 7385。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc8317.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8317.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Specification of Requirements . . . . . . . . . . . . . . 5
2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
3. E-Tree Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Scenario 1: Leaf or Root Site(s) per PE . . . . . . . . . 6
3.2. Scenario 2: Leaf or Root Site(s) per AC . . . . . . . . . 7
3.3. Scenario 3: Leaf or Root Site(s) per MAC Address . . . . 8
4. Operation for EVPN . . . . . . . . . . . . . . . . . . . . . 9
4.1. Known Unicast Traffic . . . . . . . . . . . . . . . . . . 9
4.2. BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. BUM Traffic Originated from a Single-Homed Site on a
Leaf AC . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. BUM Traffic Originated from a Single-Homed Site on a
Root AC . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. BUM Traffic Originated from a Multihomed Site on a
Leaf AC . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. BUM Traffic Originated from a Multihomed Site on a
Root AC . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. E-Tree Traffic Flows for EVPN . . . . . . . . . . . . . . 12
4.3.1. E-Tree with MAC Learning . . . . . . . . . . . . . . 13
4.3.2. E-Tree without MAC Learning . . . . . . . . . . . . . 14
5. Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . 14
5.1. Known Unicast Traffic . . . . . . . . . . . . . . . . . . 15
5.2. BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. E-Tree without MAC Learning . . . . . . . . . . . . . . . 16
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. E-Tree Extended Community . . . . . . . . . . . . . . . . 16
6.2. PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. Considerations for PMSI Tunnel Types . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Multiple Bridge Tables per E-Tree Service Instance . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Specification of Requirements . . . . . . . . . . . . . . 5
2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
3. E-Tree Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Scenario 1: Leaf or Root Site(s) per PE . . . . . . . . . 6
3.2. Scenario 2: Leaf or Root Site(s) per AC . . . . . . . . . 7
3.3. Scenario 3: Leaf or Root Site(s) per MAC Address . . . . 8
4. Operation for EVPN . . . . . . . . . . . . . . . . . . . . . 9
4.1. Known Unicast Traffic . . . . . . . . . . . . . . . . . . 9
4.2. BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. BUM Traffic Originated from a Single-Homed Site on a
Leaf AC . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. BUM Traffic Originated from a Single-Homed Site on a
Root AC . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. BUM Traffic Originated from a Multihomed Site on a
Leaf AC . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. BUM Traffic Originated from a Multihomed Site on a
Root AC . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. E-Tree Traffic Flows for EVPN . . . . . . . . . . . . . . 12
4.3.1. E-Tree with MAC Learning . . . . . . . . . . . . . . 13
4.3.2. E-Tree without MAC Learning . . . . . . . . . . . . . 14
5. Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . 14
5.1. Known Unicast Traffic . . . . . . . . . . . . . . . . . . 15
5.2. BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. E-Tree without MAC Learning . . . . . . . . . . . . . . . 16
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. E-Tree Extended Community . . . . . . . . . . . . . . . . 16
6.2. PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. Considerations for PMSI Tunnel Types . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Multiple Bridge Tables per E-Tree Service Instance . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree) [MEF6.1]. In an E-Tree service, a customer site that is typically represented by an Attachment Circuit (AC) (e.g., an 802.1Q VLAN tag [IEEE.802.1Q]), is labeled as either a Root or a Leaf site. A customer site may also be represented by a Media Access Control (MAC) address along with a VLAN tag. Root sites can communicate with all other customer sites (both Root and Leaf sites). However, Leaf sites can communicate with Root sites but not with other Leaf sites. In this document, unless explicitly mentioned otherwise, a site is always represented by an AC.
MEF论坛（MEF）定义了一个根多点以太网服务，称为以太网树（E-Tree）[MEF6.1]。在E-Tree服务中，通常由连接电路（AC）表示的客户站点（例如，802.1Q VLAN标签[IEEE.802.1Q]）被标记为根站点或叶站点。客户站点也可以由媒体访问控制（MAC）地址和VLAN标记表示。根站点可以与所有其他客户站点（根站点和叶站点）通信。然而，叶站点可以与根站点通信，但不能与其他叶站点通信。在本文档中，除非另有明确说明，否则站点始终由AC表示。
[RFC7387] describes a solution framework for supporting E-Tree service in MPLS networks. This document identifies the functional components of an overall solution to emulate E-Tree services in MPLS networks and supplements the multipoint-to-multipoint Ethernet LAN (E-LAN) services specified in [RFC7432] and [RFC7623].
[RFC7387]描述了在MPLS网络中支持E-Tree服务的解决方案框架。本文档确定了在MPLS网络中模拟E-Tree服务的整体解决方案的功能组件，并补充了[RFC7432]和[RFC7623]中规定的多点到多点以太网LAN（E-LAN）服务。
[RFC7432] defines EVPN, a solution for multipoint Layer 2 Virtual Private Network (L2VPN) services with advanced multihoming capabilities that uses BGP for distributing customer/client MAC address reachability information over the MPLS/IP network. [RFC7623] combines the functionality of EVPN with [IEEE.802.1ah] Provider Backbone Bridging (PBB) for MAC address scalability.
[RFC7432]定义了EVPN，这是一种用于多点第2层虚拟专用网络（L2VPN）服务的解决方案，具有高级多主功能，使用BGP在MPLS/IP网络上分发客户/客户端MAC地址可达性信息。[RFC7623]将EVPN的功能与[IEEE.802.1ah]提供商主干桥接（PBB）相结合，以实现MAC地址的可扩展性。
This document discusses how the functional requirements for E-Tree service can be met with a solution based on EVPN [RFC7432] and PBB-EVPN [RFC7623] with some extensions to their procedures and BGP attributes. Such a solution based on PBB-EVPN or EVPN can offer a more efficient implementation of these functions than that of [RFC7796], "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This efficiency is achieved by performing filtering of unicast traffic at the ingress Provider Edge (PE) nodes as opposed to egress filtering where the traffic is sent through the network and gets filtered and discarded at the egress PE nodes. The details of this ingress filtering are described in Section 4.1. Since this document specifies a solution based on [RFC7432], the knowledge of that document is a prerequisite. This document makes use of the most significant bit of the Tunnel Type field (in the PMSI Tunnel attribute) governed by the IANA registry created by [RFC7385]; hence, it updates [RFC7385] accordingly. Section 3 discusses E-Tree scenarios, Sections 4 and 5 describe E-Tree solutions for EVPN and PBB-EVPN (respectively), and Section 6 covers BGP encoding for E-Tree solutions.
本文档讨论了如何通过基于EVPN[RFC7432]和PBB-EVPN[RFC7623]的解决方案满足E-Tree服务的功能需求，并对其过程和BGP属性进行了一些扩展。这种基于PBB-EVPN或EVPN的解决方案可以提供比[RFC7796]“虚拟专用LAN服务（VPLS）中的以太网树（E-Tree）支持”更高效的功能实现。该效率是通过在入口提供者边缘（PE）节点处执行单播业务的过滤来实现的，而不是出口过滤，在出口过滤中，业务通过网络发送并在出口PE节点处被过滤和丢弃。第4.1节描述了该入口过滤的详细信息。由于本文档指定了基于[RFC7432]的解决方案，因此了解该文档是一个先决条件。本文档使用由[RFC7385]创建的IANA注册表管理的隧道类型字段（在PMSI隧道属性中）的最高有效位；因此，它相应地更新了[RFC7385]。第3节讨论了E-Tree场景，第4节和第5节分别描述了EVPN和PBB-EVPN的E-Tree解决方案，第6节介绍了E-Tree解决方案的BGP编码。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Broadcast Domain: In a bridged network, the broadcast domain corresponds to a Virtual LAN (VLAN), where a VLAN is typically represented by a single VLAN ID (VID) but can be represented by several VIDs where Shared VLAN Learning (SVL) is used per [IEEE.802.1ah].
广播域：在桥接网络中，广播域对应于虚拟LAN（VLAN），其中VLAN通常由单个VLAN ID（VID）表示，但可以由多个VID表示，其中根据[IEEE.802.1ah]使用共享VLAN学习（SVL）。
Bridge Table: An instantiation of a broadcast domain on a MAC-VRF.
桥接表：MAC-VRF上广播域的实例。
CE: A Customer Edge device, e.g., a host, router, or switch.
CE：客户边缘设备，例如主机、路由器或交换机。
EVI: An EVPN Instance spanning the Provider Edge (PE) devices participating in that EVPN.
EVI：跨越参与该EVPN的提供者边缘（PE）设备的EVPN实例。
MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE.
MAC-VRF：PE上媒体访问控制（MAC）地址的虚拟路由和转发表。
ES: When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an "Ethernet Segment".
ES：当客户站点（设备或网络）通过一组以太网链路连接到一个或多个PEs时，该组链路称为“以太网段”。
ESI: An Ethernet Segment Identifier is a unique non-zero identifier that identifies an ES.
ESI：以太网段标识符是标识ES的唯一非零标识符。
Ethernet Tag: An Ethernet Tag identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains.
以太网标签：以太网标签标识特定的广播域，例如VLAN。EVPN实例由一个或多个广播域组成。
P2MP: Point-to-Multipoint.
P2MP：点对多点。
PE: Provider Edge device.
PE：提供程序边缘设备。
This document categorizes E-Tree scenarios into the following three categories, depending on the nature of the Root/Leaf site association:
本文档根据根/叶站点关联的性质，将电子树场景分为以下三类：
Scenario 1: either Leaf or Root site(s) per PE;
Scenario 1: either Leaf or Root site(s) per PE;
Scenario 2: either Leaf or Root site(s) per Attachment Circuit (AC); or,
场景2：每个连接电路（AC）的叶或根位置；或
Scenario 3: either Leaf or Root site(s) per MAC address.
场景3：每个MAC地址的叶或根站点。
In this scenario, a PE may receive traffic from either Root ACs or Leaf ACs for a given MAC-VRF/bridge table, but not both. In other words, a given EVPN Instance (EVI) on a Provider Edge (PE) device is either associated with Root(s) or Leaf(s). The PE may have both Root and Leaf ACs, albeit for different EVIs.
在这种情况下，PE可以从给定MAC-VRF/网桥表的根ACs或叶ACs接收流量，但不能同时从两者接收流量。换句话说，提供者边缘（PE）设备上的给定EVPN实例（EVI）与根或叶相关联。PE可能有根和叶ACs，尽管不同的EVI。
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+---AC1----+--+ | | | MPLS | | | +--+----AC2-----+CE2|
+---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+
| |VRF| | | | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+----AC3-----+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+
+---------+ +---------+
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+---AC1----+--+ | | | MPLS | | | +--+----AC2-----+CE2|
+---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+
| |VRF| | | | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+----AC3-----+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+
+---------+ +---------+
Figure 1: Scenario 1
图1：场景1
In this scenario, tailored BGP Route Target (RT) import/export policies among the PEs belonging to the same EVI can be used to prevent communication among Leaf PEs. To prevent communication among Leaf ACs connected to the same PE and belonging to the same EVI, split-horizon filtering is used to block traffic from one Leaf AC to another Leaf AC on a MAC-VRF for a given E-Tree EVI. The purpose of this topology constraint is to avoid having PEs with only Leaf sites importing and processing BGP MAC routes from each other. To support such a topology constraint in EVPN, two BGP RTs are used for every EVI: one RT is associated with the Root sites (Root ACs) and the other is associated with the Leaf sites (Leaf ACs). On a per-EVI basis, every PE exports the single RT associated with its type of site(s). Furthermore, a PE with a Root site(s) imports both Root and Leaf RTs, whereas a PE with a Leaf site(s) only imports the Root RT.
在此场景中，可以使用属于同一EVI的PEs之间的定制BGP路由目标（RT）导入/导出策略来防止叶PEs之间的通信。为了防止连接到同一PE且属于同一EVI的叶AC之间的通信，对于给定的E-树EVI，使用分割地平线滤波来阻断MAC-VRF上从一个叶AC到另一个叶AC的通信。此拓扑约束的目的是避免PEs只有叶站点相互导入和处理BGP MAC路由。为了支持EVPN中的这种拓扑约束，每个EVI使用两个BGP RT：一个RT与根站点（根ACs）关联，另一个与叶站点（叶ACs）关联。在每个EVI的基础上，每个PE导出与其站点类型关联的单个RT。此外，具有根站点的PE同时导入根和叶RT，而具有叶站点的PE仅导入根RT。
For this scenario, if it is desired to use only a single RT per EVI (just like E-LAN services in [RFC7432]), then approach B in Scenario 2 (described below) needs to be used.
对于该场景，如果希望每个EVI仅使用一个RT（就像[RFC7432]中的E-LAN服务一样），则需要使用场景2中的方法B（如下所述）。
In this scenario, a PE can receive traffic from both Root ACs and Leaf ACs for a given EVI. In other words, a given EVI on a PE can be associated with both Root(s) and Leaf(s).
在这种情况下，PE可以从给定EVI的根ACs和叶ACs接收流量。换句话说，PE上的给定EVI可以与根和叶关联。
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----AC1----+--+ | | | | | | +--+---AC2--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+
| |VRF| | | /IP | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+---AC3--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----AC1----+--+ | | | | | | +--+---AC2--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+
| |VRF| | | /IP | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+---AC3--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+
Figure 2: Scenario 2
图2：场景2
In this scenario, (as in Scenario 1 Section 3.1), two RTs (one for Root and another for Leaf) can be used. However, the difference is that on a PE with both Root and Leaf ACs, all remote MAC routes are imported; thus, in order to apply the proper ingress filtering, there needs to be a way to differentiate remote MAC routes associated with Leaf ACs versus the ones associated with Root ACs.
在这个场景中（如场景1第3.1节），可以使用两个RTs（一个用于根，另一个用于叶）。然而，不同之处在于，在同时具有根ACs和叶ACs的PE上，所有远程MAC路由都被导入；因此，为了应用适当的入口过滤，需要有一种方法来区分与叶ACs相关联的远程MAC路由和与根ACs相关联的远程MAC路由。
In order to recognize the association of a destination MAC address to a Leaf or Root AC and, thus, support ingress filtering on the ingress PE with both Leaf and Root ACs, MAC addresses need to be colored with a Root or Leaf-Indication before advertising to other PEs. There are two approaches for such coloring:
为了识别目的地MAC地址与叶或根AC的关联，从而支持在具有叶和根ACs的入口PE上进行入口过滤，MAC地址需要在向其他PE发布广告之前用根或叶指示着色。这种着色有两种方法：
(A) to always use two RTs (one to designate Leaf RT and another for Root RT), or
（A） 始终使用两个RT（一个指定叶RT，另一个指定根RT），或
(B) to allow for a single RT to be used per EVI, just like [RFC7432], and, thus, color MAC addresses via a "color" flag in a new extended community as detailed in Section 6.1.
（B） 允许每个EVI使用单个RT，就像[RFC7432]，因此，在新的扩展社区中，通过“颜色”标志对MAC地址进行着色，详见第6.1节。
Approach A would require the same data-plane enhancements as approach B if MAC-VRF and bridge tables used per VLAN are to remain consistent with Section 6 of [RFC7432]. In order to avoid data-plane enhancements for approach A, multiple bridge tables per VLAN may be considered; however, this has major drawbacks (as described in Appendix A); thus, it is not recommended.
如果每个VLAN使用的MAC-VRF和桥接表与[RFC7432]第6节保持一致，则方法A将需要与方法B相同的数据平面增强。为了避免方法A的数据平面增强，每个VLAN可以考虑多个桥接表；然而，这有很大的缺点（如附录A所述）；因此，不建议这样做。
Given that both approaches A and B would require the same data-plane enhancements, approach B is chosen here in order to allow for RT usage consistent with baseline EVPN [RFC7432] and for better generality. It should be noted that if one wants to use RT constraints in order to avoid MAC advertisements associated with a Leaf AC to PEs with only Leaf ACs, then two RTs (one for Root and another for Leaf) can still be used with approach B; however, in such applications, Leaf/Root RTs will be used to constrain MAC advertisements and are not used to color the MAC routes for ingress filtering (i.e., in approach B, the coloring is always done via the new extended community).
考虑到方法A和B都需要相同的数据平面增强，这里选择方法B是为了允许RT使用与基线EVPN[RFC7432]一致，并具有更好的通用性。应该注意的是，如果想要使用RT约束以避免与仅具有叶AC的叶AC相关联的MAC广告到PEs，那么两个RT（一个用于根，另一个用于叶）仍然可以与方法B一起使用；然而，在此类应用中，叶/根RTs将用于约束MAC广告，而不用于为入口过滤对MAC路由进行着色（即，在方法B中，着色始终通过新的扩展社区进行）。
If, for a given EVI, a significant number of PEs have both Leaf and Root sites attached (even though they may start as Root-only or Leaf-only PEs), then a single RT per EVI should be used. The reason for such a recommendation is to alleviate the configuration overhead associated with using two RTs per EVI at the expense of having some unwanted MAC addresses on the Leaf-only PEs.
如果对于给定的EVI，相当数量的PE同时具有叶和根位点（即使它们可能以仅根或仅叶的PEs开始），则应使用每个EVI的单个RT。这样一个建议的原因是为了减轻与每个EVI使用两个rt相关的配置开销，而代价是在纯叶PEs上有一些不需要的MAC地址。
In this scenario, a customer Root or Leaf site is represented by a MAC address on an AC and a PE may receive traffic from both Root and Leaf sites on that AC for an EVI. This scenario is not covered in either [RFC7387] or [MEF6.1]; however, it is covered in this document for the sake of completeness. In this scenario, since an AC carries traffic from both Root and Leaf sites, the granularity at which Root or Leaf sites are identified is on a per-MAC-address basis. This scenario is considered in this document for EVPN service with only known unicast traffic because the Designated Forwarder (DF) filtering per [RFC7432] would not be compatible with the required egress filtering; that is, Broadcast, Unknown Unicast, and Multicast (BUM) traffic is not supported in this scenario; it is dropped by the ingress PE.
在该场景中，客户根或叶站点由AC上的MAC地址表示，并且PE可以从该AC上的根和叶站点接收EVI的流量。[RFC7387]或[MEF6.1]中均未涵盖此场景；但是，为了完整起见，本文件将对其进行介绍。在这种情况下，由于AC同时承载来自根站点和叶站点的流量，因此根站点或叶站点的识别粒度是基于每个MAC地址的。本文档中考虑了仅具有已知单播流量的EVPN服务的这种情况，因为根据[RFC7432]进行的指定转发器（DF）过滤将与所需的出口过滤不兼容；也就是说，在该场景中不支持广播、未知单播和多播（BUM）流量；它被入口PE丢弃。
For this scenario, the approach B in Scenario 2 is used in order to allow for single RT usage by service providers.
对于该场景，使用场景2中的方法B以允许服务提供商使用单个RT。
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----AC1----+--+ | | | | | | +--+-----AC2----+CE2|
+---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+
| | V | | | /IP | | | V | |
| | I | | | | | | I | | +---+
| | | | | | | | +--+-----AC3----+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+
+---------+ +---------+
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----AC1----+--+ | | | | | | +--+-----AC2----+CE2|
+---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+
| | V | | | /IP | | | V | |
| | I | | | | | | I | | +---+
| | | | | | | | +--+-----AC3----+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+
+---------+ +---------+
Figure 3: Scenario 3
图3：场景3
In conclusion, the approach B in scenario 2 is the recommended approach across all the above three scenarios, and the corresponding solution is detailed in the following sections.
综上所述，场景2中的方法B是上述三种场景中的推荐方法，相应的解决方案将在以下章节中详细介绍。
[RFC7432] defines the notion of the Ethernet Segment Identifier (ESI) MPLS label used for split-horizon filtering of BUM traffic at the egress PE. Such egress filtering capabilities can be leveraged in provision of E-Tree services, as it will be seen shortly for BUM traffic. For known unicast traffic, additional extensions to [RFC7432] are needed (i.e., a new BGP extended community for Leaf-Indication described in Section 6.1) in order to enable ingress filtering as described in detail in the following sections.
[RFC7432]定义了以太网段标识符（ESI）MPLS标签的概念，该标签用于对出口PE处的BUM流量进行分层过滤。这种出口过滤功能可以在提供E-Tree服务时加以利用，这一点很快就会在BUM流量中看到。对于已知的单播通信量，需要对[RFC7432]进行额外的扩展（即，第6.1节中描述的用于叶指示的新BGP扩展社区），以便启用入口过滤，如下节中详细描述。
In EVPN, MAC learning is performed in the control plane via advertisement of BGP routes. Because of this, the filtering needed by an E-Tree service for known unicast traffic can be performed at the ingress PE, thus providing very efficient filtering and avoiding sending known unicast traffic over the MPLS/IP core to be filtered at the egress PE, as is done in traditional E-Tree solutions (i.e., E-Tree for VPLS [RFC7796]).
在EVPN中，MAC学习通过BGP路由的广告在控制平面中执行。因此，E-Tree服务对已知单播业务所需的过滤可以在入口PE处执行，从而提供非常有效的过滤并避免通过MPLS/IP核心发送已知单播业务以在出口PE处过滤，这与传统E-Tree解决方案（即，vpl的E-Tree[RFC7796]）中所做的一样。
To provide such ingress filtering for known unicast traffic, a PE MUST indicate to other PEs what kind of sites (Root or Leaf) its MAC addresses are associated with. This is done by advertising a Leaf-Indication flag (via an extended community) along with each of its MAC/IP Advertisement routes learned from a Leaf site. The lack of such a flag indicates that the MAC address is associated with a Root site. This scheme applies to all scenarios described in Section 3.
为了为已知的单播流量提供这样的入口过滤，PE必须向其他PE指示其MAC地址与哪种类型的站点（根或叶）相关联。这是通过（通过扩展社区）宣传叶子指示标志以及从叶子站点学习到的每个MAC/IP广告路由来实现的。缺少这样的标志表示MAC地址与根站点相关联。该方案适用于第3节中描述的所有场景。
Tagging MAC addresses with a Leaf-Indication enables remote PEs to perform ingress filtering for known unicast traffic; that is, on the ingress PE, the MAC destination address lookup yields (in addition to the forwarding adjacency) a flag that indicates whether or not the target MAC is associated with a Leaf site. The ingress PE cross-checks this flag with the status of the originating AC, and if both are Leafs, then the packet is not forwarded.
用叶子指示标记MAC地址使远程PEs能够对已知单播流量执行入口过滤；也就是说，在入口PE上，MAC目的地地址查找产生（除了转发邻接之外）指示目标MAC是否与叶站点相关联的标志。入口PE将此标志与发起AC的状态交叉检查，如果两者都是LEAF，则不转发数据包。
In a situation where MAC moves are allowed among Leaf and Root sites (e.g., non-static MAC), PEs can receive multiple MAC/IP Advertisement routes for the same MAC address with different Root or Leaf-Indications (and possibly different ESIs for multihoming scenarios). In such situations, MAC mobility procedures (see Section 15 of [RFC7432]) take precedence to first identify the location of the MAC before associating that MAC with a Root or a Leaf site.
在允许MAC在叶和根站点之间移动的情况下（例如，非静态MAC），PEs可以接收具有不同根或叶指示的同一MAC地址的多个MAC/IP广告路由（对于多归属场景，可能不同的ESI）。在这种情况下，MAC移动性程序（参见[RFC7432]第15节）优先于在将MAC与根或叶站点关联之前首先识别MAC的位置。
To support the above ingress filtering functionality, a new E-Tree extended community with a Leaf-Indication flag is introduced (see Section 6.1). This new extended community MUST be advertised with MAC/IP Advertisement routes learned from a Leaf site. Besides MAC/IP Advertisement routes, no other EVPN routes are required to carry this new extended community for the purpose of known unicast traffic.
为了支持上述入口过滤功能，引入了一个新的带有叶子指示标志的E-Tree扩展社区（见第6.1节）。这个新的扩展社区必须通过从叶子站点学习的MAC/IP广告路由进行广告。除了MAC/IP广告路由之外，不需要其他EVPN路由来承载这个新的扩展社区，以实现已知的单播流量。
This specification does not provide support for filtering Broadcast, Unknown Unicast, and Multicast (BUM) traffic on the ingress PE; due to the multidestination nature of BUM traffic, it is not possible to perform filtering of the same on the ingress PE. As such, the solution relies on egress filtering. In order to apply the proper egress filtering, which varies based on whether a packet is sent from a Leaf AC or a Root AC, the MPLS-encapsulated frames MUST be tagged with an indication of when they originated from a Leaf AC (i.e., to be tagged with a Leaf label as specified in Section 6.1). This Leaf label allows for disposition PE (e.g., egress PE) to perform the necessary egress filtering function in a data plane similar to the ESI label in [RFC7432]. The allocation of the Leaf label is on a per-PE basis (e.g., independent of ESI and EVI) as described in the following sections.
本规范不支持过滤入口PE上的广播、未知单播和多播（BUM）流量；由于BUM流量的多目的地性质，不可能在入口PE上执行相同的过滤。因此，解决方案依赖于出口过滤。为了应用适当的出口过滤（其根据分组是从叶AC还是根AC发送而变化），MPLS封装的帧必须标记有它们何时起源于叶AC的指示（即，使用第6.1节中规定的叶标签进行标记）。该叶标签允许配置PE（例如出口PE）在类似于[RFC7432]中ESI标签的数据平面中执行必要的出口过滤功能。叶标签的分配基于每个PE（例如，独立于ESI和EVI），如以下章节所述。
The Leaf label can be upstream assigned for Point-to-Multipoint (P2MP) Label Switched Path (LSP) or downstream assigned for Ingress Replication tunnels. The main difference between a downstream- and upstream-assigned Leaf label is that, in the case of downstream-assigned Leaf labels, not all egress PE devices need to receive the label in MPLS-encapsulated BUM packets, just like the ESI label for Ingress Replication procedures defined in [RFC7432].
叶标签可以为点对多点（P2MP）标签交换路径（LSP）上游分配，也可以为入口复制隧道下游分配。下游和上游分配的叶标签之间的主要区别在于，在下游分配的叶标签的情况下，并非所有出口PE设备都需要在MPLS封装的BUM数据包中接收标签，就像[RFC7432]中定义的入口复制过程的ESI标签一样。
On the ingress PE, the PE needs to place all its Leaf ACs for a given bridge domain in a single split-horizon group in order to prevent intra-PE forwarding among its Leaf ACs. This intra-PE split-horizon filtering applies to BUM traffic as well as known unicast traffic.
在入口PE上，PE需要将其给定网桥域的所有叶ACs放置在单个分割地平线组中，以防止其叶ACs之间的PE内转发。此PE内分割地平线过滤适用于BUM流量以及已知的单播流量。
There are four scenarios to consider as follows. In all these scenarios, the ingress PE imposes the right MPLS label associated with the originated Ethernet Segment (ES) depending on whether the Ethernet frame originated from a Root or a Leaf site on that Ethernet Segment (ESI label or Leaf label). The mechanism by which the PE identifies whether a given frame originated from a Root or a Leaf site on the segment is based on the AC identifier for that segment (e.g., Ethernet Tag of the frame for 802.1Q frames [IEEE.802.1Q]). Other mechanisms for identifying Root or Leaf sites, such as the use of the source MAC address of the receiving frame, are optional. The scenarios below are described in context of a Root/Leaf AC, however, they can be extended to the Root/Leaf MAC address if needed.
有四种情况需要考虑如下。在所有这些场景中，入口PE根据以太网帧是源自该以太网段上的根站点还是叶站点（ESI标签或叶标签），施加与起源以太网段相关联的正确MPLS标签。PE根据该段的AC标识符（例如，802.1Q帧的以太网标签[IEEE.802.1Q]）来识别给定帧源于该段上的根站点还是叶站点的机制。用于识别根或叶站点的其他机制（例如使用接收帧的源MAC地址）是可选的。下面的场景在根/叶AC的上下文中描述，但是，如果需要，它们可以扩展到根/叶MAC地址。
In this scenario, the ingress PE adds a Leaf label advertised using the E-Tree extended community (see Section 6.1), which indicates a Leaf site. This Leaf label, used for single-homing scenarios, is not on a per-ES basis but rather on a per PE basis (i.e., a single Leaf MPLS label is used for all single-homed ESs on that PE). This Leaf label is advertised to other PE devices using the E-Tree extended community (see Section 6.1) along with an Ethernet Auto-Discovery per ES (EAD-ES) route with an ESI of zero and a set of RTs corresponding to all EVIs on the PE where each EVI has at least one Leaf site. Multiple EAD-ES routes will need to be advertised if the number of RTs that need to be carried exceed the limit on a single route per [RFC7432]. The ESI for the EAD-ES route is set to zero to indicate single-homed sites.
在这种情况下，ingress PE添加了一个使用E-Tree扩展社区（参见第6.1节）发布的叶标签，该标签指示叶站点。此叶标签用于单重定位场景，不是基于每个ES，而是基于每个PE（即，单个叶MPLS标签用于该PE上的所有单重定位ESs）。使用E-Tree扩展社区（参见第6.1节）以及ESI为零的以太网每ES自动发现（EAD-ES）路由和一组对应于PE上所有EVI的RTs（其中每个EVI至少有一个叶站点）向其他PE设备发布该叶标签。如果需要携带的RTs数量超过[RFC7432]中单个路由的限制，则需要公布多个EAD-ES路由。EAD-ES路由的ESI设置为零，以指示单宿站点。
When a PE receives this special Leaf label in the data path, it blocks the packet if the destination AC is of type Leaf; otherwise, it forwards the packet.
当PE在数据路径中接收到该特殊叶标签时，如果目的地AC是叶类型的，则其阻止分组；否则，它将转发数据包。
In this scenario, the ingress PE does not add any ESI or Leaf labels and it operates per the procedures in [RFC7432].
在这种情况下，ingress PE不添加任何ESI或叶标签，并按照[RFC7432]中的程序进行操作。
In this scenario, it is assumed that while different ACs (VLANs) on the same ES could have a different Root/Leaf designation (some being Roots and some being Leafs), the same VLAN does have the same Root/ Leaf designation on all PEs on the same ES. Furthermore, it is assumed that there is no forwarding among subnets (i.e., the service is EVPN L2 and not EVPN Integrated Routing and Bridging (IRB) [EVPN-INTEGRATED]). IRB use cases described in [EVPN-INTEGRATED] are outside the scope of this document.
在该场景中，假设相同ES上的不同ACs（VLAN）可能具有不同的根/叶指定（一些是根，一些是叶），但相同VLAN在相同ES上的所有PE上具有相同的根/叶指定。此外，假设子网之间没有转发（即，服务是EVPN L2，而不是EVPN集成路由和桥接（IRB）[EVPN-Integrated]）。[EVPN-INTEGRATED]中描述的IRB用例不在本文档的范围内。
In this scenario, if a multicast or broadcast packet is originated from a Leaf AC, then it only needs to carry a Leaf label as described in Section 4.2.1. This label is sufficient in providing the necessary egress filtering of BUM traffic from getting sent to Leaf ACs, including the Leaf AC on the same ES.
在这种情况下，如果一个多播或广播数据包来自一个叶子AC，那么它只需要携带一个叶子标签，如第4.2.1节所述。该标签足以提供必要的出口过滤，以防止BUM流量被发送到叶ACs，包括相同ES上的叶AC。
In this scenario, both the ingress and egress PE devices follow the procedure defined in [RFC7432] for adding and/or processing an ESI MPLS label; that is, existing procedures for BUM traffic in [RFC7432] are sufficient and there is no need to add a Leaf label.
在此场景中，入口和出口PE设备都遵循[RFC7432]中定义的用于添加和/或处理ESI MPLS标签的过程；也就是说，[RFC7432]中的BUM通信的现有程序已经足够，不需要添加叶标签。
Per [RFC7387], a generic E-Tree service supports all of the following traffic flows:
根据[RFC7387]，通用E-Tree服务支持以下所有流量：
- known unicast traffic from Root to Roots & Leafs
- 从根到根和叶的已知单播流量
- known unicast traffic from Leaf to Roots
- 从叶到根的已知单播流量
- BUM traffic from Root to Roots & Leafs
- 从根到根和叶的BUM流量
- BUM traffic from Leaf to Roots
- 从叶子到根的垃圾交通
A particular E-Tree service may need to support all of the above types of flows or only a select subset, depending on the target application. In the case where only multicast and broadcast flows need to be supported, the L2VPN PEs can avoid performing any MAC learning function.
特定的E-Tree服务可能需要支持上述所有类型的流，或者仅支持选定的子集，具体取决于目标应用程序。在只需要支持多播和广播流的情况下，L2VPN PEs可以避免执行任何MAC学习功能。
The following subsections will describe the operation of EVPN to support E-Tree service with and without MAC learning.
以下小节将描述EVPN的操作，以支持有MAC学习和无MAC学习的E-Tree服务。
The PEs implementing an E-Tree service must perform MAC learning when unicast traffic flows must be supported among Root and Leaf sites. In this case, the PE(s) with Root sites performs MAC learning in the data path over the ESs and advertises reachability in EVPN MAC/IP Advertisement routes. These routes will be imported by all PEs for that EVI (i.e., PEs that have Leaf sites as well as PEs that have Root sites). Similarly, the PEs with Leaf sites perform MAC learning in the data path over their ESs and advertise reachability in EVPN MAC/IP Advertisement routes. For scenarios where two different RTs are used per EVI (one to designate a Root site and another to designate a Leaf site), the MAC/IP Advertisement routes are imported only by PEs with at least one Root site in the EVI (i.e., a PE with only Leaf sites will not import these routes). PEs with Root and/or Leaf sites may use the Ethernet Auto-Discovery per EVI (EAD-EVI) routes for aliasing (in the case of multihomed segments) and EAD-ES routes for mass MAC withdrawal per [RFC7432].
当根站点和叶站点之间必须支持单播流量时，实现E-Tree服务的PEs必须执行MAC学习。在这种情况下，具有根站点的PE在ESs上的数据路径中执行MAC学习，并在EVPN MAC/IP播发路由中播发可达性。这些路线将由该EVI的所有PE导入（即，具有叶位点的PE以及具有根位点的PE）。类似地，具有叶站点的PEs在其ESs上的数据路径中执行MAC学习，并在EVPN MAC/IP播发路由中播发可达性。对于每个EVI使用两个不同RTs（一个用于指定根站点，另一个用于指定叶站点）的场景，MAC/IP广告路由仅由EVI中至少有一个根站点的PE导入（即，只有叶站点的PE不会导入这些路由）。根站点和/或叶站点的PEs可根据[RFC7432]使用以太网自动发现每EVI（EAD-EVI）路由进行别名（在多址段的情况下）和EAD-ES路由进行大规模MAC提取。
To support multicast/broadcast from Root to Leaf sites, either a P2MP tree rooted at the PE(s) with the Root site(s) (e.g., Root PEs) or Ingress Replication can be used (see Section 16 of [RFC7432]). The multicast tunnels are set up through the exchange of the EVPN Inclusive Multicast route, as defined in [RFC7432].
为了支持从根站点到叶站点的多播/广播，可以使用根站点（例如，根站点）在PE上扎根的P2MP树或入口复制（参见[RFC7432]第16节）。按照[RFC7432]中的定义，通过交换EVPN包含的多播路由来建立多播隧道。
To support multicast/broadcast from Leaf to Root sites, either Ingress Replication tunnels from each Leaf PE or a P2MP tree rooted at each Leaf PE can be used. The following two paragraphs describe when each of these tunneling schemes can be used and how to signal them.
为了支持从叶到根站点的多播/广播，可以使用来自每个叶PE的入口复制隧道或根在每个叶PE的P2MP树。以下两段描述了何时可以使用这些隧道方案以及如何向它们发送信号。
When there are only a few Root PEs with small amount of multicast/ broadcast traffic from Leaf PEs toward Root PEs, then Ingress Replication tunnels from Leaf PEs toward Root PEs should be sufficient. Therefore, if a Root PE needs to support a P2MP tunnel in the transmit direction from itself to Leaf PEs, and, at the same time, it wants to support Ingress Replication tunnels in the receive direction, the Root PE can signal it efficiently by using a new composite tunnel type defined in Section 6.2. This new composite tunnel type is advertised by the Root PE to simultaneously indicate a P2MP tunnel in the transmit direction and an Ingress Replication tunnel in the receive direction for the BUM traffic.
当只有少数根PE具有从叶PE到根PE的少量多播/广播流量时，从叶PE到根PE的入口复制隧道应该足够了。因此，如果根PE需要在从其自身到叶PE的传输方向上支持P2MP隧道，同时希望在接收方向上支持入口复制隧道，则根PE可以通过使用第6.2节中定义的新复合隧道类型有效地向其发送信号。此新的复合隧道类型由根PE播发，以同时指示BUM流量的发送方向上的P2MP隧道和接收方向上的入口复制隧道。
If the number of Root PEs is large, P2MP tunnels (e.g., Multipoint LDP (mLDP) or RSVP-TE) originated at the Leaf PEs may be used; thus, there will be no need to use the modified PMSI Tunnel attribute and the composite tunnel type values defined in Section 6.2.
如果根PEs的数量较大，则可以使用起源于叶PEs的P2MP隧道（例如，多点LDP（mLDP）或RSVP-TE）；因此，无需使用修改后的PMSI隧道属性和第6.2节中定义的复合隧道类型值。
The PEs implementing an E-Tree service need not perform MAC learning when the traffic flows between Root and Leaf sites are mainly multicast or broadcast. In this case, the PEs do not exchange EVPN MAC/IP Advertisement routes. Instead, the Inclusive Multicast Ethernet Tag route is used to support BUM traffic. In such scenarios, the small amount of unicast traffic (if any) is sent as part of BUM traffic.
当根站点和叶站点之间的流量主要是多播或广播时，实现E-Tree服务的PEs不需要执行MAC学习。在这种情况下，PEs不交换EVPN MAC/IP播发路由。相反，包容性多播以太网标记路由用于支持BUM流量。在这种情况下，少量单播通信量（如果有）作为BUM通信量的一部分发送。
The fields of this route are populated per the procedures defined in [RFC7432], and the multicast tunnel setup criteria are as described in the previous section.
此路由的字段按照[RFC7432]中定义的程序填充，多播隧道设置标准如前一节所述。
Just as in the previous section, if the number of Root PEs are only a few and, thus, Ingress Replication is desired from Leaf PEs to these Root PEs, then the modified PMSI attribute and the composite tunnel type values defined in Section 6.2 should be used.
与前一节一样，如果根PE的数量很少，因此需要从叶PE到这些根PE的入口复制，则应使用修改后的PMSI属性和第6.2节中定义的复合隧道类型值。
In PBB-EVPN, the PE advertises a Root or Leaf-Indication along with each Backbone MAC (B-MAC) Advertisement route to indicate whether the associated B-MAC address corresponds to a Root or a Leaf site. Just like the EVPN case, the new E-Tree extended community defined in Section 6.1 is advertised with each EVPN MAC/IP Advertisement route.
在PBB-EVPN中，PE连同每个主干MAC（B-MAC）广告路由广告根或叶指示，以指示相关联的B-MAC地址是否对应于根或叶站点。与EVPN的情况一样，第6.1节中定义的新E树扩展社区通过每个EVPN MAC/IP广告路由进行广告。
In the case where a multihomed ES has both Root and Leaf sites attached, two B-MAC addresses are advertised: one B-MAC address is per ES (as specified in [RFC7623]) and implicitly denotes Root, and the other B-MAC address is per PE and explicitly denotes Leaf. The former B-MAC address is not advertised with the E-Tree extended community, but the latter B-MAC denoting Leaf is advertised with the new E-Tree extended community where a "Leaf-indication" flag is set. In multihoming scenarios where an ES has both Root and Leaf ACs, it is assumed that while different ACs (VLANs) on the same ES could have a different Root/Leaf designation (some being Roots and some being Leafs), the same VLAN does have the same Root/Leaf designation on all PEs on the same ES. Furthermore, it is assumed that there is no forwarding among subnets (i.e., the service is L2 and not IRB). An IRB use case is outside the scope of this document.
在多宿ES同时连接根站点和叶站点的情况下，会公布两个B-MAC地址：一个B-MAC地址为每个ES（如[RFC7623]中所述），隐式表示根，另一个B-MAC地址为每个PE，显式表示叶。前一个B-MAC地址不通过E-Tree扩展社区进行广告，但表示叶的后一个B-MAC通过新的E-Tree扩展社区进行广告，其中设置了“叶指示”标志。在ES同时具有根和叶ACs的多主场景中，假设同一ES上的不同ACs（VLAN）可能具有不同的根/叶指定（一些是根，一些是叶），但同一VLAN在同一ES上的所有PE上具有相同的根/叶指定。此外，假设子网之间没有转发（即，服务是L2而不是IRB）。IRB用例不在本文档的范围内。
The ingress PE uses the right B-MAC source address depending on whether the Ethernet frame originated from the Root or Leaf AC on that ES. The mechanism by which the PE identifies whether a given frame originated from a Root or Leaf site on the segment is based on
入口PE使用正确的B-MAC源地址，这取决于Ethernet帧是源自该ES上的根AC还是叶AC。PE识别给定帧是否起源于段上的根或叶位置的机制基于
the Ethernet Tag associated with the frame. Other mechanisms of identification, beyond the Ethernet Tag, are outside the scope of this document.
与帧关联的以太网标记。除以太网标签外的其他识别机制不在本文件范围内。
Furthermore, a PE advertises two special global B-MAC addresses, one for Root and another for Leaf, and tags the Leaf one as such in the MAC Advertisement route. These B-MAC addresses are used as source addresses for traffic originating from single-homed segments. The B-MAC address used for indicating Leaf sites can be the same for both single-homed and multihomed segments.
此外，PE播发两个特殊的全局B-MAC地址，一个用于根，另一个用于叶，并且在MAC播发路由中将叶标记为这样。这些B-MAC地址用作源于单主网段的流量的源地址。用于指示叶站点的B-MAC地址对于单宿和多宿段都可以相同。
For known unicast traffic, the PEs perform ingress filtering: on the ingress PE, the Customer/Client MAC (C-MAC) [RFC7623] destination address lookup yields, in addition to the target B-MAC address and forwarding adjacency, a flag that indicates whether the target B-MAC is associated with a Root or a Leaf site. The ingress PE also checks the status of the originating site; if both are Leafs, then the packet is not forwarded.
对于已知的单播通信量，PEs执行入口过滤：在入口PE上，客户/客户端MAC（C-MAC）[RFC7623]目标地址查找除了目标B-MAC地址和转发邻接外，还产生一个标志，指示目标B-MAC是与根站点还是与叶站点相关联。入口PE还检查始发站点的状态；如果两者都是leaf，则不转发数据包。
For BUM traffic, the PEs must perform egress filtering. When a PE receives an EVPN MAC/IP Advertisement route (which will be used as a source B-MAC for BUM traffic), it updates its egress filtering (based on the source B-MAC address) as follows:
对于BUM流量，PEs必须执行出口过滤。当PE接收到EVPN MAC/IP播发路由（将用作BUM流量的源B-MAC）时，它更新其出口过滤（基于源B-MAC地址），如下所示：
- If the EVPN MAC/IP Advertisement route indicates that the advertised B-MAC is a Leaf, and the local ES is a Leaf as well, then the source B-MAC address is added to its B-MAC list used for egress filtering (i.e., to block traffic from that B-MAC address). Otherwise, the B-MAC filtering list is not updated.
- 如果EVPN MAC/IP播发路由指示播发的B-MAC是叶，并且本地ES也是叶，则源B-MAC地址被添加到其用于出口过滤的B-MAC列表中（即，阻止来自该B-MAC地址的流量）。否则，不更新B-MAC过滤列表。
- If the EVPN MAC/IP Advertisement route indicates that the advertised B-MAC has changed its designation from a Leaf to a Root, and the local ES is a Leaf, then the source B-MAC address is removed from the B-MAC list corresponding to the local ES used for egress filtering (i.e., to unblock traffic from that B-MAC address).
- 如果EVPN MAC/IP播发路由指示播发的B-MAC已将其指定从叶更改为根，并且本地ES是叶，则源B-MAC地址从与用于出口过滤的本地ES相对应的B-MAC列表中移除（即，解除阻止来自该B-MAC地址的流量）。
When the egress PE receives the packet, it examines the B-MAC source address to check whether it should filter or forward the frame. Note that this uses the same filtering logic as the split-horizon filtering described in Section 6.2.1.3 of [RFC7623] and does not require any additional flags in the data plane.
当出口PE接收到分组时，它检查B-MAC源地址，以检查是否应该过滤或转发帧。请注意，这使用了与[RFC7623]第6.2.1.3节中描述的分割地平线过滤相同的过滤逻辑，并且不需要在数据平面中添加任何额外的标志。
Just as in Section 4.2, the PE places all Leaf ESs of a given bridge domain in a single split-horizon group in order to prevent intra-PE forwarding among Leaf segments. This split-horizon function applies to BUM traffic as well as known unicast traffic.
正如第4.2节所述，PE将给定网桥域的所有叶ESs放置在单个分割地平线组中，以防止叶段之间的PE内转发。此分割地平线功能适用于BUM流量以及已知的单播流量。
In scenarios where the traffic of interest is only multicast and/or broadcast, the PEs implementing an E-Tree service do not need to do any MAC learning. In such scenarios, the filtering must be performed on egress PEs. For PBB-EVPN, the handling of such traffic is per Section 5.2 without the need for C-MAC learning (in the data plane) in the I-component (C-bridge table) of PBB-EVPN PEs (at both ingress and egress PEs).
在感兴趣的通信量仅为多播和/或广播的场景中，实现E-Tree服务的PEs不需要进行任何MAC学习。在这种情况下，必须对出口PE执行过滤。对于PBB-EVPN，根据第5.2节处理此类流量，而不需要PBB-EVPN PEs（入口和出口PEs）的I组件（C桥表）中的C-MAC学习（在数据平面中）。
This document defines a new BGP extended community for EVPN.
本文档为EVPN定义了一个新的BGP扩展社区。
This extended community is a new transitive extended community [RFC4360] having a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. It is used for Leaf-Indication of known unicast and BUM traffic. It indicates that the frame is originated from a Leaf site.
此扩展社区是一个新的可传递扩展社区[RFC4360]，其类型字段值为0x06（EVPN），子类型为0x05。它用于已知单播和BUM流量的叶指示。它表示该帧源于叶位置。
The E-Tree extended community is encoded as an 8-octet value as follows:
E-Tree扩展社区编码为8个八位组值，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x05 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x05 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: E-Tree Extended Community
图4：E-Tree扩展社区
The Flags field has the following format:
“标志”字段的格式如下：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |L| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |L| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
This document defines the following flags:
本文件定义了以下标志：
+ Leaf-Indication (L)
+ 叶片指示（L）
A value of one indicates a Leaf AC/site. The rest of the flag bits are reserved and should be set to zero.
值为1表示叶AC/位置。其余的标志位是保留的，应设置为零。
When this extended community is advertised along with the MAC/IP Advertisement route (for known unicast traffic) per Section 4.1, the Leaf-Indication flag MUST be set to one and the Leaf label SHOULD be set to zero. The receiving PE MUST ignore Leaf label and only process the Leaf-Indication flag. A value of zero for the Leaf-Indication flag is invalid when sent along with a MAC/IP Advertisement route, and an error should be logged.
根据第4.1节，当此扩展社区与MAC/IP广告路由（对于已知单播流量）一起广告时，必须将叶指示标志设置为1，且叶标签应设置为零。接收PE必须忽略叶标签，仅处理叶指示标志。当与MAC/IP播发路由一起发送时，叶指示标志的值为零无效，应记录错误。
When this extended community is advertised along with the EAD-ES route (with an ESI of zero) for BUM traffic to enable egress filtering on disposition PEs per Sections 4.2.1 and 4.2.3, the Leaf label MUST be set to a valid MPLS label (i.e., a non-reserved, assigned MPLS label [RFC3032]) and the Leaf-Indication flag SHOULD be set to zero. The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the Leaf label field. The receiving PE MUST ignore the Leaf-Indication flag. A non-valid MPLS label, when sent along with the EAD-ES route, should be ignored and logged as an error.
当按照第4.2.1节和第4.2.3节的规定，将此扩展社区与EAD-ES路由（ESI为零）一起发布用于BUM流量的广告，以便在处置PE上启用出口过滤时，必须将叶标签设置为有效的MPLS标签（即，非保留、分配的MPLS标签[RFC3032]），并且叶指示标志应设置为零。20位MPLS标签的值在叶标签字段的高阶20位中编码。接收PE必须忽略叶指示标志。当与EAD-ES路由一起发送时，应忽略无效的MPLS标签，并将其记录为错误。
The reserved bits SHOULD be set to zero by the transmitter and MUST be ignored by the receiver.
发射机应将保留位设置为零，接收机必须忽略保留位。
[RFC6514] defines the PMSI Tunnel attribute, which is an optional transitive attribute with the following format:
[RFC6514]定义PMSI隧道属性，该属性是可选的可传递属性，格式如下：
+-------------------------------------------+
| Flags (1 octet) |
+-------------------------------------------+
| Tunnel Type (1 octet) |
+-------------------------------------------+
| Ingress Replication MPLS Label (3 octets) |
+-------------------------------------------+
| Tunnel Identifier (variable) |
+-------------------------------------------+
+-------------------------------------------+
| Flags (1 octet) |
+-------------------------------------------+
| Tunnel Type (1 octet) |
+-------------------------------------------+
| Ingress Replication MPLS Label (3 octets) |
+-------------------------------------------+
| Tunnel Identifier (variable) |
+-------------------------------------------+
Table 1: PMSI Tunnel Attribute
表1:PMSI隧道属性
This document defines a new composite tunnel type by introducing a new 'composite tunnel' bit in the Tunnel Type field and adding an MPLS label to the Tunnel Identifier field of the PMSI Tunnel attribute, as detailed below. All other fields remain as defined in [RFC6514]. Composite tunnel type is advertised by the Root PE to simultaneously indicate a non-Ingress-Replication tunnel (e.g., P2MP tunnel) in the transmit direction and an Ingress Replication tunnel in the receive direction for the BUM traffic.
本文档通过在隧道类型字段中引入新的“复合隧道”位，并将MPLS标签添加到PMSI隧道属性的隧道标识符字段中，定义了新的复合隧道类型，如下所述。所有其他字段保持[RFC6514]中的定义。复合隧道类型由根PE播发，以同时指示BUM流量的传输方向上的非入口复制隧道（例如，P2MP隧道）和接收方向上的入口复制隧道。
When receiver Ingress Replication labels are needed, the high-order bit of the Tunnel Type field (composite tunnel bit) is set while the remaining low-order seven bits indicate the Tunnel Type as before (for the existing Tunnel Types). When this composite tunnel bit is set, the "tunnel identifier" field begins with a three-octet label, followed by the actual tunnel identifier for the transmit tunnel. PEs that don't understand the new meaning of the high-order bit treat the Tunnel Type as an undefined Tunnel Type and treat the PMSI Tunnel attribute as a malformed attribute [RFC6514]. That is why the composite tunnel bit is allocated in the Tunnel Type field rather than the Flags field. For the PEs that do understand the new meaning of the high-order, if Ingress Replication is desired when sending BUM traffic, the PE will use the label in the Tunnel Identifier field when sending its BUM traffic.
当需要接收器入口复制标签时，隧道类型字段的高位（复合隧道位）被设置，而剩余的低位七位与之前一样指示隧道类型（对于现有隧道类型）。设置此复合隧道位时，“隧道标识符”字段以三个八位组标签开始，然后是传输隧道的实际隧道标识符。不理解高阶位新含义的PE将隧道类型视为未定义的隧道类型，并将PMSI隧道属性视为格式错误的属性[RFC6514]。这就是为什么在隧道类型字段而不是标志字段中分配复合隧道位的原因。对于理解高阶新含义的PE，如果发送BUM流量时需要入口复制，则PE将在发送其BUM流量时使用隧道标识符字段中的标签。
Using the composite tunnel bit for Tunnel Types 0x00 'no tunnel information present' and 0x06 'Ingress Replication' is invalid. A PE that receives a PMSI Tunnel attribute with such information considers it malformed, and it SHOULD treat this Update as though all the routes contained in this Update had been withdrawn per Section 6 of [RFC6514].
对隧道类型0x00“无隧道信息存在”和0x06“入口复制”使用复合隧道位无效。接收带有此类信息的PMSI隧道属性的PE认为其格式不正确，应将此更新视为已根据[RFC6514]第6节撤销了此更新中包含的所有路由。
Since this document uses the EVPN constructs of [RFC7432] and [RFC7623], the same security considerations in these documents are also applicable here. Furthermore, this document provides an additional security check by allowing sites (or ACs) of an EVPN instance to be designated as a "Root" or "Leaf" by the network operator / service provider and thus prevent any traffic exchange among "Leaf" sites of that VPN through ingress filtering for known unicast traffic and egress filtering for BUM traffic. Since (by default and for the purpose of backward compatibility) an AC that doesn't have a Leaf designation is considered a Root AC, in order to avoid any traffic exchange among Leaf ACs, the operator SHOULD configure the AC with a proper role (Leaf or Root) before activating the AC.
由于本文档使用[RFC7432]和[RFC7623]的EVPN构造，因此这些文档中的相同安全注意事项也适用于此处。此外，本文件通过允许网络运营商/服务提供商将EVPN实例的站点（或AC）指定为“根”或“叶”，提供了额外的安全检查，从而防止“叶”之间的任何流量交换该VPN的站点通过已知单播流量的入口过滤和BUM流量的出口过滤。由于（出于向后兼容性的目的，默认情况下）没有叶指定的AC被视为根AC，为了避免叶AC之间的任何流量交换，操作员应在激活AC之前将AC配置为适当的角色（叶或根）。
IANA has allocated sub-type value 5 in the "EVPN Extended Community Sub-Types" registry defined in [RFC7153] as follows:
IANA已在[RFC7153]中定义的“EVPN扩展社区子类型”注册表中分配子类型值5，如下所示：
SUB-TYPE VALUE NAME Reference
-------------- ------------------------- -------------
0x05 E-Tree Extended Community This document
SUB-TYPE VALUE NAME Reference
-------------- ------------------------- -------------
0x05 E-Tree Extended Community This document
This document creates a one-octet registry called "E-Tree Flags". New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. Initial registrations are as follows:
本文档创建了一个名为“E-Tree Flags”的八位字节注册表。新的注册将通过[RFC8126]中定义的“需要RFC”程序进行。初步登记如下：
Bit Name Reference
---- -------------- -------------
0-6 Unassigned
7 Leaf-Indication This document
Bit Name Reference
---- -------------- -------------
0-6 Unassigned
7 Leaf-Indication This document
The "P-Multicast Service Interface (PMSI) Tunnel Types" registry in the "Border Gateway Protocol (BGP) Parameters" registry has been updated to reflect the use of the most significant bit as the "composite tunnel" bit (see Section 6.2).
“边界网关协议（BGP）参数”注册表中的“P-多播服务接口（PMSI）隧道类型”注册表已更新，以反映最高有效位作为“复合隧道”位的使用情况（见第6.2节）。
For this purpose, this document updates [RFC7385] by changing the previously unassigned values (i.e., 0x08 - 0xFA) as follows:
为此，本文件通过更改先前未分配的值（即0x08-0xFA）来更新[RFC7385]，如下所示：
Value Meaning Reference
--------- ----------------------------- --------------
0x0C-0x7A Unassigned
0x7B-0x7E Experimental This Document
0x7F Reserved This Document
0x80-0xFA Reserved for Composite Tunnel This Document
0xFB-0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
Value Meaning Reference
--------- ----------------------------- --------------
0x0C-0x7A Unassigned
0x7B-0x7E Experimental This Document
0x7F Reserved This Document
0x80-0xFA Reserved for Composite Tunnel This Document
0xFB-0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
The allocation policy for values 0x08-0x7A is per IETF Review [RFC8126]. The range for "Experimental" has been expanded to include the previously assigned range of 0xFB-0xFE and the new range of 0x7B-0x7E. The values in these ranges are not to be assigned. The value 0x7F, which is the mirror image of (0xFF), is reserved in this document.
值0x08-0x7A的分配策略符合IETF审查[RFC8126]。“实验”的范围已扩大，包括先前指定的0xFB-0xFE范围和新的0x7B-0x7E范围。不分配这些范围内的值。值0x7F是（0xFF）的镜像，在本文档中保留。
[MEF6.1] MEF Forum, "Ethernet Services Definitions - Phase 2", MEF 6.1, April 2008, <https://mef.net/PDF_Documents/ technical-specifications/MEF6-1.pdf>.
[MEF6.1]MEF论坛，“以太网服务定义-第2阶段”，MEF6.12008年4月<https://mef.net/PDF_Documents/ 技术规范/MEF6-1.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，DOI 10.17487/RFC4360，2006年2月<https://www.rfc-editor.org/info/rfc4360>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<https://www.rfc-editor.org/info/rfc6514>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7153]Rosen，E.和Y.Rekhter，“BGP扩展社区的IANA注册”，RFC 7153，DOI 10.17487/RFC7153，2014年3月<https://www.rfc-editor.org/info/rfc7153>.
[RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <https://www.rfc-editor.org/info/rfc7385>.
[RFC7385]Andersson，L.和G.Swallow，“P-多播服务接口（PMSI）隧道类型代码点的IANA注册”，RFC 7385，DOI 10.17487/RFC7385，2014年10月<https://www.rfc-editor.org/info/rfc7385>.
[RFC7387] Key, R., Ed., Yong, L., Ed., Delord, S., Jounay, F., and L. Jin, "A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network", RFC 7387, DOI 10.17487/RFC7387, October 2014, <https://www.rfc-editor.org/info/rfc7387>.
[RFC7387]Key，R.，Ed.，Yong，L.，Ed.，Delord，S.，Jounay，F.，和L.Jin，“多协议标签交换（MPLS）网络上的以太网树（E-Tree）服务框架”，RFC 7387，DOI 10.17487/RFC7387，2014年10月<https://www.rfc-editor.org/info/rfc7387>.
[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>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7623]Sajassi，A.，Ed.，Salam，S.，Bitar，N.，Isaac，A.，和W.Henderickx，“提供商主干桥接与以太网VPN（PBB-EVPN）相结合”，RFC 7623，DOI 10.17487/RFC7623，2015年9月<https://www.rfc-editor.org/info/rfc7623>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[EVPN-INTEGRATED] 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-集成]Sajassi，A.，Salam，S.，Thoria，S.，Drake，J.，Rabadan，J.，和L.Yong，“EVPN中的集成路由和桥接”，正在进行的工作，草稿-ietf-bess-EVPN-inter-subnet-forwarding-032017年2月。
[IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
[IEEE.802.1ah]IEEE，“局域网和城域网IEEE标准-媒体访问控制（MAC）网桥和虚拟桥接局域网”，第25和26条，IEEE标准802.1Q，DOI 10.1109/IEEESTD.2011.6009146。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
[IEEE.802.1Q]IEEE，“局域网和城域网IEEE标准-网桥和桥接网络-媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q，DOI 10.1109/IEEESTD.2011.6009146。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，DOI 10.17487/RFC3032，2001年1月<https://www.rfc-editor.org/info/rfc3032>.
[RFC7796] Jiang, Y., Ed., Yong, L., and M. Paul, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)", RFC 7796, DOI 10.17487/RFC7796, March 2016, <https://www.rfc-editor.org/info/rfc7796>.
[RFC7796]Jiang，Y.，Ed.，Yong，L.，和M.Paul，“虚拟专用局域网服务（VPLS）中的以太网树（E-Tree）支持”，RFC 7796，DOI 10.17487/RFC77962016年3月<https://www.rfc-editor.org/info/rfc7796>.
When two MAC-VRFs (two bridge tables per VLAN) are used for an E-Tree service (one for Root ACs and another for Leaf ACs) on a given PE, then the following complications in a data-plane path can result.
当两个MAC VRF（每个VLAN两个桥接表）用于给定PE上的E-Tree服务（一个用于根ACs，另一个用于叶ACs）时，可能会导致数据平面路径中出现以下复杂情况。
Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf and Root ACs exists for that VLAN) would require either that two lookups be performed per MAC address in each direction in case of a miss or that the duplication of many MAC addresses between the two bridge tables belonging to the same VLAN (same E-Tree instance) be made. Unless two lookups are made, duplication of MAC addresses would be needed for both locally learned and remotely learned MAC addresses. Locally learned MAC addresses from Leaf ACs need to be duplicated onto a Root bridge table, and locally learned MAC addresses from Root ACs need to be duplicated onto a Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Because of potential inefficiencies associated with data-plane implementation of additional MAC lookup or duplication of MAC entries, this option is not believed to be implementable without data-plane performance inefficiencies in some platforms; thus, this document introduces the coloring as described in Section 3.2 and detailed in Section 4.1.
维护每个VLAN的两个MAC VRF（两个网桥表）（当该VLAN的叶ACs和根ACs都存在时）需要在每个方向上对每个MAC地址执行两次查找，以防丢失，或者在属于同一VLAN（同一E树实例）的两个网桥表之间复制多个MAC地址。除非进行两次查找，否则本地学习和远程学习的MAC地址都需要重复MAC地址。来自叶ACs的本地学习MAC地址需要复制到根网桥表上，来自根ACs的本地学习MAC地址需要复制到叶网桥表上。从根ACs远程学习的MAC地址需要复制到根和叶桥表中。由于额外MAC查找的数据平面实现或MAC项的复制可能会导致效率低下，因此在某些平台上，如果没有数据平面性能低下的情况，则不认为可以实现此选项；因此，本文件介绍了第3.2节所述以及第4.1节所述的着色。
Acknowledgements
致谢
We would like to thank Eric Rosen, Jeffrey Zhang, Wen Lin, Aldrin Issac, Wim Henderickx, Dennis Cai, and Antoni Przygienda for their valuable comments and contributions. The authors would also like to thank Thomas Morin for shepherding this document and providing valuable comments.
我们要感谢Eric Rosen、Jeffrey Zhang、Wen Lin、Aldrin Issac、Wim Henderickx、Dennis Cai和Antoni Przygienda的宝贵评论和贡献。作者还要感谢Thomas Morin对本文件的指导和提供的宝贵意见。
Authors' Addresses
作者地址
Ali Sajassi (editor) Cisco
阿里·萨贾西（编辑）思科
Email: sajassi@cisco.com
Email: sajassi@cisco.com
Samer Salam Cisco
萨默萨拉姆思科
Email: ssalam@cisco.com
Email: ssalam@cisco.com
John Drake Juniper
约翰德雷克杜尼珀
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Jim Uttaro AT&T
吉姆乌塔罗AT&T
Email: ju1738@att.com
Email: ju1738@att.com
Sami Boutros VMware
萨米·布特罗斯
Email: sboutros@vmware.com
Email: sboutros@vmware.com
Jorge Rabadan Nokia
豪尔赫·拉巴丹诺基亚
Email: jorge.rabadan@nokia.com
Email: jorge.rabadan@nokia.com