Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 7623 S. Salam
Category: Standards Track Cisco
ISSN: 2070-1721 N. Bitar
Verizon
A. Isaac
Juniper
W. Henderickx
Alcatel-Lucent
September 2015
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 7623 S. Salam
Category: Standards Track Cisco
ISSN: 2070-1721 N. Bitar
Verizon
A. Isaac
Juniper
W. Henderickx
Alcatel-Lucent
September 2015
Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
提供商主干桥接与以太网VPN（PBB-EVPN）相结合
Abstract
摘要
This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.
本文档讨论了如何将以太网提供商主干桥接（PBB）与以太网VPN（EVPN）相结合，以便通过提供商主干MAC（B-MAC）地址聚合客户/客户MAC（C-MAC）地址来减少BGP MAC广告路由的数量，使用C-MAC聚合提供客户MAC地址移动性，将C-MAC学习的范围仅限于活动流，提供每个站点的策略，并避免拓扑更改时C-MAC地址刷新。组合解决方案称为PBB-EVPN。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7623.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7623.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Requirements ....................................................4
3.1. MAC Advertisement Route Scalability ........................5
3.2. C-MAC Mobility Independent of B-MAC Advertisements .........5
3.3. C-MAC Address Learning and Confinement .....................5
3.4. Per-Site Policy Support ....................................6
3.5. No C-MAC Address Flushing for All-Active Multihoming .......6
4. Solution Overview ...............................................6
5. BGP Encoding ....................................................7
5.1. Ethernet Auto-Discovery Route ..............................7
5.2. MAC/IP Advertisement Route .................................7
5.3. Inclusive Multicast Ethernet Tag Route .....................8
5.4. Ethernet Segment Route .....................................8
5.5. ESI Label Extended Community ...............................8
5.6. ES-Import Route Target .....................................9
5.7. MAC Mobility Extended Community ............................9
5.8. Default Gateway Extended Community .........................9
6. Operation .......................................................9
6.1. MAC Address Distribution over Core .........................9
6.2. Device Multihoming .........................................9
6.2.1. Flow-Based Load-Balancing ...........................9
6.2.1.1. PE B-MAC Address Assignment ...............10
6.2.1.2. Automating B-MAC Address Assignment .......11
6.2.1.3. Split Horizon and Designated
Forwarder Election ........................12
6.2.2. Load-Balancing based on I-SID ......................12
6.2.2.1. PE B-MAC Address Assignment ...............12
6.2.2.2. Split Horizon and Designated
Forwarder Election ........................13
6.2.2.3. Handling Failure Scenarios ................13
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Requirements ....................................................4
3.1. MAC Advertisement Route Scalability ........................5
3.2. C-MAC Mobility Independent of B-MAC Advertisements .........5
3.3. C-MAC Address Learning and Confinement .....................5
3.4. Per-Site Policy Support ....................................6
3.5. No C-MAC Address Flushing for All-Active Multihoming .......6
4. Solution Overview ...............................................6
5. BGP Encoding ....................................................7
5.1. Ethernet Auto-Discovery Route ..............................7
5.2. MAC/IP Advertisement Route .................................7
5.3. Inclusive Multicast Ethernet Tag Route .....................8
5.4. Ethernet Segment Route .....................................8
5.5. ESI Label Extended Community ...............................8
5.6. ES-Import Route Target .....................................9
5.7. MAC Mobility Extended Community ............................9
5.8. Default Gateway Extended Community .........................9
6. Operation .......................................................9
6.1. MAC Address Distribution over Core .........................9
6.2. Device Multihoming .........................................9
6.2.1. Flow-Based Load-Balancing ...........................9
6.2.1.1. PE B-MAC Address Assignment ...............10
6.2.1.2. Automating B-MAC Address Assignment .......11
6.2.1.3. Split Horizon and Designated
Forwarder Election ........................12
6.2.2. Load-Balancing based on I-SID ......................12
6.2.2.1. PE B-MAC Address Assignment ...............12
6.2.2.2. Split Horizon and Designated
Forwarder Election ........................13
6.2.2.3. Handling Failure Scenarios ................13
6.3. Network Multihoming .......................................14
6.4. Frame Forwarding ..........................................14
6.4.1. Unicast ............................................15
6.4.2. Multicast/Broadcast ................................15
6.5. MPLS Encapsulation of PBB Frames ..........................16
7. Minimizing ARP/ND Broadcast ....................................16
8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp .............17
8.1. B-MAC Address Assignment ..................................17
8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement .......17
8.3. Operation: ................................................17
9. Solution Advantages ............................................18
9.1. MAC Advertisement Route Scalability .......................18
9.2. C-MAC Mobility Independent of B-MAC Advertisements ........18
9.3. C-MAC Address Learning and Confinement ....................19
9.4. Seamless Interworking with 802.1aq Access Networks ........19
9.5. Per-Site Policy Support ...................................20
9.6. No C-MAC Address Flushing for All-Active Multihoming ......20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................20
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................23
6.3. Network Multihoming .......................................14
6.4. Frame Forwarding ..........................................14
6.4.1. Unicast ............................................15
6.4.2. Multicast/Broadcast ................................15
6.5. MPLS Encapsulation of PBB Frames ..........................16
7. Minimizing ARP/ND Broadcast ....................................16
8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp .............17
8.1. B-MAC Address Assignment ..................................17
8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement .......17
8.3. Operation: ................................................17
9. Solution Advantages ............................................18
9.1. MAC Advertisement Route Scalability .......................18
9.2. C-MAC Mobility Independent of B-MAC Advertisements ........18
9.3. C-MAC Address Learning and Confinement ....................19
9.4. Seamless Interworking with 802.1aq Access Networks ........19
9.5. Per-Site Policy Support ...................................20
9.6. No C-MAC Address Flushing for All-Active Multihoming ......20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................20
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................23
[RFC7432] introduces a solution for multipoint Layer 2 Virtual Private Network (L2VPN) services, with advanced multihoming capabilities, using BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. [PBB] defines an architecture for Ethernet Provider Backbone Bridging (PBB), where MAC tunneling is employed to improve service instance and MAC address scalability in Ethernet as well as VPLS networks [RFC7080].
[RFC7432]介绍了一种多点第2层虚拟专用网络（L2VPN）服务解决方案，该解决方案具有高级多主功能，使用BGP在核心MPLS/IP网络上分发客户/客户端MAC地址可达性信息。[PBB]定义了以太网提供商主干桥接（PBB）的体系结构，其中MAC隧道用于改进以太网以及VPLS网络中的服务实例和MAC地址可伸缩性[RFC7080]。
In this document, we discuss how PBB can be combined with EVPN in order to: reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.
在本文档中，我们讨论了PBB如何与EVPN相结合，以便：通过提供商主干MAC（B-MAC）地址聚合客户/客户MAC（C-MAC）地址，减少BGP MAC广告路由的数量，使用C-MAC聚合提供客户MAC地址移动性，将C-MAC学习的范围仅限于活动流，提供每个站点的策略，并避免拓扑更改时C-MAC地址刷新。组合解决方案称为PBB-EVPN。
ARP: Address Resolution Protocol BEB: Backbone Edge Bridge B-MAC: Backbone MAC B-VID: Backbone VLAN ID CE: Customer Edge C-MAC: Customer/Client MAC ES: Ethernet Segment ESI: Ethernet Segment Identifier EVI: EVPN Instance EVPN: Ethernet VPN I-SID: Service Instance Identifier (24 bits and global within a PBB network see [RFC7080]) LSP: Label Switched Path MP2MP: Multipoint to Multipoint MP2P: Multipoint to Point NA: Neighbor Advertisement ND: Neighbor Discovery P2MP: Point to Multipoint P2P: Point to Point PBB: Provider Backbone Bridge PE: Provider Edge RT: Route Target VPLS: Virtual Private LAN Service
ARP:地址解析协议BEB:主干边缘网桥B-MAC:主干MAC B-VID:主干VLAN ID CE:客户边缘C-MAC:客户/客户MAC ES:以太网段ESI:以太网段标识符EVI:EVPN实例EVPN:以太网VPN I-SID:服务实例标识符（PBB网络内24位和全局请参阅[RFC7080]）LSP:标签交换路径MP2MP:多点对多点MP2P:多点对点NA:邻居公告ND:邻居发现P2MP:点对多点P2P:点对点PBB:提供商主干网桥PE:提供商边缘RT:路由目标VPLS:虚拟专用LAN服务
Single-Active Redundancy Mode: When only a single PE, among a group of PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode.
单主动冗余模式：当连接到以太网段的一组PE中只有一个PE被允许向/从该以太网段转发流量时，以太网段被定义为在单主动冗余模式下运行。
All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode.
所有主动冗余模式：当允许连接到以太网段的所有PE向/从该以太网段转发流量时，以太网段被定义为在所有主动冗余模式下运行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
The requirements for PBB-EVPN include all the requirements for EVPN that were described in [RFC7209], in addition to the following:
PBB-EVPN的要求包括[RFC7209]中描述的所有EVPN要求，以及以下要求：
In typical operation, an EVPN PE sends a BGP MAC Advertisement route per C-MAC address. In certain applications, this poses scalability challenges, as is the case in data center interconnect (DCI) scenarios where the number of virtual machines (VMs), and hence the number of C-MAC addresses, can be in the millions. In such scenarios, it is required to reduce the number of BGP MAC Advertisement routes by relying on a 'MAC summarization' scheme, as is provided by PBB.
在典型操作中，EVPN PE根据C-MAC地址发送BGP MAC广告路由。在某些应用程序中，这会带来可扩展性挑战，数据中心互连（DCI）场景中的情况就是如此，其中虚拟机（VM）的数量以及C-MAC地址的数量可能达到数百万。在这种情况下，需要根据PBB提供的“MAC摘要”方案来减少BGP MAC广告路由的数量。
Certain applications, such as virtual machine mobility, require support for fast C-MAC address mobility. For these applications, when using EVPN, the virtual machine MAC address needs to be transmitted in BGP MAC Advertisement route. Otherwise, traffic would be forwarded to the wrong segment when a virtual machine moves from one ES to another. This means MAC address prefixes cannot be used in data center applications.
某些应用程序（如虚拟机移动性）需要支持快速C-MAC地址移动性。对于这些应用，当使用EVPN时，需要在BGP MAC广告路由中传输虚拟机MAC地址。否则，当虚拟机从一个ES移动到另一个ES时，流量将被转发到错误的段。这意味着数据中心应用程序中不能使用MAC地址前缀。
In order to support C-MAC address mobility, while retaining the scalability benefits of MAC summarization, PBB technology is used. It defines a B-MAC address space that is independent of the C-MAC address space, and aggregates C-MAC addresses via a single B-MAC address.
为了支持C-MAC地址移动性，同时保留MAC摘要的可扩展性优势，使用了PBB技术。它定义独立于C-MAC地址空间的B-MAC地址空间，并通过单个B-MAC地址聚合C-MAC地址。
In EVPN, all the PE nodes participating in the same EVPN instance are exposed to all the C-MAC addresses learned by any one of these PE nodes because a C-MAC learned by one of the PE nodes is advertised in BGP to other PE nodes in that EVPN instance. This is the case even if some of the PE nodes for that EVPN instance are not involved in forwarding traffic to, or from, these C-MAC addresses. Even if an implementation does not install hardware forwarding entries for C-MAC addresses that are not part of active traffic flows on that PE, the device memory is still consumed by keeping record of the C-MAC addresses in the routing information base (RIB) table. In network applications with millions of C-MAC addresses, this introduces a non-trivial waste of PE resources. As such, it is required to confine the scope of visibility of C-MAC addresses to only those PE nodes that are actively involved in forwarding traffic to, or from, these addresses.
在EVPN中，参与同一EVPN实例的所有PE节点暴露于由这些PE节点中的任何一个学习的所有C-MAC地址，因为由其中一个PE节点学习的C-MAC在BGP中通告给该EVPN实例中的其他PE节点。即使该EVPN实例的一些PE节点不参与向这些C-MAC地址或从这些C-MAC地址转发通信量，情况也是如此。即使实现没有为不属于该PE上的活动业务流的C-MAC地址安装硬件转发条目，设备内存仍然通过在路由信息库（RIB）表中保留C-MAC地址的记录来消耗。在具有数百万个C-MAC地址的网络应用程序中，这会造成PE资源的极大浪费。因此，需要将C-MAC地址的可视范围仅限于那些积极参与向这些地址或从这些地址转发流量的PE节点。
In many applications, it is required to be able to enforce connectivity policy rules at the granularity of a site (or segment). This includes the ability to control which PE nodes in the network can forward traffic to, or from, a given site. Both EVPN and PBB-EVPN are capable of providing this granularity of policy control. In the case where the policy needs to be at the granularity of per C-MAC address, then the C-MAC address should be learned in the control plane (in BGP) per [RFC7432].
在许多应用程序中，需要能够在站点（或段）的粒度上实施连接策略规则。这包括控制网络中哪些PE节点可以将流量转发到给定站点或从给定站点转发流量的能力。EVPN和PBB-EVPN都能够提供这种策略控制粒度。如果策略的粒度需要为每个C-MAC地址，则应按照[RFC7432]在控制平面（在BGP中）中学习C-MAC地址。
Just as in [RFC7432], it is required to avoid C-MAC address flushing upon link, port, or node failure for All-Active multihomed segments.
正如在[RFC7432]中一样，需要避免在所有活动多址段的链路、端口或节点故障时刷新C-MAC地址。
The solution involves incorporating IEEE Backbone Edge Bridge (BEB) functionality on the EVPN PE nodes similar to PBB-VPLS, where BEB functionality is incorporated in the VPLS PE nodes. The PE devices would then receive 802.1Q Ethernet frames from their attachment circuits, encapsulate them in the PBB header, and forward the frames over the IP/MPLS core. On the egress EVPN PE, the PBB header is removed following the MPLS disposition, and the original 802.1Q Ethernet frame is delivered to the customer equipment.
该解决方案涉及在EVPN PE节点上合并IEEE主干边缘网桥（BEB）功能，类似于PBB-VPLS，其中BEB功能合并在VPLS PE节点中。然后，PE设备将从其连接电路接收802.1Q以太网帧，将其封装在PBB报头中，并通过IP/MPLS核心转发帧。在出口EVPN-PE上，在MPLS配置之后移除PBB报头，并且原始802.1Q以太网帧被传送到客户设备。
BEB +--------------+ BEB
|| | | ||
\/ | | \/
+----+ AC1 +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+
\ | |
AC2\ +----+ | |
\| | | |
| PE2| | |
+----+ | |
/\ +--------------+
||
BEB
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
BEB +--------------+ BEB
|| | | ||
\/ | | \/
+----+ AC1 +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+
\ | |
AC2\ +----+ | |
\| | | |
| PE2| | |
+----+ | |
/\ +--------------+
||
BEB
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 1: PBB-EVPN Network
图1:PBB-EVPN网络
The PE nodes perform the following functions:
PE节点执行以下功能：
- Learn customer/client MAC addresses (C-MACs) over the attachment circuits in the data plane, per normal bridge operation.
- 按照正常网桥操作，通过数据平面中的连接电路了解客户/客户机MAC地址（C-MAC）。
- Learn remote C-MAC to B-MAC bindings in the data plane for traffic received from the core per the bridging operation described in [PBB].
- 根据[PBB]中描述的桥接操作，了解数据平面中从核心接收的通信量的远程C-MAC到B-MAC绑定。
- Advertise local B-MAC address reachability information in BGP to all other PE nodes in the same set of service instances. Note that every PE has a set of B-MAC addresses that uniquely identifies the device. B-MAC address assignment is described in details in Section 6.2.2.
- 向同一组服务实例中的所有其他PE节点公布BGP中的本地B-MAC地址可达性信息。请注意，每个PE都有一组唯一标识设备的B-MAC地址。B-MAC地址分配详见第6.2.2节。
- Build a forwarding table from remote BGP advertisements received associating remote B-MAC addresses with remote PE IP addresses and the associated MPLS label(s).
- 从接收到的远程BGP播发建立转发表，该播发将远程B-MAC地址与远程PE IP地址和关联的MPLS标签相关联。
PBB-EVPN leverages the same BGP routes and attributes defined in [RFC7432], adapted as described below.
PBB-EVPN利用[RFC7432]中定义的相同BGP路由和属性，如下所述进行调整。
This route and all of its associated modes are not needed in PBB-EVPN because PBB encapsulation provides the required level of indirection for C-MAC addresses -- i.e., an ES can be represented by a B-MAC address for the purpose of data-plane learning/forwarding.
PBB-EVPN中不需要该路由及其所有相关模式，因为PBB封装为C-MAC地址提供了所需的间接寻址级别——即，为了数据平面学习/转发的目的，ES可以由B-MAC地址表示。
The receiving PE knows that it need not wait for the receipt of the Ethernet A-D (auto-discovery) route for route resolution by means of the reserved ESI encoded in the MAC Advertisement route: the ESI values of 0 and MAX-ESI indicate that the receiving PE can resolve the path without an Ethernet A-D route.
接收PE知道，它不需要等待接收到以太网A-D（自动发现）路由来通过MAC广告路由中编码的保留ESI进行路由解析：ESI值0和MAX-ESI指示接收PE可以解析没有以太网A-D路由的路径。
The EVPN MAC/IP Advertisement route is used to distribute B-MAC addresses of the PE nodes instead of the C-MAC addresses of end-stations/hosts. This is because the C-MAC addresses are learned in the data plane for traffic arriving from the core. The MAC Advertisement route is encoded as follows:
EVPN MAC/IP播发路由用于分配PE节点的B-MAC地址，而不是终端站/主机的C-MAC地址。这是因为C-MAC地址是在数据平面中为来自核心的通信量学习的。MAC播发路由编码如下：
- The MAC address field contains the B-MAC address.
- MAC地址字段包含B-MAC地址。
- The Ethernet Tag field is set to 0.
- 以太网标记字段设置为0。
- The Ethernet Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load-balancing) or to MAX-ESI (for multihomed segments with per-flow load-balancing). All other values are not permitted.
- 以太网段标识符字段必须设置为0（对于具有per-I-SID负载平衡的单宿段或多宿段）或MAX-ESI（对于具有每流负载平衡的多宿段）。不允许使用所有其他值。
- All other fields are set as defined in [RFC7432].
- 所有其他字段均按照[RFC7432]中的定义进行设置。
This route is tagged with the RT corresponding to its EVI. This EVI is analogous to a B-VID.
该路线标记有与其EVI对应的RT。该EVI类似于B-VID。
This route is used for multicast pruning per I-SID. It is used for auto-discovery of PEs participating in a given I-SID so that a multicast tunnel (MP2P, P2P, P2MP, or MP2MP LSP) can be set up for that I-SID. [RFC7080] uses multicast pruning per I-SID based on [MMRP], which is a soft-state protocol. The advantages of multicast pruning using this BGP route over [MMRP] are that a) it scales very well for a large number of PEs and b) it works with any type of LSP (MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P pseudowires. The Inclusive Multicast Ethernet Tag route is encoded as follows:
此路由用于根据I-SID进行多播修剪。它用于自动发现参与给定I-SID的PE，以便为该I-SID设置多播隧道（MP2P、P2P、P2MP或MP2MP LSP）。[RFC7080]使用基于[MMRP]的每个I-SID的多播修剪，这是一种软状态协议。与[MMRP]相比，使用此BGP路由进行多播修剪的优势在于：a）它可以很好地扩展大量PE；b）它可以与任何类型的LSP（MP2P、P2P、P2MP或MP2MP）一起工作；然而，[MMRP]仅在P2P伪线上工作。包容性多播以太网标记路由编码如下：
- The Ethernet Tag field is set with the appropriate I-SID value.
- Ethernet标记字段设置了适当的I-SID值。
- All other fields are set as defined in [RFC7432].
- 所有其他字段均按照[RFC7432]中的定义进行设置。
This route is tagged with an RT. This RT SHOULD be set to a value corresponding to its EVI (which is analogous to a B-VID). The RT for this route MAY also be auto-derived from the corresponding Ethernet Tag (I-SID) based on the procedure specified in Section 5.1.2.1 of [OVERLAY].
此路线用RT标记。此RT应设置为与其EVI（类似于B-VID）对应的值。根据[OVERLAY]第5.1.2.1节中规定的程序，该路由的RT也可以从相应的以太网标签（I-SID）自动导出。
This route is used for auto-discovery of PEs belonging to a given redundancy group (e.g., attached to a given ES) per [RFC7432].
此路由用于根据[RFC7432]自动发现属于给定冗余组（例如，连接到给定ES）的PE。
This extended community is not used in PBB-EVPN. In [RFC7432], this extended community is used along with the Ethernet A-D route to advertise an MPLS label for the purpose of split-horizon filtering. Since in PBB-EVPN, the split-horizon filtering is performed natively using B-MAC source address, there is no need for this extended community.
PBB-EVPN中未使用此扩展社区。在[RFC7432]中，此扩展社区与以太网A-D路由一起用于公布MPLS标签，以便进行拆分地平线过滤。由于在PBB-EVPN中，分割地平线滤波是使用B-MAC源地址本机执行的，因此不需要这个扩展社区。
This RT is used as defined in [RFC7432].
按照[RFC7432]中的定义使用此RT。
This extended community is defined in [RFC7432] and it is used with a MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is tagged with the RT corresponding to its EVI (which is analogous to a B-VID). When this extended community is used along with a B-MAC route in PBB-EVPN, it indicates that all C-MAC addresses associated with that B-MAC address across all corresponding I-SIDs must be flushed.
该扩展社区在[RFC7432]中定义，并与MAC路由（PBB-EVPN情况下的B-MAC路由）一起使用。B-MAC路由使用与其EVI（类似于B-VID）对应的RT进行标记。当此扩展社区与PBB-EVPN中的B-MAC路由一起使用时，它表示必须刷新所有对应I-SID中与该B-MAC地址关联的所有C-MAC地址。
When a PE first advertises a B-MAC, it MAY advertise it with this extended community where the sticky/static flag is set to 1 and the sequence number is set to zero. In such cases where the PE wants to signal the stickiness of a B-MAC, then when a flush indication is needed, the PE advertises the B-MAC along with the MAC Mobility extended community where the sticky/static flag remains set and the sequence number is incremented.
当PE第一次播发B-MAC时，它可以使用该扩展社区播发它，其中粘性/静态标志设置为1，序列号设置为零。在PE想要发出B-MAC粘性的信号的情况下，然后当需要刷新指示时，PE与MAC移动性扩展社区一起播发B-MAC，其中粘性/静态标志保持设置并且序列号递增。
This extended community is not used in PBB-EVPN.
PBB-EVPN中未使用此扩展社区。
This section discusses the operation of PBB-EVPN, specifically in areas where it differs from [RFC7432].
本节讨论PBB-EVPN的操作，特别是在与[RFC7432]不同的领域。
In PBB-EVPN, host MAC addresses (i.e., C-MAC addresses) need not be distributed in BGP. Rather, every PE independently learns the C-MAC addresses in the data plane via normal bridging operation. Every PE has a set of one or more unicast B-MAC addresses associated with it, and those are the addresses distributed over the core in MAC Advertisement routes.
在PBB-EVPN中，主机MAC地址（即C-MAC地址）不需要分布在BGP中。相反，每个PE通过正常桥接操作独立地学习数据平面中的C-MAC地址。每个PE都有一组与之关联的一个或多个单播B-MAC地址，这些地址分布在MAC广告路由中的核心上。
This section describes the procedures for supporting device multihoming in an All-Active redundancy mode (i.e., flow-based load-balancing).
本节描述了在全主动冗余模式（即基于流的负载平衡）下支持设备多主的过程。
In [PBB], every BEB is uniquely identified by one or more B-MAC addresses. These addresses are usually locally administered by the service provider. For PBB-EVPN, the choice of B-MAC address(es) for the PE nodes must be examined carefully as it has implications on the proper operation of multihoming. In particular, for the scenario where a CE is multihomed to a number of PE nodes with All-Active redundancy mode, a given C-MAC address would be reachable via multiple PE nodes concurrently. Given that any given remote PE will bind the C-MAC address to a single B-MAC address, then the various PE nodes connected to the same CE must share the same B-MAC address. Otherwise, the MAC address table of the remote PE nodes will keep oscillating between the B-MAC addresses of the various PE devices. For example, consider the network of Figure 1, and assume that PE1 has B-MAC address BM1 and PE2 has B-MAC address BM2. Also, assume that both links from CE1 to the PE nodes are part of the same Ethernet link aggregation group. If BM1 is not equal to BM2, the consequence is that the MAC address table on PE3 will keep oscillating such that the C-MAC address M1 of CE1 would flip-flop between BM1 or BM2, depending on the load-balancing decision on CE1 for traffic destined to the core.
在[PBB]中，每个BEB由一个或多个B-MAC地址唯一标识。这些地址通常由服务提供商在本地管理。对于PBB-EVPN，必须仔细检查PE节点的B-MAC地址的选择，因为它对多归属的正确操作有影响。特别地，对于CE以所有活动冗余模式多宿到多个PE节点的场景，给定的C-MAC地址将可通过多个PE节点并发地到达。假设任何给定的远程PE将C-MAC地址绑定到单个B-MAC地址，那么连接到同一CE的各个PE节点必须共享相同的B-MAC地址。否则，远程PE节点的MAC地址表将在各种PE设备的B-MAC地址之间保持振荡。例如，考虑图1的网络，并假设PE1具有B-MAC地址BM1和PE2具有B-MAC地址BM2。此外，假设从CE1到PE节点的两条链路都是同一以太网链路聚合组的一部分。如果BM1不等于BM2，则结果是PE3上的MAC地址表将保持振荡，从而CE1的C-MAC地址M1将在BM1或BM2之间切换，这取决于CE1上针对发送到核心的流量的负载平衡决策。
Considering that there could be multiple sites (e.g., CEs) that are multihomed to the same set of PE nodes, then it is required for all the PE devices in a redundancy group to have a unique B-MAC address per site. This way, it is possible to achieve fast convergence in the case where a link or port failure impacts the attachment circuit connecting a single site to a given PE.
考虑到可能有多个站点（例如，CE）多宿于同一组PE节点，则冗余组中的所有PE设备需要每个站点具有唯一的B-MAC地址。这样，在链路或端口故障影响连接单个站点到给定PE的连接电路的情况下，可以实现快速收敛。
+---------+
+-------+ PE1 | IP/MPLS |
/ | |
CE1 | Network | PEr
M1 \ | |
+-------+ PE2 | |
/-------+ | |
/ | |
CE2 | |
M2 \ | |
\ | |
+------+ PE3 +---------+
+---------+
+-------+ PE1 | IP/MPLS |
/ | |
CE1 | Network | PEr
M1 \ | |
+-------+ PE2 | |
/-------+ | |
/ | |
CE2 | |
M2 \ | |
\ | |
+------+ PE3 +---------+
Figure 2: B-MAC Address Assignment
图2:B-MAC地址分配
In the example network shown in Figure 2 above, two sites corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3, respectively. Assume that BM1 is the B-MAC used for the site
在上面图2所示的示例网络中，与CE1和CE2相对应的两个站点分别双宿于PE1/PE2和PE2/PE3。假设BM1是用于站点的B-MAC
corresponding to CE1. Similarly, BM2 is the B-MAC used for the site corresponding to CE2. On PE1, a single B-MAC address (BM1) is required for the site corresponding to CE1. On PE2, two B-MAC addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a single B-MAC address (BM2) is required for the site corresponding to CE2. All three PE nodes would advertise their respective B-MAC addresses in BGP using the MAC Advertisement routes defined in [RFC7432]. The remote PE, PEr, would learn via BGP that BM1 is reachable via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3. Furthermore, PEr establishes, via the PBB bridge learning procedure, that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via BM2. As a result, PEr can load-balance traffic destined to M1 between PE1 and PE2, as well as traffic destined to M2 between both PE2 and PE3. In the case of a failure that causes, for example, CE1 to be isolated from PE1, the latter can withdraw the route it has advertised for BM1. This way, PEr would update its path list for BM1 and will send all traffic destined to M1 over to PE2 only.
对应于CE1。类似地，BM2是用于对应于CE2的站点的B-MAC。在PE1上，与CE1相对应的站点需要一个B-MAC地址（BM1）。在PE2上，需要两个B-MAC地址（BM1和BM2），每个站点一个。而在PE3上，对应于CE2的站点需要一个B-MAC地址（BM2）。所有三个PE节点将使用[RFC7432]中定义的MAC公布路由在BGP中公布各自的B-MAC地址。远程PE PEr将通过BGP得知BM1可通过PE1和PE2访问，而BM2可通过PE2和PE3访问。此外，PEr通过PBB桥学习过程确定C-MAC M1可通过BM1到达，而C-MAC M2可通过BM2到达。因此，PEr can可以在PE1和PE2之间平衡目的地为M1的流量，以及在PE2和PE3之间平衡目的地为M2的流量。例如，在导致CE1与PE1隔离的故障情况下，PE1可以撤回其为BM1播发的路由。这样，PEr将更新其BM1的路径列表，并将所有发送到M1的流量仅发送到PE2。
The PE B-MAC address used for single-homed or Single-Active sites can be automatically derived from the hardware (using for example the backplane's address and/or PE's reserved MAC pool ). However, the B-MAC address used for All-Active sites must be coordinated among the redundancy group members. To automate the assignment of this latter address, the PE can derive this B-MAC address from the MAC address portion of the CE's Link Aggregation Control Protocol (LACP) System Identifier by flipping the 'Locally Administered' bit of the CE's address. This guarantees the uniqueness of the B-MAC address within the network, and ensures that all PE nodes connected to the same All-Active CE use the same value for the B-MAC address.
用于单个主站点或单个活动站点的PE B-MAC地址可以从硬件自动派生（例如使用背板地址和/或PE的保留MAC池）。但是，用于所有活动站点的B-MAC地址必须在冗余组成员之间进行协调。为了自动分配后一个地址，PE可以通过翻转CE地址的“本地管理”位，从CE的链路聚合控制协议（LACP）系统标识符的MAC地址部分导出该B-MAC地址。这保证了网络中B-MAC地址的唯一性，并确保连接到相同的所有活动CE的所有PE节点使用相同的B-MAC地址值。
Note that with this automatic provisioning of the B-MAC address associated with All-Active CEs, it is not possible to support the uncommon scenario where a CE has multiple link bundles within the same LACP session towards the PE nodes, and the service involves hair-pinning traffic from one bundle to another. This is because the split-horizon filtering relies on B-MAC addresses rather than Site-ID Labels (as will be described in the next section). The operator must explicitly configure the B-MAC address for this fairly uncommon service scenario.
注意，通过与所有活动CE相关联的B-MAC地址的这种自动配置，不可能支持这样一种不常见的情况，即CE在同一LACP会话中有多个指向PE节点的链路捆绑包，并且服务涉及将流量从一个捆绑包固定到另一个捆绑包。这是因为拆分地平线过滤依赖于B-MAC地址，而不是站点ID标签（将在下一节中描述）。运营商必须为这种相当罕见的服务场景明确配置B-MAC地址。
Whenever a B-MAC address is provisioned on the PE, either manually or automatically (as an outcome of CE auto-discovery), the PE MUST transmit a MAC Advertisement route for the B-MAC address with a downstream assigned MPLS label that uniquely identifies that address
每当手动或自动（作为CE自动发现的结果）在PE上设置B-MAC地址时，PE必须为B-MAC地址发送MAC播发路由，该路由具有唯一标识该地址的下游分配MPLS标签
on the advertising PE. The route is tagged with the RTs of the associated EVIs as described above.
关于体育广告。如上所述，用相关EVI的RTs标记路线。
[RFC7432] relies on split-horizon filtering for a multi-homed ES,
where the ES label is used for egress filtering on the attachment
circuit in order to prevent forwarding loops. In PBB-EVPN, the B-MAC
source address can be used for the same purpose, as it uniquely
identifies the originating site of a given frame. As such, ES labels
are not used in PBB-EVPN, and the egress split-horizon filtering is
done based on the B-MAC source address. It is worth noting here that
[PBB] defines this B-MAC address-based filtering function as part of
the I-Component options; hence, no new functions are required to
support split-horizon filtering beyond what is already defined in
[PBB].
[RFC7432] relies on split-horizon filtering for a multi-homed ES,
where the ES label is used for egress filtering on the attachment
circuit in order to prevent forwarding loops. In PBB-EVPN, the B-MAC
source address can be used for the same purpose, as it uniquely
identifies the originating site of a given frame. As such, ES labels
are not used in PBB-EVPN, and the egress split-horizon filtering is
done based on the B-MAC source address. It is worth noting here that
[PBB] defines this B-MAC address-based filtering function as part of
the I-Component options; hence, no new functions are required to
support split-horizon filtering beyond what is already defined in
[PBB].
The Designated Forwarder (DF) election procedures are defined in [RFC7432].
[RFC7432]中定义了指定货运代理（DF）的选择程序。
This section describes the procedures for supporting device multihoming in a Single-Active redundancy mode with per-I-SID load-balancing.
本节描述了使用per-I-SID负载平衡在单个主动冗余模式下支持设备多主的过程。
In the case where per-I-SID load-balancing is desired among the PE nodes in a given redundancy group, multiple unicast B-MAC addresses are allocated per multihomed ES: Each PE connected to the multihomed segment is assigned a unique B-MAC. Every PE then advertises its B-MAC address using the BGP MAC Advertisement route. In this mode of operation, two B-MAC address-assignment models are possible:
在给定冗余组中的PE节点之间需要per-I-SID负载平衡的情况下，每个多址ES分配多个单播B-MAC地址：连接到多址段的每个PE分配一个唯一的B-MAC。然后，每个PE使用BGP MAC播发路由播发其B-MAC地址。在这种操作模式下，可以使用两种B-MAC地址分配模型：
- The PE may use a shared B-MAC address for all its single-homed segments and/or all its multi-homed Single-Active segments (e.g., segments operating in per-I-SID load-balancing mode).
- PE可对其所有单宿网段和/或其所有多宿单活动网段（例如，在per-I-SID负载平衡模式下运行的网段）使用共享B-MAC地址。
- The PE may use a dedicated B-MAC address for each ES operating with per-I-SID load-balancing mode.
- PE可以为每个以per-I-SID负载平衡模式运行的ES使用专用的B-MAC地址。
A PE implementation MAY choose to support either the shared B-MAC address model or the dedicated B-MAC address model without causing any interoperability issues. The advantage of the dedicated B-MAC over the shared B-MAC address for multi-homed Single-Active segments, is that when C-MAC flushing is needed, fewer C-MAC addresses are impacted. Furthermore, it gives the disposition PE the ability to
PE实现可以选择支持共享B-MAC地址模型或专用B-MAC地址模型，而不会导致任何互操作性问题。专用B-MAC相对于多主单活动段的共享B-MAC地址的优势在于，当需要C-MAC刷新时，受影响的C-MAC地址更少。此外，它使处置PE能够
avoid C-MAC destination address lookup even though source C-MAC learning is still required in the data plane. Its disadvantage is that there are additional B-MAC advertisements in BGP.
避免查找C-MAC目标地址，即使数据平面中仍然需要源C-MAC学习。其缺点是在BGP中存在额外的B-MAC广告。
A remote PE initially floods traffic to a destination C-MAC address, located in a given multihomed ES, to all the PE nodes configured with that I-SID. Then, when reply traffic arrives at the remote PE, it learns (in the data path) the B-MAC address and associated next-hop PE to use for said C-MAC address.
远程PE最初会将通信量发送到位于给定多址ES中的目标C-MAC地址，并发送到使用该I-SID配置的所有PE节点。然后，当应答业务到达远程PE时，它学习（在数据路径中）B-MAC地址和相关联的下一跳PE以用于所述C-MAC地址。
The procedures are similar to the flow-based load-balancing case, with the only difference being that the DF filtering must be applied to unicast as well as multicast traffic, and in both core-to-segment as well as segment-to-core directions.
这些过程类似于基于流的负载平衡情况，唯一的区别是DF过滤必须应用于单播和多播流量，以及核心到段以及段到核心的方向。
When a PE connected to a multihomed ES loses connectivity to the segment, due to link or port failure, it needs to notify the remote PEs to trigger C-MAC address flushing. This can be achieved in one of two ways, depending on the B-MAC assignment model:
当连接到多址ES的PE由于链路或端口故障而失去与网段的连接时，需要通知远程PE触发C-MAC地址刷新。这可以通过以下两种方式之一实现，具体取决于B-MAC分配模型：
- If the PE uses a shared B-MAC address for multiple Ethernet segments, then the C-MAC flushing is signaled by means of having the failed PE re-advertise the MAC Advertisement route for the associated B-MAC, tagged with the MAC Mobility extended community attribute. The value of the Counter field in that attribute must be incremented prior to advertisement. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn MAC route.
- 如果PE对多个以太网段使用共享B-MAC地址，则通过使失败的PE为相关联的B-MAC重新通告MAC通告路由（用MAC移动性扩展社区属性标记）来通知C-MAC刷新。该属性中计数器字段的值必须在播发之前递增。这会导致远程PE节点刷新与所讨论的B-MAC相关联的所有C-MAC地址。这是在映射到撤回的MAC路由的EVI的所有I-SID上完成的。
- If the PE uses a dedicated B-MAC address for each ES operating under per-I-SID load-balancing mode, the failed PE simply withdraws the B-MAC route previously advertised for that segment. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn MAC route.
- 如果PE为在per-I-SID负载平衡模式下运行的每个ES使用专用的B-MAC地址，则失败的PE只需退出先前为该段播发的B-MAC路由。这会导致远程PE节点刷新与所讨论的B-MAC相关联的所有C-MAC地址。这是在映射到撤回的MAC路由的EVI的所有I-SID上完成的。
When a PE connected to a multihomed ES fails (i.e., node failure) or when the PE becomes completely isolated from the EVPN network, the remote PEs will start purging the MAC Advertisement routes that were advertised by the failed PE. This is done either as an outcome of the remote PEs detecting that the BGP session to the failed PE has gone down, or by having a Route Reflector withdrawing all the routes that were advertised by the failed PE. The remote PEs, in this case,
当连接到多宿ES的PE出现故障（即节点故障）或PE与EVPN网络完全隔离时，远程PE将开始清除故障PE播发的MAC播发路由。这可以作为远程PE检测到与故障PE的BGP会话已中断的结果，也可以通过让路由反射器收回故障PE播发的所有路由来完成。远程PEs，在这种情况下，
will perform C-MAC address flushing as an outcome of the MAC Advertisement route withdrawals.
将执行C-MAC地址刷新，作为MAC广告路由撤回的结果。
For all failure scenarios (link/port failure, node failure, and PE node isolation), when the fault condition clears, the recovered PE re-advertises the associated ES route to other members of its redundancy group. This triggers the backup PE(s) in the redundancy group to block the I-SIDs for which the recovered PE is a DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address flush notification to the remote PEs by re-advertising the MAC Advertisement route for the associated B-MAC, with the MAC Mobility extended community attribute. The value of the Counter field in that attribute must be incremented prior to advertisement. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn/re-advertised MAC route.
对于所有故障场景（链路/端口故障、节点故障和PE节点隔离），当故障条件清除时，恢复的PE将相关ES路由重新播发到其冗余组的其他成员。这会触发冗余组中的备份PE，以阻止恢复的PE为DF的I-SID。当备份PE阻塞I-SID时，它会通过使用MAC移动扩展社区属性重新通告相关B-MAC的MAC通告路由，触发对远程PE的C-MAC地址刷新通知。该属性中计数器字段的值必须在播发之前递增。这会导致远程PE节点刷新与所讨论的B-MAC相关联的所有C-MAC地址。这是在映射到撤回/重新公布的MAC路由的EVI的所有I-SID上完成的。
When an Ethernet network is multihomed to a set of PE nodes running PBB-EVPN, Single-Active redundancy model can be supported with per-service instance (i.e., I-SID) load-balancing. In this model, DF election is performed to ensure that a single PE node in the redundancy group is responsible for forwarding traffic associated with a given I-SID. This guarantees that no forwarding loops are created. Filtering based on DF state applies to both unicast and multicast traffic, and in both access-to-core as well as core-to-access directions just like a Single-Active multihomed device scenario (but unlike an All-Active multihomed device scenario where DF filtering is limited to multi-destination frames in the core-to-access direction). Similar to a Single-Active multihomed device scenario, with load-balancing based on I-SID, a unique B-MAC address is assigned to each of the PE nodes connected to the multihomed network (segment).
当以太网多宿到运行PBB-EVPN的一组PE节点时，可以通过每个服务实例（即i-SID）负载平衡支持单个主动冗余模型。在该模型中，执行DF选择以确保冗余组中的单个PE节点负责转发与给定I-SID相关联的流量。这保证不会创建任何转发循环。基于DF状态的过滤适用于单播和多播流量，以及对核心的访问和核心到访问方向，就像单个活动多址设备场景（但与全活动多址设备场景不同，在全活动多址设备场景中，DF过滤仅限于核心到访问方向中的多个目标帧）。与单个活动多宿设备场景类似，通过基于I-SID的负载平衡，将唯一的B-MAC地址分配给连接到多宿网络（段）的每个PE节点。
The frame-forwarding functions are divided in between the Bridge Module, which hosts the [PBB] BEB functionality, and the MPLS Forwarder which handles the MPLS imposition/disposition. The details of frame forwarding for unicast and multi-destination frames are discussed next.
帧转发功能分为桥接模块（承载[PBB]BEB功能）和MPLS转发器（处理MPLS强制/处置）。接下来讨论单播和多目的帧的帧转发细节。
Known unicast traffic received from the Attachment Circuit (AC) will be PBB-encapsulated by the PE using the B-MAC source address corresponding to the originating site. The unicast B-MAC destination address is determined based on a lookup of the C-MAC destination address (the binding of the two is done via transparent learning of reverse traffic). The resulting frame is then encapsulated with an LSP tunnel label and an EVPN label associated with the B-MAC destination address. If per flow load-balancing over ECMPs in the MPLS core is required, then a flow label is added below the label associated with the B-MAC address in the label stack.
从连接电路（AC）接收的已知单播通信量将由PE使用对应于发起站点的B-MAC源地址来封装PBB。单播B-MAC目的地地址是基于C-MAC目的地地址的查找来确定的（二者的绑定是通过反向业务的透明学习来完成的）。然后用LSP隧道标签和与B-MAC目的地地址相关联的EVPN标签封装得到的帧。如果需要通过MPLS核心中的ECMPs实现每流负载平衡，则在标签堆栈中与B-MAC地址关联的标签下方添加流标签。
For unknown unicast traffic, the PE forwards these frames over the MPLS core. When these frames are to be forwarded, then the same set of options used for forwarding multicast/broadcast frames (as described in next section) are used.
对于未知的单播流量，PE通过MPLS核心转发这些帧。当要转发这些帧时，将使用用于转发多播/广播帧的相同选项集（如下一节所述）。
Multi-destination frames received from the AC will be PBB-encapsulated by the PE using the B-MAC source address corresponding to the originating site. The multicast B-MAC destination address is selected based on the value of the I-SID as defined in [PBB]. The resulting frame is then forwarded over the MPLS core using one of the following two options:
从AC接收的多目的地帧将由PE使用对应于发起站点的B-MAC源地址来封装PBB。根据[PBB]中定义的I-SID值选择多播B-MAC目标地址。然后使用以下两个选项之一在MPLS核心上转发生成的帧：
Option 1: the MPLS Forwarder can perform ingress replication over a set of MP2P or P2P tunnel LSPs. The frame is encapsulated with a tunnel LSP label and the EVPN ingress replication label advertised in the Inclusive Multicast Ethernet Tag [RFC7432].
选项1：MPLS转发器可以通过一组MP2P或P2P隧道LSP执行入口复制。该帧用隧道LSP标签和EVPN入口复制标签封装在包含多播以太网标签[RFC7432]中。
Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the procedures defined in [RFC7432]. This includes either the use of Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS Forwarder can use MP2MP tunnel LSP if Inclusive trees are used.
选项2:MPLS转发器可以按照[RFC7432]中定义的过程使用P2MP隧道LSP。这包括使用包含树或聚合包含树。此外，如果使用包含树，MPLS转发器可以使用MP2MP隧道LSP。
Note that the same procedures for advertising and handling the Inclusive Multicast Ethernet Tag defined in [RFC7432] apply here.
请注意，[RFC7432]中定义的用于广告和处理包容性多播以太网标记的相同过程适用于此处。
The encapsulation for the transport of PBB frames over MPLS is similar to that of classical Ethernet, albeit with the additional PBB header, as shown in the figure below:
通过MPLS传输PBB帧的封装与传统以太网的封装类似，尽管有额外的PBB报头，如下图所示：
+------------------+
| IP/MPLS Header |
+------------------+
| PBB Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
+------------------+
| IP/MPLS Header |
+------------------+
| PBB Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 3: PBB over MPLS Encapsulation
图3:PBB over MPLS封装
The PE nodes MAY implement an ARP/ND-proxy function in order to minimize the volume of ARP/ND traffic that is broadcasted over the MPLS network. In case of ARP proxy, this is achieved by having each PE node snoop on ARP request and response messages received over the access interfaces or the MPLS core. The PE builds a cache of IP/MAC address bindings from these snooped messages. The PE then uses this cache to respond to ARP requests ingress on access ports and target hosts that are in remote sites. If the PE finds a match for the IP address in its ARP cache, it responds back to the requesting host and drops the request. Otherwise, if it does not find a match, then the request is flooded over the MPLS network using either ingress replication or P2MP LSPs. In case of ND proxy, this is achieved similar to the above but with ND/NA messages per [RFC4389].
PE节点可以实现ARP/ND代理功能，以便最小化通过MPLS网络广播的ARP/ND通信量。对于ARP代理，这是通过让每个PE节点监听通过接入接口或MPLS核心接收的ARP请求和响应消息来实现的。PE根据这些窥探消息构建IP/MAC地址绑定的缓存。PE然后使用此缓存响应远程站点中的访问端口和目标主机上的ARP请求入口。如果PE在其ARP缓存中找到IP地址的匹配项，它将响应请求主机并丢弃请求。否则，如果未找到匹配项，则使用入口复制或P2MP LSP通过MPLS网络淹没请求。在ND代理的情况下，这与上述类似，但根据[RFC4389]使用ND/NA消息实现。
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
|SW1 |--| | | PE1| | PE2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
|SW1 |--| | | PE1| | PE2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------------------------- PBB -------------------------->| DP
|<----MPLS----->|
|<------------------------- PBB -------------------------->| DP
|<----MPLS----->|
Legend: CP = Control-Plane View DP = Data-Plane View
图例：CP=控制平面视图DP=数据平面视图
Figure 4: Interconnecting 802.1aq / 802.1Qbp Networks with PBB-EVPN
图4：将802.1aq/802.1Qbp网络与PBB-EVPN互连
The B-MAC addresses need to be globally unique across all networks including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC addresses used for single-homed and Single-Active Ethernet segments should be unique because they are typically auto-derived from the PE's pools of reserved MAC addresses that are unique. The B-MAC addresses used for All-Active Ethernet segments should also be unique given that each network operator typically has its own assigned Organizationally Unique Identifier (OUI) and thus can assign its own unique MAC addresses.
在包括PBB-EVPN和IEEE 802.1aq/802.1Qbp网络在内的所有网络中，B-MAC地址必须是全局唯一的。用于单主和单活动以太网段的B-MAC地址应该是唯一的，因为它们通常是从PE的唯一保留MAC地址池自动派生的。所有活动以太网段使用的B-MAC地址也应该是唯一的，因为每个网络运营商通常都有自己分配的组织唯一标识符（OUI），因此可以分配自己的唯一MAC地址。
B-MAC addresses associated with 802.1aq / 802.1Qbp switches are advertised using the EVPN MAC/IP route advertisement already defined in [RFC7432].
与802.1aq/802.1Qbp交换机关联的B-MAC地址使用[RFC7432]中已定义的EVPN MAC/IP路由播发进行播发。
8.3. Operation:
8.3. 操作：
When a PE receives a PBB-encapsulated Ethernet frame from the access side, it performs a lookup on the B-MAC destination address to identify the next hop. If the lookup yields that the next hop is a remote PE, the local PE would then encapsulate the PBB frame in MPLS. The label stack comprises of the VPN label (advertised by the remote
当PE从接入侧接收到PBB封装的以太网帧时，它在B-MAC目的地址上执行查找以识别下一跳。如果查找结果表明下一跳是远程PE，则本地PE将在MPLS中封装PBB帧。标签堆栈由VPN标签（由远程服务器播发）组成
PE), followed by an LSP/IGP label. From that point onwards, regular MPLS forwarding is applied.
PE），然后是LSP/IGP标签。从那时起，将应用常规MPLS转发。
On the disposition PE, assuming penultimate-hop-popping is employed, the PE receives the MPLS-encapsulated PBB frame with a single label: the VPN label. The value of the label indicates to the disposition PE that this is a PBB frame, so the label is popped, the TTL field (in the 802.1Qbp F-Tag) is reinitialized, and normal PBB processing is employed from this point onwards.
在部署PE上，假设采用倒数第二跳弹出，PE接收带有单个标签（VPN标签）的MPLS封装PBB帧。标签的值向处置PE指示这是一个PBB帧，因此标签弹出，TTL字段（在802.1Qbp F-Tag中）重新初始化，并且从此点开始使用正常PBB处理。
In this section, we discuss the advantages of the PBB-EVPN solution in the context of the requirements set forth in Section 3.
在本节中，我们将根据第3节中提出的要求讨论PBB-EVPN解决方案的优势。
In PBB-EVPN, the number of MAC Advertisement routes is a function of the number of Ethernet segments (e.g., sites) rather than the number of hosts/servers. This is because the B-MAC addresses of the PEs, rather than C-MAC addresses (of hosts/servers), are being advertised in BGP. As discussed above, there's a one-to-one mapping between All-Active multihomed segments and their associated B-MAC addresses; there can be either a one-to-one or many-to-one mapping between Single-Active multihomed segments and their associated B-MAC addresses; and finally there is a many-to-one mapping between single-home sites and their associated B-MAC addresses on a given PE. This means a single B-MAC is associated with one or more segments where each segment can be associated with many C-MAC addresses. As a result, the volume of MAC Advertisement routes in PBB-EVPN may be multiple orders of magnitude less than EVPN.
在PBB-EVPN中，MAC广告路由的数量是以太网段（例如站点）数量的函数，而不是主机/服务器的数量。这是因为在BGP中公布的是PEs的B-MAC地址，而不是（主机/服务器的）C-MAC地址。如上所述，在所有活动的多址段及其相关的B-MAC地址之间存在一对一映射；单个活动多址网段与其关联的B-MAC地址之间可以存在一对一或多对一映射；最后，在单个家庭站点和它们在给定PE上的相关B-MAC地址之间存在多对一映射。这意味着单个B-MAC与一个或多个段相关联，其中每个段可与多个C-MAC地址相关联。结果，PBB-EVPN中的MAC广告路由的容量可能比EVPN小多个数量级。
As described above, in PBB-EVPN, a single B-MAC address can aggregate many C-MAC addresses. Given that B-MAC addresses are associated with segments attached to a PE or to the PE itself, their locations are fixed and thus not impacted what so ever by C-MAC mobility. Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any re-advertisements of them). This is because the association of C-MAC address to B-MAC address is learned in the data-plane and C-MAC addresses are not advertised in BGP. Aggregation via B-MAC addresses in PBB-EVPN performs much better than EVPN.
如上所述，在PBB-EVPN中，单个B-MAC地址可以聚合多个C-MAC地址。鉴于B-MAC地址与连接到PE或PE本身的段相关联，它们的位置是固定的，因此不会受到C-MAC移动性的影响。因此，C-MAC移动性不影响B-MAC地址（例如，它们的任何重新广告）。这是因为C-MAC地址与B-MAC地址的关联是在数据平面中学习的，并且C-MAC地址不会在BGP中公布。PBB-EVPN中通过B-MAC地址进行聚合的性能比EVPN好得多。
To illustrate how this compares to EVPN, consider the following example:
为了说明这与EVPN相比，请考虑下面的例子：
If a PE running EVPN advertises reachability for N MAC addresses via a particular segment, and then 50% of the MAC addresses in that segment move to other segments (e.g., due to virtual machine mobility), then N/2 additional MAC Advertisement routes need to be sent for the MAC addresses that have moved. With PBB-EVPN, on the other hand, the B-MAC addresses that are statically associated with PE nodes are not subject to mobility. As C-MAC addresses move from one segment to another, the binding of C-MAC to B-MAC addresses is updated via data-plane learning in PBB-EVPN.
如果运行EVPN的PE通过特定段播发N个MAC地址的可达性，然后该段中50%的MAC地址移动到其他段（例如，由于虚拟机移动性），则需要为已移动的MAC地址发送N/2个额外的MAC播发路由。另一方面，对于PBB-EVPN，与PE节点静态关联的B-MAC地址不受移动性的影响。当C-MAC地址从一段移动到另一段时，通过PBB-EVPN中的数据平面学习更新C-MAC到B-MAC地址的绑定。
In PBB-EVPN, C-MAC address reachability information is built via data-plane learning. As such, PE nodes not participating in active conversations involving a particular C-MAC address will purge that address from their forwarding tables. Furthermore, since C-MAC addresses are not distributed in BGP, PE nodes will not maintain any record of them in the control-plane routing table.
在PBB-EVPN中，通过数据平面学习建立C-MAC地址可达性信息。因此，不参与涉及特定C-MAC地址的活动会话的PE节点将从其转发表中清除该地址。此外，由于C-MAC地址不分布在BGP中，PE节点将不会在控制平面路由表中维护它们的任何记录。
Consider the scenario where two access networks, one running MPLS and the other running 802.1aq, are interconnected via an MPLS backbone network. The figure below shows such an example network.
考虑两个接入网络，一个运行MPLS和另一个运行802.1aq的情况，通过MPLS骨干网络互连。下图显示了这样一个示例网络。
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | PE1| | PE2| | |--| CE |
+----+ | 802.1aq |---| | | |--| MPLS | +----+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | PE1| | PE2| | |--| CE |
+----+ | 802.1aq |---| | | |--| MPLS | +----+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 5: Interoperability with 802.1aq
图5：与802.1aq的互操作性
If the MPLS backbone network employs EVPN, then the 802.1aq data-plane encapsulation must be terminated on PE1 or the edge device connecting to PE1. Either way, all the PE nodes that are part of the associated service instances will be exposed to all the C-MAC addresses of all hosts/servers connected to the access networks. However, if the MPLS backbone network employs PBB-EVPN, then the 802.1aq encapsulation can be extended over the MPLS backbone, thereby maintaining C-MAC address transparency on PE1. If PBB-EVPN is also
如果MPLS主干网采用EVPN，则802.1aq数据平面封装必须在PE1或连接到PE1的边缘设备上终止。无论哪种方式，作为关联服务实例一部分的所有PE节点都将暴露于连接到接入网络的所有主机/服务器的所有C-MAC地址。然而，如果MPLS主干网络采用PBB-EVPN，则802.1aq封装可以扩展到MPLS主干上，从而在PE1上保持C-MAC地址的透明性。如果PBB-EVPN也是
extended over the MPLS access network on the right, then C-MAC addresses would be transparent to PE2 as well.
扩展到右边的MPLS接入网络，那么C-MAC地址对PE2也是透明的。
In PBB-EVPN, the per-site policy can be supported via B-MAC addresses via assigning a unique B-MAC address for every site/segment (typically multihomed but can also be single-homed). Given that the B-MAC addresses are sent in BGP MAC/IP route advertisement, it is possible to define per-site (i.e., B-MAC) forwarding policies including policies for E-TREE service.
在PBB-EVPN中，通过为每个站点/段分配唯一的B-MAC地址（通常是多址的，但也可以是单址的），可以通过B-MAC地址支持每站点策略。假设在BGP MAC/IP路由公告中发送B-MAC地址，则可以定义每个站点（即B-MAC）的转发策略，包括e-TREE服务的策略。
Just as in [RFC7432], with PBB-EVPN, it is possible to avoid C-MAC address flushing upon topology change affecting an All-Active multihomed segment. To illustrate this, consider the example network of Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1) to PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind CE1 via data-plane learning. If AC1 fails, then PE3 does not need to flush any of the C-MAC addresses learned and associated with BM1. This is because PE1 will withdraw the MAC Advertisement routes associated with BM1, thereby leading PE3 to have a single adjacency (to PE2) for this B-MAC address. Therefore, the topology change is communicated to PE3 and no C-MAC address flushing is required.
正如在[RFC7432]中一样，使用PBB-EVPN，可以避免在影响全活动多址段的拓扑更改时刷新C-MAC地址。为了说明这一点，请考虑图1的示例网络。PE1和PE2都向PE3公布相同的B-MAC地址（BM1）。然后，PE3通过数据平面学习学习CE1后面的服务器/主机的C-MAC地址。如果AC1失败，则PE3不需要刷新任何已学习并与BM1关联的C-MAC地址。这是因为PE1将撤回与BM1相关联的MAC广告路由，从而导致PE3对此B-MAC地址具有单一邻接（到PE2）。因此，拓扑更改被传送到PE3，不需要C-MAC地址刷新。
All the security considerations in [RFC7432] apply directly to this document because this document leverages the control plane described in [RFC7432] and their associated procedures -- although not the complete set but rather a subset.
[RFC7432]中的所有安全注意事项都直接适用于本文档，因为本文档利用了[RFC7432]中描述的控制平面及其相关过程——虽然不是完整的集合，而是子集。
This document does not introduce any new security considerations beyond that of [RFC7432] and [RFC4761] because advertisements and processing of B-MAC addresses follow that of [RFC7432] and processing of C-MAC addresses follow that of [RFC4761] -- i.e, B-MAC addresses are learned in the control plane and C-MAC addresses are learned in data plane.
除了[RFC7432]和[RFC4761]之外，本文件没有引入任何新的安全注意事项，因为B-MAC地址的播发和处理遵循[RFC7432]的播发和处理，C-MAC地址的处理遵循[RFC4761]的播发和处理——即，B-MAC地址在控制平面中学习，C-MAC地址在数据平面中学习。
There are no additional IANA considerations for PBB-EVPN beyond what is already described in [RFC7432].
除了[RFC7432]中已经描述的内容外，PBB-EVPN没有其他IANA注意事项。
[PBB] 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.
[PBB]IEEE，“局域网和城域网IEEE标准-媒体访问控制（MAC）网桥和虚拟桥接局域网”，第25和26条，IEEE标准802.1Q，DOI 10.1109/IEEESTD.2011.6009146。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7432>.
[MMRP] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clause 10, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
[MMRP]IEEE，“IEEE局域网和城域网标准-媒体访问控制（MAC）网桥和虚拟桥接局域网”，第10条，IEEE标准802.1Q，DOI 10.1109/IEEESTD.2011.6009146。
[OVERLAY] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Isaac, A., Uttaro, J., Henderickx, W., Shekhar, R., Salam, S., Patel, K., Rao, D., and S. Thoria, "A Network Virtualization Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01, February 2015.
[OVERLAY]Sajassi，A.，Ed.，Drake，J.，Ed.，Bitar，N.，Isaac，A.，Uttaro，J.，Henderickx，W.，Shekhar，R.，Salam，S.，Patel，K.，Rao，D.，和S.Thoria，“使用EVPN的网络虚拟化覆盖解决方案”，草稿-ietf-bess-EVPN-OVERLAY-01，2015年2月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，DOI 10.17487/RFC4389，2006年4月<http://www.rfc-editor.org/info/rfc4389>.
[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, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<http://www.rfc-editor.org/info/rfc4761>.
[RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, December 2013, <http://www.rfc-editor.org/info/rfc7080>.
[RFC7080]Sajassi，A.，Salam，S.，Bitar，N.，和F.Balus，“虚拟专用局域网服务（VPLS）与提供商主干网桥的互操作性”，RFC 7080，DOI 10.17487/RFC70802013年12月<http://www.rfc-editor.org/info/rfc7080>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7209>.
Acknowledgements
致谢
The authors would like to thank Jose Liste and Patrice Brissette for their reviews and comments of this document. We would also like to thank Giles Heron for several rounds of reviews and providing valuable inputs to get this document ready for IESG submission.
作者感谢Jose Liste和Patrice Brissette对本文件的评论和评论。我们还要感谢Giles Heron进行了几轮审查，并提供了宝贵的投入，以便为IESG提交本文件做好准备。
Contributors
贡献者
In addition to the authors listed, the following individuals also contributed to this document.
除了列出的作者之外，以下个人也对本文件作出了贡献。
Lizhong Jin, ZTE Sami Boutros, Cisco Dennis Cai, Cisco Keyur Patel, Cisco Sam Aldrin, Huawei Himanshu Shah, Ciena Jorge Rabadan, ALU
Jin Lizhong、中兴通讯Sami Boutros、Cisco Dennis Cai、Cisco Keyur Patel、Cisco Sam Aldrin、华为Himanshu Shah、Ciena Jorge Rabadan、ALU
Authors' Addresses
作者地址
Ali Sajassi, editor Cisco 170 West Tasman Drive San Jose, CA 95134 United States Email: sajassi@cisco.com
Ali Sajassi，编辑Cisco 170 West Tasman Drive San Jose，CA 95134美国电子邮件：sajassi@cisco.com
Samer Salam Cisco 595 Burrard Street, Suite # 2123 Vancouver, BC V7X 1J1 Canada Email: ssalam@cisco.com
Samer Salam Cisco加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室V7X 1J1电子邮件：ssalam@cisco.com
Nabil Bitar Verizon Communications Email: nabil.n.bitar@verizon.com
Nabil Bitar Verizon通信电子邮件：Nabil.n。bitar@verizon.com
Aldrin Isaac Juniper Email: aisaac@juniper.net
Aldrin Isaac Juniper电子邮件：aisaac@juniper.net
Wim Henderickx Alcatel-Lucent Email: wim.henderickx@alcatel-lucent.com
Wim亨德里克斯阿尔卡特朗讯电子邮件：Wim。henderickx@alcatel-朗讯网