以太网VPN(EVPN)和提供商骨干桥接EVPN(PBB-EVPN)中的以太网树(E-Tree)支持

RFC8317：Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)，January 2018

梗概

MEF 论坛 (MEF) 定义了一种称为以太网树 (Ethernet-Tree，E-Tree) 的有根多点以太网服务。在 RFC 7387“多协议标签交换 (Multiprotocol Label Switching，MPLS) 网络上的以太网树 (E-Tree) 服务框架”中描述了在 MPLS 网络中支持该服务的解决方案框架。本文档讨论了如何使用基于RFC 7432“基于 BGP MPLS 的以太网 VPN (Ethernet VPN，EVPN)”的解决方案来满足这些功能要求，并进行了一些扩展，并描述了此类解决方案如何提供比这些功能更有效的实现。RFC 7796-“虚拟专用 LAN 服务 (Virtual Private LAN Service，VPLS) 中的以太网树（E-Tree）支持”。本文档使用了由RFC 7385创建的 IANA 注册表管理的隧道类型字段的最高有效位（在 P-组播服务接口 (P-Multicast Service Interface，PMSI) 隧道属性中）；因此，它相应地更新了 RFC 7385。

本备忘录的状态

这是一个 Internet 标准跟踪文档。

本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 团体字的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8317。

版权声明

版权所有 (c) 2018 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。

1、 介绍

MEF 论坛 (MEF) 定义了一种称为以太网树 (E-Tree) [MEF6.1] 的有根多点以太网服务。在 E-Tree 服务中，通常由接入电路 (Attachment Circuit，AC)（例如，802.1Q VLAN 标签 [IEEE.802.1Q]）表示的客户站点被标记为根站点或叶子站点。客户站点也可以由媒体访问控制 (Media Access Control，MAC) 地址和 VLAN 标记表示。根站点可以与所有其他客户站点（根站点和叶子站点）进行通信。但是，Leaf 站点可以与 Root 站点通信，但不能与其他 Leaf 站点通信。在本文档中，除非另有明确说明，站点始终由 AC 表示。

[RFC7387] 描述了在 MPLS 网络中支持 E-Tree 服务的解决方案框架。本文档确定了在 MPLS 网络中模拟 E-Tree 服务的整体解决方案的功能组件，并补充了 [RFC7432] 和 [RFC7623] 中规定的多点对多点以太网 LAN (Ethernet LAN，E-LAN) 服务。

[RFC7432] 定义了 EVPN，这是一种用于多点二层虚拟专用网络 (Layer 2 Virtual Private Network，L2VPN) 服务的解决方案，具有高级多宿主功能，使用 BGP 在 MPLS/IP 网络上分发客户/客户端 MAC 地址可达性信息。[RFC7623] 将 EVPN 的功能与 [IEEE.802.1ah] 提供商骨干桥接 (Provider Backbone Bridging，PBB) 相结合，以实现 MAC 地址可扩展性。

本文档讨论了如何使用基于 EVPN [RFC7432] 和 PBB-EVPN [RFC7623] 的解决方案来满足 E-Tree 服务的功能要求，并对其过程和 BGP 属性进行了一些扩展。这种基于 PBB-EVPN 或 EVPN 的解决方案可以提供比[RFC7796]“虚拟专用局域网服务（VPLS）中的以太网树（E-Tree）支持”更有效的实现这些功能。这种效率是通过在入口提供商边缘 (Provider Edge，PE) 节点执行单播流量过滤而不是出口过滤来实现的，在出口过滤中，流量通过网络发送并在出口 PE 节点被过滤和丢弃。此入口过滤的详细信息在第 4.1 节中描述。由于本文档指定了基于 [RFC7432] 的解决方案，因此了解该文档是先决条件。本文档使用了由 [RFC7385] 创建的 IANA 注册管理机构管理的隧道类型字段的最高有效位（在 PMSI 隧道属性中）；因此，它相应地更新了 [RFC7385]。第 3 节讨论 E-Tree 场景，第 4 节和第 5 节描述 EVPN 和 PBB-EVPN（分别）的 E-Tree 解决方案，第 6 节涵盖 E-Tree 解决方案的 BGP 编码。

2、 术语

2.1、 需求说明

关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” “当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

2.2、 术语和缩写

Broadcast Domain：广播域，在桥接网络中，广播域对应一个虚拟局域网 (Virtual LAN，VLAN)，其中一个 VLAN 通常由单个 VLAN ID (VID) 表示，但可以由多个 VID 表示，其中使用共享 VLAN 学习 (Shared VLAN Learning，SVL)根据 [IEEE.802.1ah]。

Bridge Table：桥接表，MAC-VRF 上广播域的实例化。

CE：Customer Edge，客户边缘设备，例如主机、路由器或交换机。

EVI：跨越参与该 EVPN 的提供商边缘 (PE) 设备的 EVPN 实例（EVPN Instance）。

MAC-VRF：PE 上媒体访问控制 (Media Access Control，MAC) 地址的虚拟路由和转发表（Virtual Routing and Forwarding，VRF）。

ES：当客户站点（设备或网络）通过一组以太网链路连接到一个或多个 PE 时，该组链路称为“以太网段（Ethernet Segment）”。

ESI：Ethernet Segment Identifier，以太网段标识符是标识 ES 的唯一非零标识符。

Ethernet Tag：以太网标签，以太网标签标识特定的广播域，例如 VLAN。一个 EVPN 实例由一个或多个广播域组成。

P2MP：Point-to-Multipoint，点对多点。

PE：Provider Edge device，提供商边缘设备。

3、 E-Tree 场景

本文档根据根/叶子站点关联的性质将 E-Tree 场景分为以下三类：

场景 1：每个 PE 的叶子或根站点；

场景 2：每个接入电路 (AC) 的叶子站点或根站点；或者，

场景 3：每个 MAC 地址的叶子站点或根站点。

3.1、 场景 1：每个 PE 的叶子或根站点

在这种情况下，对于给定的 MAC-VRF/网桥表，PE 可能会从根 AC 或叶子 AC 接收流量，但不能同时接收两者。换言之，提供商边缘 (PE) 设备上的给定 EVPN 实例 (EVI) 与根或叶子关联。尽管针对不同的 EVI，PE 可能同时具有根和叶子 AC。

图 1：场景 1

在这种情况下，可以使用在属于同一 EVI 的 PE 之间定制的 BGP 路由目标 (Route Target，RT) 导入/导出策略来阻止 Leaf PE 之间的通信。为了防止连接到同一 PE 并属于同一 EVI 的 Leaf AC 之间的通信，水平分割过滤用于阻止流量从一个 Leaf AC 到另一个 Leaf AC 在 MAC-VRF 上的给定 E-Tree EVI。此拓扑约束的目的是避免只有叶子站点的 PE 相互导入和处理 BGP MAC 路由。为了支持 EVPN 中的这种拓扑约束，每个 EVI 使用两个 BGP RT：一个 RT 与根站点（Root AC）相关联，另一个与叶子站点（Leaf AC）相关联。在每个 EVI 的基础上，每个 PE 导出与其站点类型相关联的单个 RT。此外，具有根站点的 PE 导入根和叶子 RT，而具有叶子站点的 PE 仅导入根 RT。

对于这个场景，如果希望每个 EVI 只使用一个 RT（就像 [RFC7432] 中的 E-LAN 服务），那么需要使用场景 2 中的方法 B（如下所述）。

3.2、 场景 2：每个 AC 的叶子或根站点

在这种情况下，PE 可以从根 AC 和叶子 AC 接收给定 EVI 的流量。换句话说，PE 上的给定 EVI 可以与根和叶子相关联。

图 2：场景 2

在这个场景中（如场景 1 第 3.1 节），可以使用两个 RT（一个用于根，另一个用于叶子）。但不同的是，在同时具有Root和Leaf AC的PE上，远端MAC路由全部引入；因此，为了应用适当的入口过滤，需要有一种方法来区分与叶子 AC 相关联的远程 MAC 路由与与根 AC 相关联的远程 MAC 路由。

为了识别目标 MAC 地址与 Leaf 或 Root AC 的关联，从而支持在具有 Leaf 和 Root AC 的入口 PE 上的入口过滤，MAC 地址需要在通告之前使用 Root 或 Leaf-Indication 着色给其他PE。这种着色有两种方法：

(A) 始终使用两个 RT（一个指定叶子 RT，另一个指定根 RT），或

(B) 允许每个 EVI 使用单个 RT，就像 [RFC7432] 一样，因此，通过新扩展团体字中的“颜色”标志对 MAC 地址进行着色，如第 6.1 节所述。

如果每个 VLAN 使用的 MAC-VRF 和网桥表要与 [RFC7432] 的第 6 节保持一致，则方法 A 将需要与方法 B 相同的数据平面增强。为了避免方法 A 的数据平面增强，可以考虑每个 VLAN 有多个网桥表；但是，这有很大的缺点（如附录 A 中所述）；因此，不推荐。

考虑到方法 A 和 B 都需要相同的数据平面增强功能，这里选择方法 B 是为了允许 RT 使用与基线 EVPN [RFC7432] 一致并具有更好的通用性。需要注意的是，如果想要使用RT约束来避免与Leaf AC相关的MAC通告给只有Leaf AC的PE，那么两种RT（一个用于Root，另一个用于Leaf）仍然可以与方法B一起使用；然而，在此类应用中，叶子/根 RT 将用于约束 MAC 通告，而不用于为入口过滤的 MAC 路由着色（即，在方法 B 中，着色始终通过新的扩展团体字完成）。

如果对于给定的 EVI，大量 PE 同时连接了叶子和根站点（即使它们可能以仅根或仅叶子的 PE 开始），则应使用每个 EVI 的单个 RT。提出这种建议的原因是为了减轻与每个 EVI 使用两个 RT 相关的配置开销，代价是在 Leaf-only PE 上有一些不需要的 MAC 地址。

3.3、 场景 3：每个 MAC 地址的叶子或根站点

在这种情况下，客户根或叶子站点由 AC 上的 MAC 地址表示，PE 可能会从该 AC 上的根站点和叶子站点接收流量，用于 EVI。[RFC7387] 或 [MEF6.1] 中均未涵盖此场景；但是，为了完整起见，它在本文档中进行了介绍。在这种情况下，由于 AC 承载来自根站点和叶子站点的流量，因此识别根站点或叶子站点的粒度是基于每个 MAC 地址的。本文档针对仅具有已知单播流量的 EVPN 服务考虑了这种情况，因为根据 [RFC7432] 的指定转发器 (Designated Forwarder，DF) 过滤与所需的出口过滤不兼容；也就是说，在这种情况下不支持广播、未知单播和组播 (Broadcast, Unknown Unicast, and Multicast，BUM) 流量；它被入口 PE 丢弃。

对于此场景，使用场景 2 中的方法 B 以允许服务提供商使用单个 RT。

图 3：场景 3

综上所述，方案二中的方案B是上述三种方案的推荐方案，相应的解决方案将在以下部分详细介绍。

4、 EVPN 操作

[RFC7432] 定义了以太网段标识符 (ESI) MPLS 标签的概念，用于在出口 PE 处对 BUM 流量进行水平分割过滤。此类出口过滤功能可用于提供 E-Tree 服务，因为它很快就会用于 BUM 流量。对于已知的单播流量，需要对 [RFC7432] 进行额外扩展（即，第 6.1 节中描述的叶子指示的新 BGP 扩展团体字）以启用入口过滤，如以下部分所述。

4.1、 已知单播流量

在 EVPN 中，MAC 学习是通过 BGP 路由的通告在控制平面中进行的。因此，E-Tree 服务对已知单播流量所需的过滤可以在入口 PE 处执行，从而提供非常有效的过滤并避免通过 MPLS/IP 核心发送已知单播流量以在出口 PE 处过滤，就像在传统的 E-Tree 解决方案中所做的一样（即，用于 VPLS [RFC7796] 的 E-Tree）。

为了为已知的单播流量提供这种入口过滤，PE 必须向其他 PE 指示其 MAC 地址与哪种站点（根或叶子）相关联。这是通过通告叶子指示标志（通过扩展团体字）以及从叶子站点获知的每个 MAC/IP 通告路由来完成的。缺少此类标志表明 MAC 地址与根站点相关联。该方案适用于第 3 节中描述的所有场景。

使用 Leaf-Indication 标记 MAC 地址使远程 PE 能够对已知单播流量执行入口过滤；也就是说，在入口 PE 上，MAC 目标地址查找产生（除了转发邻接之外）一个标志，指示目标 MAC 是否与叶子站点相关联。入口 PE 与始发 AC 的状态交叉检查此标志，如果两者都是叶子，则不转发数据包。

在允许 MAC 在 Leaf 和 Root 站点之间迁移的情况下（例如，非静态 MAC），PE 可以接收针对相同 MAC 地址的多个 MAC/IP 通告路由，这些路由具有不同的 Root 或 Leaf-Indications（对于多宿主可能还有不同的 ESI）场景）。在这种情况下，MAC 迁移性过程（参见 [RFC7432] 的第 15 节）在将该 MAC 与根或叶子站点相关联之前首先确定 MAC 的位置。

为了支持上述入口过滤功能，引入了一个带有叶子指示标志的新 E-Tree 扩展团体字（参见第 6.1 节）。这个新的扩展团体字必须使用从叶子站点获知的 MAC/IP 通告路由进行通告。除了 MAC/IP 通告路由之外，不需要其他 EVPN 路由来承载这个新的扩展团体字，以达到已知单播流量的目的。

4.2、 BUM 流量

本规范不支持在入口 PE 上过滤广播、未知单播和组播 (BUM) 流量；由于 BUM 流量的多目的地特性，不可能在入口 PE 上执行相同的过滤。因此，该解决方案依赖于出口过滤。为了应用适当的出口过滤，根据数据包是从叶子 AC 还是根 AC 发送，MPLS 封装的帧必须标记有它们何时起源于叶子 AC 的指示（即，到用第 6.1 节中指定的叶子标签标记）。该叶子标签允许处置 PE（例如，出口 PE）在类似于 [RFC7432] 中的 ESI 标签的数据平面中执行必要的出口过滤功能。叶子标签的分配基于每个 PE（例如，独立于 ESI 和 EVI），如以下部分所述。

叶子标签可以上游分配给点对多点 (P2MP) 标签交换路径 (Label Switched Path，LSP) 或下游分配给入口复制隧道。下游分配的 Leaf 标签和上游分配的 Leaf 标签的主要区别在于，在下游分配的 Leaf 标签的情况下，并非所有出口 PE 设备都需要接收 MPLS 封装的 BUM 数据包中的标签，就像 Ingress 的 ESI 标签一样[RFC7432] 中定义的复制过程。

在入口 PE 上，PE 需要将给定网桥域的所有叶子 AC 放置在单个水平分割组中，以防止其叶子 AC 之间的 PE 内转发。这种 PE 内水平分割过滤适用于 BUM 流量以及已知的单播流量。

有以下四种情况需要考虑。在所有这些场景中，入口 PE 会根据以太网帧是源自该以太网段上的根站点还是叶子站点（ESI 标签或叶子标签）来强加与起源的以太网段 (ES) 相关联的正确 MPLS 标签。PE 识别给定帧是源自段上的根站点还是叶子站点的机制基于该段的 AC 标识符（例如，802.1Q 帧的帧的以太网标签 [IEEE.802.1Q]） .用于识别根或叶子站点的其他机制，例如使用接收帧的源 MAC 地址，是可选的。下面的场景是在根/叶子 AC 的上下文中描述的，但是，如果需要，它们可以扩展到根/叶子 MAC 地址。

4.2.1、 来自叶子 AC 上的单宿主站点的 BUM 流量

在这种情况下，入口 PE 添加使用 E-Tree 扩展团体字（见第 6.1 节）通告的 Leaf 标签，表示一个 Leaf 站点。该叶子标签用于单归属场景，不是基于每个 ES 而是基于每个 PE（即，单个叶子 MPLS 标签用于该 PE 上的所有单归属 ES）。该叶子标签使用 E-Tree 扩展团体字（参见第 6.1 节）以及 ESI 为零的以太网自动发现（Ethernet Auto-Discovery per ES，EAD-ES）路由和一组对应于所有 EVI 的 RT 通告给其他 PE 设备在每个 EVI 至少有一个叶子站点的 PE 上。如果需要携带的 RT 数量超过 [RFC7432] 中单个路由的限制，则需要通告多条 EAD-ES 路由。EAD-ES 路由的 ESI 设置为零以指示单宿主站点。

当PE在数据路径中收到这个特殊的Leaf标签时，如果目的AC是Leaf类型，它就会阻塞这个数据包；否则，它转发数据包。

4.2.2、 BUM 流量源自根 AC 上的单宿主站点

在这种情况下，入口 PE 不添加任何 ESI 或叶子标签，它按照 [RFC7432] 中的程序运行。

4.2.3、 来自叶子 AC 上的多宿主站点的 BUM 流量

在这种情况下，假设同一 ES 上的不同 AC (VLAN) 可能具有不同的根/叶子指定（有些是根，有些是叶子），但同一个 VLAN 在所有 PE 上确实具有相同的根/叶子指定在同一个 ES 上。此外，假设子网之间没有转发（即服务是 EVPN L2 而不是 EVPN 集成路由和桥接 (Integrated Routing and Bridging，IRB) [EVPN-INTEGRATED]）。[EVPN-INTEGRATED] 中描述的 IRB 用例超出了本文档的范围。

在这种情况下，如果组播或广播报文来自Leaf AC，那么它只需要携带一个Leaf标签，如4.2.1节所述。此标签足以提供必要的 BUM 流量出口过滤，以免发送到叶子 AC，包括同一 ES 上的叶子 AC。

4.2.4、 BUM 流量源自根 AC 上的多宿主站点

在这种情况下，入口和出口 PE 设备都遵循 [RFC7432] 中定义的过程来添加和/或处理 ESI MPLS 标签；也就是说，[RFC7432] 中现有的 BUM 流量程序就足够了，不需要添加 Leaf 标签。

4.3、 EVPN 的 E-Tree 流量流

根据 [RFC7387]，通用 E-Tree 服务支持以下所有流量：

- 从 Root 到 Roots & Leafs 的已知单播流量

- 从叶子到根的已知单播流量

- 从 Root 到 Roots & Leafs 的 BUM 流量

- 从叶子到根的 BUM 流量

特定的 E-Tree 服务可能需要支持所有上述类型的流或仅支持选定的子集，具体取决于目标应用程序。在只需要支持组播和广播流的情况下，L2VPN PE可以避免执行任何MAC学习功能。

以下小节将描述 EVPN 的操作以支持有和没有 MAC 学习的 E-Tree 服务。

4.3.1、 带有 MAC 学习的 E-Tree

当根和叶子站点之间必须支持单播流量时，实现 E-Tree 服务的 PE 必须执行 MAC 学习。在这种情况下，具有根站点的 PE 在 ES 上的数据路径中执行 MAC 学习，并在 EVPN MAC/IP 通告路由中通告可达性。这些路由将由该 EVI 的所有 PE 导入（即，具有叶子站点的 PE 以及具有根站点的 PE）。类似地，具有叶子站点的 PE 在其 ES 上的数据路径中执行 MAC 学习，并在 EVPN MAC/IP 通告路由中通告可达性。对于每个 EVI 使用两个不同 RT（一个指定 Root 站点，另一个指定 Leaf 站点）的场景，MAC/IP Advertisement 路由仅由 EVI 中至少有一个 Root site 的 PE 导入（即，一个只有叶子站点的 PE 不会导入这些路由）。具有根和/或叶子站点的 PE 可以使用每个 EVI 的以太网自动发现 (EAD-EVI) 路由进行别名（在多宿主段的情况下）和 EAD-ES 路由用于根据 [RFC7432] 的大量 MAC 撤回。

为了支持从根站点到叶子站点的组播/广播，可以使用以 PE 为根的 P2MP 树和根站点（例如，根 PE）或入口复制（参见 [RFC7432] 的第 16 节）。组播隧道是通过 EVPN 包含组播路由的交换建立的，如 [RFC7432] 中所定义。

为了支持从叶子节点到根站点的组播/广播，可以使用来自每个叶子 PE 的入口复制隧道或以每个叶子 PE 为根的 P2MP 树。以下两段描述了何时可以使用这些隧道方案中的每一个以及如何用信号通知它们。

当只有少数根 PE 具有少量组播/广播流量从叶子 PE 到根 PE 时，从叶子 PE 到根 PE 的入口复制隧道就足够了。因此，如果 Root PE 需要在从自身到 Leaf PE 的传输方向上支持 P2MP 隧道，同时又希望在接收方向上支持 Ingress Replication 隧道，则 Root PE 可以通过使用6.2 节中定义的一种新的复合隧道类型。这种新的复合隧道类型由根 PE 通告，以同时为 BUM 流量指示发送方向上的 P2MP 隧道和接收方向上的入口复制隧道。

如果Root PE数量较多，可以使用Leaf PE发起的P2MP隧道（例如Multipoint LDP（mLDP）或RSVP-TE）；因此，将不需要使用修改后的 PMSI 隧道属性和第 6.2 节中定义的复合隧道类型值。

4.3.2、 没有 MAC 学习的 E-Tree

当Root站点和Leaf站点之间的流量主要是组播或广播时，实现E-Tree业务的PE不需要进行MAC学习。在这种情况下，PE 之间不交换 EVPN MAC/IP 通告路由。相反，Inclusive Multicast Ethernet Tag 路由用于支持 BUM 流量。在这种情况下，少量单播流量（如果有）作为 BUM 流量的一部分发送。

该路由的字段按照 [RFC7432] 中定义的过程填充，组播隧道设置标准如上一节所述。

和上一节一样，如果根 PE 的数量只有几个，因此需要从叶子 PE 到这些根 PE 的入口复制，那么 6.2 节中定义的修改后的 PMSI 属性和复合隧道类型值应该是用过的。

5、 PBB-EVPN 操作

在 PBB-EVPN 中，PE 与每个骨干 MAC (Backbone MAC，B-MAC) 通告路由一起通告 Root 或 Leaf-Indication，以指示关联的 B-MAC 地址是对应于 Root 站点还是 Leaf 站点。就像 EVPN 的情况一样，第 6.1 节中定义的新 E-Tree 扩展团体字与每个 EVPN MAC/IP 通告路由一起通告。

在多宿主 ES 同时连接根站点和叶子站点的情况下，会通告两个 B-MAC 地址：一个 B-MAC 地址是每个 ES（如 [RFC7623] 中指定的）并隐式表示根，另一个 B-MAC地址是每个 PE 并明确表示叶子。前者的 B-MAC 地址不与 E-Tree 扩展团体字一起通告，但表示叶子的后一个 B-MAC 地址与设置了“Leaf-indication”标志的新 E-Tree 扩展团体字一起通告。在 ES 同时具有根和叶子 AC 的多宿主场景中，假设虽然同一 ES 上的不同 AC (VLAN) 可能具有不同的根/叶子指定（一些是根，一些是叶子），但同一个 VLAN 确实有在同一 ES 上的所有 PE 上具有相同的根/叶子指定。此外，假设子网之间没有转发（即服务是 L2 而不是 IRB）。IRB 用例超出了本文档的范围。

入口 PE 使用正确的 B-MAC 源地址，具体取决于以太网帧是源自该 ES 上的根 AC 还是叶子 AC。PE 识别给定帧是源自段上的根站点还是叶子站点的机制基于与该帧相关联的以太网标签。以太网标签之外的其他识别机制不在本文档的范围内。

此外，PE 通告两个特殊的全局 B-MAC 地址，一个用于 Root，另一个用于 Leaf，并在 MAC Advertisement 路由中标记 Leaf。这些 B-MAC 地址用作源自单宿主网段的流量的源地址。用于指示叶子站点的 B-MAC 地址对于单宿主和多宿主段可以相同。

5.1、 已知单播流量

对于已知的单播流量，PE 执行入口过滤：在入口 PE 上，客户/客户端 MAC (C-MAC) [RFC7623] 目标地址查找产生，除了目标 B-MAC 地址和转发邻接，一个标志指示目标B-MAC 是与Root 站点还是Leaf 站点相关联。Ingress PE 也检查始发站点的状态；如果两者都是叶子，则不转发数据包。

5.2、 BUM 流量

对于 BUM 流量，PE 必须进行出口过滤。当 PE 收到 EVPN MAC/IP 通告路由（将用作 BUM 流量的源 B-MAC）时，它更新其出口过滤（基于源 B-MAC 地址）如下：

- 如果EVPN MAC/IP Advertisement 路由表明通告的B-MAC 是Leaf，并且本地ES 也是Leaf，则将源B-MAC 地址添加到其用于出口过滤的B-MAC 列表中（即阻止来自该 B-MAC 地址的流量）。否则，不更新 B-MAC 过滤列表。

- 如果 EVPN MAC/IP Advertisement 路由指示通告的 B-MAC 已将其指定从 Leaf 更改为 Root，并且本地 ES 是 Leaf，则从 B-MAC 列表中删除源 B-MAC 地址对应于用于出口过滤的本地 ES（即，解除来自该 B-MAC 地址的流量的阻塞）。

当出口 PE 收到数据包时，它会检查 B-MAC 源地址以检查它是否应该过滤或转发该帧。请注意，这使用与 [RFC7623] 的第 6.2.1.3 节中描述的水平分割过滤相同的过滤逻辑，并且不需要数据平面中的任何额外标志。

正如在第 4.2 节中一样，PE 将给定网桥域的所有叶子 ES 放置在单个水平分割组中，以防止叶子段之间的 PE 内转发。这种水平分割功能适用于 BUM 流量以及已知的单播流量。

5.3、 没有 MAC 学习的 E-Tree

在感兴趣的流量只是组播和/或广播的场景中，实现E-Tree服务的PE不需要做任何MAC学习。在这种情况下，必须对出口 PE 进行过滤。对于 PBB-EVPN，此类流量的处理按照第 5.2 节进行，无需 PBB-EVPN PE（在入口和出口处）的 I 组件（C 桥表）中的 C-MAC 学习（在数据平面中） PE）。

6、 BGP 编码

本文档为 EVPN 定义了一个新的 BGP 扩展团体字。

6.1、 E-Tree 扩展团体字

这个扩展团体字是一个新的可传递扩展团体字[RFC4360]，其类型字段值为 0x06（EVPN），子类型为 0x05。它用于已知单播和 BUM 流量的叶子指示。它表明该帧来自叶子站点。

E-Tree 扩展团体字被编码为 8 个八位字节的值，如下所示：

图 4：E-Tree 扩展团体字

标志字段具有以下格式：

本文档定义了以下标志：

+ 叶子指示 (Leaf-Indication，L)

值为 1 表示叶子 AC/站点。其余的标志位是保留的，应设置为零。

当这个扩展团体字与 MAC/IP 通告路由（对于已知的单播流量）一起按照第 4.1 节进行通告时，叶子指示标志必须设置为 1，并且叶子标签应该设置为 0。接收 PE 必须忽略 Leaf 标签，只处理 Leaf-Indication 标志。与 MAC/IP 通告路由一起发送时，叶子指示标志的零值无效，应记录错误。

当这个扩展团体字与 BUM 流量的 EAD-ES 路由（ESI 为零）一起被通告时，根据第 4.2.1 和 4.2.3 节在处置 PE 上启用出口过滤，叶子标签必须设置为有效的 MPLS标签（即非保留的、分配的 MPLS 标签 [RFC3032]）和叶子指示标志应该设置为零。20 位 MPLS 标签的值编码在 Leaf 标签字段的高 20 位中。接收 PE 必须忽略 Leaf-Indication 标志。与 EAD-ES 路由一起发送的无效 MPLS 标签应被忽略并记录为错误。

保留位应该由发送器设置为零，并且必须被接收器忽略。

6.2、 PMSI 隧道属性

[RFC6514]定义了PMSI隧道属性，它是一个可选的传递属性，格式如下：

表 1：PMSI 隧道属性

本文档通过在隧道类型字段中引入新的“复合隧道”位并将 MPLS 标签添加到 PMSI 隧道属性的隧道标识符字段来定义新的复合隧道类型，如下详述。所有其他字段保持在 [RFC6514] 中的定义。复合隧道类型由根 PE 通告，以同时指示 BUM 流量在发送方向上的非入口复制隧道（例如，P2MP 隧道）和接收方向上的入口复制隧道。

当需要接收方入口复制标签时，隧道类型字段的高位（复合隧道位）被设置，而其余的低七位指示隧道类型（对于现有的隧道类型）。当这个复合隧道位被设置时，“隧道标识符”字段以三个八位字节的标签开始，后跟传输隧道的实际隧道标识符。不理解高位新含义的 PE 将隧道类型视为未定义的隧道类型，并将 PMSI 隧道属性视为格式错误的属性 [RFC6514]。这就是为什么在隧道类型字段而不是标志字段中分配复合隧道位的原因。对于了解高阶新含义的PE，如果在发送BUM 流量时需要Ingress Replication，则PE 在发送BUM 流量时将使用Tunnel Identifier 字段中的标签。

将复合隧道位用于隧道类型 0x00“无隧道信息存在”和 0x06“入口复制”是无效的。收到带有此类信息的 PMSI 隧道属性的 PE 认为其格式错误，并且它应该将此更新视为根据 [RFC6514] 的第 6 节已撤消此更新中包含的所有路由。

7、 安全考虑

由于本文档使用 [RFC7432] 和 [RFC7623] 的 EVPN 结构，因此这些文档中的相同安全考虑也适用于此处。此外，本文档通过允许网络运营商/服务提供商将 EVPN 实例的站点（或 AC）指定为“根”或“叶子”，从而防止“叶子”站点之间的任何流量交换，提供了额外的安全检查该 VPN 通过对已知单播流量的入口过滤和对 BUM 流量的出口过滤。由于（默认情况下和为了向后兼容）没有叶子指定的 AC 被认为是根 AC，为了避免叶子 AC 之间的任何流量交换，运营商应该为 AC 配置适当的角色（叶子或根）之前激活 AC。

8、 IANA 考虑

IANA 在 [RFC7153] 中定义的“EVPN 扩展团体字子类型”注册表中分配了子类型值 5，如下所示：

本文档创建了一个名为“E-Tree Flags”的八位字节注册表。新注册将通过 [RFC8126] 中定义的“RFC 要求”程序进行。初始注册如下：

8.1、 PMSI 隧道类型的注意事项

“边界网关协议 (Border Gateway Protocol，BGP) 参数”注册表中的“P-组播服务接口 (PMSI) 隧道类型”注册表已更新，以反映最高有效位作为“复合隧道”位的使用（参见第 6.2 节） .

为此，本文档通过更改先前未分配的值（即 0x08 - 0xFA）来更新 [RFC7385]，如下所示：

值 0x08-0x7A 的分配策略是根据 IETF 审查 [RFC8126]。“实验性”的范围已扩展为包括先前分配的范围 0xFB-0xFE 和新的范围 0x7B-0x7E。不分配这些范围内的值。本文档中保留值 0x7F，它是 (0xFF) 的镜像。

9、 参考文献

9.1、 规范参考

[MEF6.1] MEF Forum, "Ethernet Services Definitions - Phase 2", MEF 6.1, April 2008, <https://mef.net/PDF_Documents/technical-specifications/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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.

9.2、 参考资料

[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.
[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.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.
[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>.
[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>.

附录 A、 每个 E-Tree 服务实例的多个桥接表

当给定 PE 上的两个 MAC-VRF（每个 VLAN 两个网桥表）用于 E-Tree 服务（一个用于根 AC，另一个用于叶子 AC）时，数据平面路径中可能会出现以下复杂情况。

为每个 VLAN 维护两个 MAC-VRF（两个网桥表）（当该 VLAN 存在叶子和根 AC 时）将需要在每个方向上的每个 MAC 地址执行两次查找，以防丢失，或者需要重复许多 MAC属于同一个 VLAN（同一个 E-Tree 实例）的两个网桥表之间的地址。除非进行两次查找，否则本地学习的和远程学习的 MAC 地址都需要重复 MAC 地址。从Leaf AC本地学习到的MAC地址需要复制到根桥表中，从Root AC本地学习到的MAC地址需要复制到Leaf桥表中。从根 AC 远程学习的 MAC 地址需要复制到根和叶子桥表中。由于与数据平面实施额外的 MAC 查找或 MAC 条目的重复相关的潜在低效率，在某些平台中，如果没有数据平面性能低效，则认为此选项无法实施；因此，本文档介绍了第 3.2 节中所述和第 4.1 节中详述的着色。

致谢

我们要感谢 Eric Rosen、Jeffrey Zhang、Wen Lin、Aldrin Issac、Wim Henderickx、Dennis Cai 和 Antoni Przygienda 的宝贵意见和贡献。作者还要感谢 Thomas Morin 对本文档的指导和提供的宝贵意见。