Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7782 Huawei
Category: Standards Track R. Perlman
ISSN: 2070-1721 EMC
H. Zhai
Astute Technology
M. Durrani
Cisco Systems
S. Gupta
IP Infusion
February 2016
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7782 Huawei
Category: Standards Track R. Perlman
ISSN: 2070-1721 EMC
H. Zhai
Astute Technology
M. Durrani
Cisco Systems
S. Gupta
IP Infusion
February 2016
Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
使用多个MAC附件的大量链路（TRILL）活动边缘的透明互连
Abstract
摘要
TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.
TRILL（大量链路的透明互连）主动服务在TRILL校园边缘为终端站提供流量级负载平衡和链路故障恢复能力，如RFC 7379所述。
This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.
本文档规定了一种方法，通过该方法，活动边缘RBridge组中的成员RBridge（也称为路由桥或TRILL交换机）使用其自己的昵称作为入口RBridge昵称来封装来自连接端系统的帧。因此，远程边缘RBridge（不在组中的）将看到一个主机媒体访问控制（MAC）地址与组中的多个RBridge相关联。需要此类远程边缘rbridge来维护所有这些关联（即MAC附件），并且不在它们之间发生触发器（如在实施本规范之前发生的那样）。本文讨论了本规范的设计目标。
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/rfc7782.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7782.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Acronyms and Terminology ........................................4
3. Overview ........................................................5
4. Incremental Deployable Options ..................................6
4.1. Details of Option B ........................................7
4.1.1. Advertising Data Labels for Active-Active Edge ......7
4.1.2. Discovery of Active-Active Edge Members .............8
4.1.3. Advertising Learned MAC Addresses ...................9
4.2. Extended RBridge Capability Flags APPsub-TLV ..............11
5. Meeting the Design Goals .......................................12
5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) ......12
5.2. Regular Unicast/Multicast Ingress .........................12
5.3. Correct Multicast Egress ..................................12
5.3.1. No Duplication (Single Exit Point) .................12
5.3.2. No Echo (Split Horizon) ............................13
5.4. No Black-Hole or Triangular Forwarding ....................14
5.5. Load Balance towards the AAE ..............................14
5.6. Scalability ...............................................14
6. E-L1FS Backward Compatibility ..................................15
7. Security Considerations ........................................15
8. IANA Considerations ............................................16
8.1. TRILL APPsub-TLVs .........................................16
8.2. Extended RBridge Capabilities Registry ....................16
8.3. Active-Active Flags .......................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................19
Appendix A. Scenarios for Split Horizon ...........................20
Acknowledgments ...................................................21
Authors' Addresses ................................................22
1. Introduction ....................................................3
2. Acronyms and Terminology ........................................4
3. Overview ........................................................5
4. Incremental Deployable Options ..................................6
4.1. Details of Option B ........................................7
4.1.1. Advertising Data Labels for Active-Active Edge ......7
4.1.2. Discovery of Active-Active Edge Members .............8
4.1.3. Advertising Learned MAC Addresses ...................9
4.2. Extended RBridge Capability Flags APPsub-TLV ..............11
5. Meeting the Design Goals .......................................12
5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) ......12
5.2. Regular Unicast/Multicast Ingress .........................12
5.3. Correct Multicast Egress ..................................12
5.3.1. No Duplication (Single Exit Point) .................12
5.3.2. No Echo (Split Horizon) ............................13
5.4. No Black-Hole or Triangular Forwarding ....................14
5.5. Load Balance towards the AAE ..............................14
5.6. Scalability ...............................................14
6. E-L1FS Backward Compatibility ..................................15
7. Security Considerations ........................................15
8. IANA Considerations ............................................16
8.1. TRILL APPsub-TLVs .........................................16
8.2. Extended RBridge Capabilities Registry ....................16
8.3. Active-Active Flags .......................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................19
Appendix A. Scenarios for Split Horizon ...........................20
Acknowledgments ...................................................21
Authors' Addresses ................................................22
As discussed in [RFC7379], in a TRILL (Transparent Interconnection of Lots of Links) Active-Active Edge (AAE) topology, a Local Active-Active Link Protocol (LAALP) -- for example, a Multi-Chassis Link Aggregation (MC-LAG) bundle -- is used to connect multiple RBridges (Routing Bridges or TRILL switches) to multi-port Customer Equipment (CE), such as a switch, virtual switch (vSwitch), or multi-port end station. A set of end nodes is attached in the case of a switch or vSwitch. It is required that data traffic within a specific VLAN from this end node set (including the multi-port end-station case) can be ingressed and egressed by any of these RBridges simultaneously. End systems in the set can spread their traffic among these edge RBridges at the flow level. When a link fails, end systems keep using the remaining links in the LAALP without waiting for the convergence of TRILL, which provides resilience to link failures.
如[RFC7379]中所述，在TRILL（多链路透明互连）主动边缘（AAE）拓扑中，本地主动链路协议（LAALP）——例如，多机箱链路聚合（MC-LAG）捆绑包——用于将多个RBridge（路由桥或TRILL交换机）连接到多端口客户设备（CE），例如交换机、虚拟交换机（vSwitch）或多端口终端站。如果是交换机或vSwitch，则会连接一组端节点。要求来自该终端节点集（包括多端口终端站情况）的特定VLAN内的数据流量可以由这些RBridge中的任何一个同时进入和离开。集合中的终端系统可以在流量级别将其流量分布在这些边缘RBridge之间。当一条链路发生故障时，终端系统会继续使用LAALP中的剩余链路，而无需等待TRILL的收敛，这为链路故障提供了恢复能力。
Since a frame from each end node can be ingressed by any RBridge in the local AAE group, a remote edge RBridge may observe multiple attachment points (i.e., egress RBridges) for this end node. This issue is known as "MAC address flip-flopping"; see [RFC7379] for a discussion.
由于来自每个终端节点的帧可以由本地AAE组中的任何RBridge进入，因此远程边缘RBridge可以观察该终端节点的多个连接点（即，出口RBridge）。这个问题被称为“MAC地址触发器”；有关讨论，请参见[RFC7379]。
Per this document, AAE member RBridges use their own nicknames to ingress frames into the TRILL campus. Remote edge RBridges are required to keep multiple points of attachment per MAC address and Data Label (VLAN or Fine-Grained Label [RFC7172]) attached to the AAE. This addresses the MAC flip-flopping issue. Using this solution, as specified in this document, in an AAE group does not prohibit the use of other solutions in other AAE groups in the same TRILL campus. For example, the specification in this document and the specification in [RFC7781] could be simultaneously deployed for different AAE groups in the same campus.
根据本文档，AAE成员RBridges使用自己的昵称将帧导入TRILL校园。远程边缘RBridge需要保持每个MAC地址和连接到AAE的数据标签（VLAN或细粒度标签[RFC7172]）的多个连接点。这就解决了MAC触发器的问题。如本文档所述，在AAE组中使用此解决方案并不禁止在同一TRILL校园的其他AAE组中使用其他解决方案。例如，本文档中的规范和[RFC7781]中的规范可以同时部署到同一校园中的不同AAE组。
The main body of this document is organized as follows: Section 2 lists acronyms and terms. Section 3 describes the overview model. Section 4 provides options for incremental deployment. Section 5 describes how this approach meets the design goals. Section 6 discusses backward compatibility. Section 7 covers security considerations. Section 8 covers IANA considerations.
本文件的主体结构如下：第2节列出了缩略语和术语。第3节描述了概述模型。第4节提供了增量部署的选项。第5节描述了该方法如何满足设计目标。第6节讨论向后兼容性。第7节涉及安全考虑。第8节介绍了IANA的考虑因素。
AAE: Active-Active Edge
AAE：活动边
Campus: A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
校园网：由TRILL交换机、链路和可能由终端站和IP路由器连接的网桥组成的TRILL网络。对于TRILL来说，“校园”这个名字没有“学术”含义。
CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment.
CE：客户设备（终端站或桥接器）。设备可以是物理设备，也可以是虚拟设备。
Data Label: VLAN or Fine-Grained Label (FGL)
数据标签：VLAN或细粒度标签（FGL）
DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges.
分布式弹性网络互连。[802.1AX]中规定的链路聚合，可在（A）一个、两个或三个CE和（b）两个或三个RBRIGE之间提供LAALP。
E-L1FS: Extended Level 1 Flooding Scope
E-L1FS：扩展1级泛洪范围
Edge RBridge: An RBridge providing end-station service on one or more of its ports.
边缘RBridge：在其一个或多个端口上提供终端站服务的RBridge。
ESADI: End Station Address Distribution Information [RFC7357]
ESADI：端站地址分布信息[RFC7357]
FGL: Fine-Grained Label [RFC7172]
FGL：细粒度标签[RFC7172]
FS-LSP: Flooding Scope Link State Protocol Data Unit
FS-LSP：泛洪作用域链路状态协议数据单元
IS: Intermediate System [IS-IS]
IS：中间系统[IS-IS]
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中间系统至中间系统[IS-IS]
LAALP: Local Active-Active Link Protocol [RFC7379]. Any protocol similar to MC-LAG (or DRNI) that runs in a distributed fashion on a CE, on the links from that CE to a set of edge group RBridges, and on those RBridges.
LAALP：本地主动链路协议[RFC7379]。任何类似于MC-LAG（或DRNI）的协议，在CE、从该CE到一组边缘组RBridge的链路以及这些RBridge上以分布式方式运行。
LSP: Link State PDU
链路状态PDU
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of link aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
MC-LAG：多机箱链路聚合。链路聚合[802.1AX]的专有扩展，可在一个CE和两个或多个RBRIGE之间提供LAALP。
PDU: Protocol Data Unit
协议数据单元
RBridge: A device implementing the TRILL protocol.
RBridge：实现TRILL协议的设备。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7177].
TRILL：链路层中大量链路的透明互连或隧道路由[RFC6325][RFC7177]。
TRILL switch: An alternative name for an RBridge.
颤音开关：RBridge的另一个名称。
vSwitch: A virtual switch, such as a hypervisor, that also simulates a bridge.
vSwitch：虚拟交换机，如虚拟机监控程序，它还模拟网桥。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Familiarity with [RFC6325], [RFC6439], and [RFC7177] is assumed in this document.
本文件假定熟悉[RFC6325]、[RFC6439]和[RFC7177]。
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||LAALP1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||LAALP1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10
Figure 1: An Example Topology for TRILL Active-Active Edge
图1:TRILL活动边的拓扑示例
Figure 1 shows an example network for TRILL AAE (see also Figure 1 in [RFC7379]). In this figure, end nodes (H1, H2, H3, and H4) are attached to a bridge (B) that communicates with multiple RBridges (RB1, RB2, and RB3) via the LAALP. Suppose that RB4 is a "remote" RBridge not in the AAE group in the TRILL campus. This connection model is also applicable to the virtualized environment where the physical bridge can be replaced with a vSwitch while those bare metal hosts are replaced with virtual machines (VMs).
图1显示了TRILL AAE的示例网络（另请参见[RFC7379]中的图1）。在该图中，终端节点（H1、H2、H3和H4）连接到桥接器（B），该桥接器通过LAALP与多个RBridge（RB1、RB2和RB3）通信。假设RB4是一个“远程”RBridge，不在TRILL校园的AAE组中。此连接模型也适用于虚拟化环境，在虚拟化环境中，物理网桥可以用vSwitch替换，而那些裸机主机可以用虚拟机（VM）替换。
For a frame received from its attached end node sets, a member RBridge of the AAE group conforming to this document always encapsulates that frame using its own nickname as the ingress nickname, regardless of whether it is unicast or multicast.
对于从其连接的终端节点集接收的帧，符合本文档的AAE组的成员RBridge总是使用其自己的昵称作为入口昵称来封装该帧，而不管它是单播还是多播。
With the two options specified below, even though remote RBridge RB4 will see multiple attachments for each MAC address from one of the end nodes, MAC address flip-flopping will not cause any problems.
使用下面指定的两个选项，即使远程RBridge RB4将看到来自一个终端节点的每个MAC地址的多个附件，MAC地址翻转也不会导致任何问题。
This section specifies two options. Option A requires new hardware support. Option B can be incrementally implemented throughout a TRILL campus with common existing TRILL "fast path" hardware. Further details on Option B are given in Section 4.1.
本节指定了两个选项。选项A需要新的硬件支持。选项B可以在一个TRILL校园内，使用常见的现有TRILL“快速路径”硬件，以增量方式实施。第4.1节给出了选项B的更多详细信息。
Option A: A new capability announcement would appear in LSPs: "I can cope with data-plane learning of multiple attachments for an end node." This mode of operation is generally not supported by existing TRILL fast path hardware. Only if all edge RBridges to which the group has data connectivity -- and that are interested in any of the Data Labels in which the AAE is interested -- announce this capability can the AAE group safely use this approach. If all such RBridges do not announce this "Option A" capability, then a fallback would be needed, such as reverting from active-active to active-standby operation or isolating the RBridges that would need to support this capability but do not support it. Further details for Option A are beyond the scope of this document, except that, as described in Section 4.2, a bit is reserved to indicate support for Option A, because a remote RBridge supporting Option A is compatible with an AAE group using Option B.
选项A：LSP中会出现一个新的功能公告：“我可以处理一个终端节点的多个附件的数据平面学习。”现有TRILL fast path硬件通常不支持这种操作模式。只有当集团拥有数据连接的所有边缘RBridge（以及对AAE感兴趣的任何数据标签感兴趣的边缘RBridge）宣布此功能时，AAE集团才能安全地使用此方法。如果所有此类RBridge未宣布此“选项A”功能，则需要回退，例如从主-主操作恢复到主-备操作，或隔离需要支持此功能但不支持此功能的RBridge。选项A的进一步详细信息超出了本文件的范围，但如第4.2节所述，保留一个位表示支持选项A，因为支持选项A的远程RBridge与使用选项B的AAE组兼容。
Option B: As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357], one MAC address may be persistently claimed to be attached to multiple RBridges within the same Data Label in the TRILL ESADI-LSPs. For Option B, AAE member RBridges make use of the TRILL ESADI protocol to distribute multiple attachments of a MAC address. Remote RBridges SHOULD disable data-plane MAC learning for such multi-attached MAC addresses from TRILL Data packet decapsulation, unless they also support Option A. The ability to configure an RBridge to disable data-plane learning is provided by the base TRILL protocol [RFC6325].
选项B：正如[RFC6325]第4.2.6节和[RFC7357]第5.3节所指出的，一个MAC地址可能会持续地连接到TRILL ESADI LSP中同一数据标签内的多个RBridge。对于选项B，AAE成员RBridges利用TRILL ESADI协议分发MAC地址的多个附件。远程RBridge应从TRILL数据包去封装中禁用此类多连接MAC地址的数据平面MAC学习，除非它们也支持选项A。配置RBridge以禁用数据平面学习的能力由基本TRILL协议[RFC6325]提供。
With Option B, the receiving edge RBridges MUST avoid flip-flop errors for MAC addresses learned from the TRILL Data packet decapsulation for the originating RBridge within these Data Labels. It is RECOMMENDED that the receiving edge RBridge disable data-plane MAC learning from TRILL Data packet decapsulation within those advertised Data Labels for the originating RBridge, unless the receiving RBridge also supports Option A. Alternative implementations that produce the same expected behavior, i.e., the receiving edge RBridge does not flip-flop among multiple MAC attachments, are acceptable. For example, the confidence-level mechanism as specified in [RFC6325] can be used. Let the receiving edge RBridge give a prevailing confidence value (e.g., 0x21) to the first MAC attachment learned from the data plane over others from the TRILL Data packet decapsulation. The receiving edge RBridge will stick to this MAC attachment until it is overridden by one learned from the ESADI protocol [RFC7357]. The MAC attachment learned from ESADI is set to have a higher confidence value (e.g., 0x80) to override any alternative learning from the decapsulation of received TRILL Data packets [RFC6325].
对于选项B，接收边缘RBridge必须避免从这些数据标签内的原始RBridge的TRILL数据包去封装中学习到的MAC地址的触发器错误。建议接收边缘RBridge在发起RBridge的那些广告数据标签内禁用从TRILL数据包去封装的数据平面MAC学习，除非接收RBridge还支持选项A。产生相同预期行为的替代实现，即。，接收边缘RBridge不会在多个MAC附件之间触发，这是可以接受的。例如，可以使用[RFC6325]中规定的置信水平机制。让接收边缘RBridge对从数据平面学习到的第一MAC连接给出一个普遍置信值（例如，0x21），而不是从TRILL数据分组去封装中学习到的其他MAC连接。接收边缘RBridge将坚持此MAC连接，直到它被从ESADI协议[RFC7357]学习到的连接覆盖。从ESADI学习到的MAC连接被设置为具有更高的置信值（例如0x80），以覆盖从接收到的TRILL数据包的去封装中学习到的任何替代学习[RFC6325]。
An RBridge in an AAE group MUST participate in ESADI in Data Labels enabled for its attached LAALPs. This document further registers two data flags, which are used to advertise that the originating RBridge supports and participates in an AAE. These two flags are allocated from the Interested VLANs Flag Bits that appear in the Interested VLANs and Spanning Tree Roots sub-TLV and the Interested Labels Flag Bits that appear in the Interested Labels and Spanning Tree Roots sub-TLV [RFC7176] (see Section 8.3). When these flags are set to 1, the originating RBridge is advertising Data Labels for LAALPs rather than plain LAN links.
AAE组中的RBridge必须在为其连接的LAALP启用的数据标签中参与ESADI。本文档还注册了两个数据标志，用于通告发起RBridge支持并参与AAE。这两个标志是从相关VLAN和生成树根子TLV中出现的相关VLAN标志位和相关标签和生成树根子TLV[RFC7176]中出现的相关标签标志位分配的（见第8.3节）。当这些标志设置为1时，原始RBridge将为LAALPs而不是普通LAN链路发布数据标签。
Remote edge RBridges need to discover RBridges in an AAE. This is achieved by listening to the following "AA LAALP Group RBridges" TRILL APPsub-TLV included in the TRILL GENINFO TLV in FS-LSPs [RFC7780]:
远程边缘RBridges需要在AAE中发现RBridges。这是通过收听FS LSP[RFC7780]中TRILL GENINFO TLV中包含的以下“AA LAALP Group RBridges”TRILL APPsub TLV来实现的：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: AA LAALP Group RBridges (TRILL APPsub-TLV type 252)
o 类型：AA LAALP集团RBridges（TRILL APPsub TLV 252型）
o Length: 3 + k
o 长度：3+k
o Sender Nickname: The nickname the originating RBridge will use as the ingress nickname. This field is useful because the originating RBridge might own multiple nicknames.
o 发送方昵称：发起RBridge将用作入口昵称的昵称。此字段很有用，因为原始RBridge可能拥有多个昵称。
o LAALP ID Size: The length, k, of the LAALP ID in bytes.
o LAALP ID大小：LAALP ID的长度k，以字节为单位。
o LAALP ID: The ID of the LAALP, which is k bytes long. If the LAALP is an MC-LAG or DRNI, it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
o LAALP ID：LAALP的ID，长度为k字节。如果LAALP是MC-LAG或DRNI，则为[802.1AX]第6.3.2条中规定的8字节ID。
This APPsub-TLV is expected to rarely change, as it only does so in cases of the creation or elimination of an AAE group, or of link failure or restoration to the CE in such a group.
该APPsub TLV预计很少发生变化，因为它仅在创建或消除AAE组，或在此类组中发生链路故障或恢复到CE的情况下才会发生变化。
Whenever MAC addresses from the LAALP of this AAE are learned through ingress or configuration, the originating RBridge MUST advertise these MAC addresses using the MAC-Reachability TLV [RFC6165] via the ESADI protocol [RFC7357]. The MAC-Reachability TLVs are composed in a way that each TLV only contains MAC addresses of end nodes attached to a single LAALP. Each such TLV is enclosed in a TRILL APPsub-TLV, defined as follows:
每当通过入口或配置从该AAE的LAALP获知MAC地址时，发起RBridge必须通过ESADI协议[RFC7357]使用MAC可达性TLV[RFC6165]公布这些MAC地址。MAC可达性TLV的组成方式是，每个TLV仅包含连接到单个LAALP的终端节点的MAC地址。每个此类TLV都包含在TRILL APPsub TLV中，定义如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-MAC | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MAC-Reachability TLV (7 + 6*n bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-MAC | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MAC-Reachability TLV (7 + 6*n bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: AA LAALP Group MAC (TRILL APPsub-TLV type 253)
o 类型：AA LAALP集团MAC（TRILL APPsub TLV 253型）
o Length: The MAC-Reachability TLV [RFC6165] is contained in the value field as a sub-TLV. The total number of bytes contained in the value field is given by k + 8 + 6*n.
o 长度：MAC可达性TLV[RFC6165]作为子TLV包含在值字段中。值字段中包含的总字节数由k+8+6*n表示。
o LAALP ID Size: The length, k, of the LAALP ID in bytes.
o LAALP ID大小：LAALP ID的长度k，以字节为单位。
o LAALP ID: The ID of the LAALP, which is k bytes long. Here, it also serves as the identifier of the AAE. If the LAALP is an MC-LAG (or DRNI), it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
o LAALP ID：LAALP的ID，长度为k字节。在这里，它还充当AAE的标识符。如果LAALP是MC-LAG（或DRNI），则它是[802.1AX]第6.3.2条中规定的8字节ID。
o MAC-Reachability sub-TLV: The AA-LAALP-GROUP-MAC APPsub-TLV value contains the MAC-Reachability TLV as a sub-TLV (see [RFC6165]; n is the number of MAC addresses present). As specified in Section 2.2 of [RFC7356], the Type and Length fields of the MAC-Reachability TLV are encoded as unsigned 16-bit integers. The 1-byte unsigned confidence value, along with these TLVs, SHOULD be set to prevail over those MAC addresses learned from TRILL Data decapsulation by remote edge RBridges.
o MAC可达性子TLV:AA-LAALP-GROUP-MAC APPsub TLV值包含MAC可达性TLV作为子TLV（请参阅[RFC6165]；n是存在的MAC地址数）。如[RFC7356]第2.2节所述，MAC可达性TLV的类型和长度字段编码为无符号16位整数。1字节无符号置信值以及这些TLV应设置为优先于远程边缘RBridge从TRILL数据去封装中获得的MAC地址。
This AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL GENINFO TLV [RFC7357] in the ESADI-LSP. There may be more than one occurrence of such TRILL APPsub-TLVs in one ESADI-LSP fragment.
该AA-LAALP-GROUP-MAC APPsub TLV必须包含在ESADI-LSP中的TRILL GENINFO TLV[RFC7357]中。在一个ESADI-LSP片段中，此类颤音APPsub TLV可能不止一次出现。
For those MAC addresses contained in an AA-LAALP-GROUP-MAC APPsub-TLV, this document applies. Otherwise, [RFC7357] applies. For example, an AAE member RBridge continues to enclose MAC addresses learned from TRILL Data packet decapsulation in MAC-Reachability TLVs as per [RFC6165] and advertise them using the ESADI protocol.
对于AA-LAALP-GROUP-MAC APPsub TLV中包含的MAC地址，本文件适用。否则，[RFC7357]适用。例如，AAE成员RBridge继续按照[RFC6165]在MAC可达性TLV中封装从TRILL数据包去封装中学习到的MAC地址，并使用ESADI协议公布它们。
When the remote RBridge learns MAC addresses contained in the AA-LAALP-GROUP-MAC APPsub-TLV via the ESADI protocol [RFC7357], it sends the packets destined to these MAC addresses to the closest one (the one to which the remote RBridge has the least-cost forwarding path) of those RBridges in the AAE identified by the LAALP ID in the AA-LAALP-GROUP-MAC APPsub-TLV. If there are multiple equal least-cost member RBridges, the ingress RBridge is required to select one of them in a pseudorandom way, as specified in Section 5.3 of [RFC7357].
当远程RBridge通过ESADI协议[RFC7357]学习AA-LAALP-GROUP-MAC APPsub TLV中包含的MAC地址时，它将发送到这些MAC地址的包发送到最近的MAC地址（远程RBridge具有最低成本转发路径的MAC地址）由AA-LAALP-GROUP-MAC APPsub TLV中的LAALP ID识别的AAE中的RBRINGS。如[RFC7357]第5.3节所述，如果存在多个相等的最小成本成员RBridge，则入口RBridge需要以伪随机方式选择其中一个。
When another RBridge in the same AAE group receives an ESADI-LSP with the AA-LAALP-GROUP-MAC APPsub-TLV, it also learns MAC addresses of those end nodes served by the corresponding LAALP. These MAC addresses SHOULD be learned as if those end nodes are locally attached to this RBridge itself.
当同一AAE组中的另一个RBridge接收到带有AA-LAALP-group-MAC APPsub TLV的ESADI-LSP时，它还学习由相应LAALP服务的那些终端节点的MAC地址。应该学习这些MAC地址，就像这些终端节点本地连接到此RBridge本身一样。
An AAE member RBridge MUST use the AA-LAALP-GROUP-MAC APPsub-TLV to advertise in ESADI the MAC addresses learned from a plain local link (a non-LAALP link) with Data Labels that happen to be covered by the Data Labels of any attached LAALP. The reason is that MAC learning from TRILL Data packet decapsulation within these Data Labels at the remote edge RBridge has normally been disabled for this RBridge.
AAE成员RBridge必须使用AA-LAALP-GROUP-MAC APPsub TLV在ESADI中公布从普通本地链路（非LAALP链路）获取的MAC地址，该链路的数据标签恰好包含在任何附加LAALP的数据标签中。原因是，在远程边缘RBridge的这些数据标签内，从TRILL数据包去封装的MAC学习通常已对此RBridge禁用。
This APPsub-TLV changes whenever the MAC reachability situation for the LAALP changes.
每当LAALP的MAC可达性情况发生变化时，此APPsub TLV就会发生变化。
The following Extended RBridge Capability Flags APPsub-TLV will be included in E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO TLV:
以下扩展RBridge能力标志APPsub TLV将作为TRILL GENINFO TLV的APPsub TLV包含在E-L1FS FS-LSP碎片零[RFC7780]中：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDED-RBRIDGE-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDED-RBRIDGE-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended RBridge Capability (TRILL APPsub-TLV type 254)
o 类型：扩展RBridge能力（TRILL APPsub TLV 254型）
o Length: Set to 10.
o 长度：设置为10。
o Topology: Indicates the topology to which the capabilities apply. When this field is set to zero, either topologies are not in use or the capabilities apply to all topologies [TRILL-MT].
o 拓扑：指示应用功能的拓扑。当该字段设置为零时，要么拓扑未使用，要么功能适用于所有拓扑[TRILL-MT]。
o E: Bit 0 of the capability bits. When this bit is set, it indicates that the originating RBridge acts as specified in Option B above.
o E：能力位的第0位。当设置该位时，它表示起始RBridge按照上述选项B中的规定进行操作。
o H: Bit 1 of the capability bits. When this bit is set, it indicates that the originating RBridge keeps multiple MAC attachments learned from TRILL Data packet decapsulation with fast path hardware; that is, it acts as specified in Option A above.
o H：能力位的第1位。当该位被设置时，它指示发起RBridge保持从TRILL数据包使用快速路径硬件去封装中学习的多个MAC附件；也就是说，它按照上面选项A中的规定工作。
o Reserved: Flags extending from bit 2 through bit 63 of the capability bits. Reserved for future use. These MUST be sent as zero and ignored on receipt.
o 保留：从功能位的第2位扩展到第63位的标志。保留供将来使用。这些必须作为零发送，并在收到时忽略。
The Extended RBridge Capability Flags TRILL APPsub-TLV is used to notify other RBridges as to whether the originating RBridge supports the capability indicated by the E and H bits. For example, if the E bit is set, it indicates that the originating RBridge will act as defined in Option B. That is, it will disable the MAC learning from TRILL Data packet decapsulation within Data Labels advertised by AAE RBridges while waiting for the TRILL ESADI-LSPs to distribute the {MAC, Nickname, Data Label} association. Meanwhile, this RBridge is able to act as an AAE RBridge. It is required that MAC addresses
扩展的RBridge能力标志TRILL APPsub TLV用于通知其他RBridge原始RBridge是否支持由E和H位指示的能力。例如，如果设置了E位，则表示始发RBridge将按照选项B中的定义进行操作。也就是说，它将在等待TRILL ESADI LSP分发{MAC，昵称，数据标签}关联的同时，禁用AAE RBridges公布的数据标签内TRILL数据包去封装的MAC学习。同时，该RBridge能够充当AAE RBridge。需要MAC地址
learned from local LAALPs be advertised in TRILL ESADI-LSPs, using the AA-LAALP-GROUP-MAC APPsub-TLV, which is defined in Section 4.1.3. If an RBridge in an AAE group, as specified herein, observes a remote RBridge interested in one or more of that AAE group's Data Labels and the remote RBridge does not support, as indicated by its extended capabilities, either Option A or Option B, then the AAE group MUST fall back to active-standby mode.
使用第4.1.3节定义的AA-LAALP-GROUP-MAC APPsub TLV，在TRILL ESADI LSP中宣传从当地LAALP学到的知识。如本文所述，如果AAE组中的RBridge观察到对该AAE组的一个或多个数据标签感兴趣的远程RBridge，并且远程RBridge不支持选项a或选项B，则AAE组必须返回到主备模式。
This APPsub-TLV is expected to rarely change, as it only needs to be updated when RBridge capabilities change, e.g., due to an upgrade or reconfiguration.
该APPsub TLV预计很少发生变化，因为它只需要在RBridge功能发生变化时更新，例如，由于升级或重新配置。
This section explores how this specification meets the major design goals of AAE.
本节探讨本规范如何满足AAE的主要设计目标。
Since all RBridges talking with the AAE RBridges in the campus are able to see multiple attachments for one MAC address in ESADI [RFC7357], a MAC address learned from one AAE member will not be overwritten by the same MAC address learned from another AAE member. Although multiple entries for this MAC address will be created, for return traffic the remote RBridge is required to consistently use one of the attachments for each MAC address rather than flip-flopping among them (see Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357]).
由于在校园内与AAE RBridge通话的所有RBridge都能够在ESADI[RFC7357]中看到一个MAC地址的多个附件，因此从一个AAE成员获悉的MAC地址不会被从另一个AAE成员获悉的相同MAC地址覆盖。尽管将为此MAC地址创建多个条目，但对于返回流量，远程RBridge需要始终为每个MAC地址使用一个附件，而不是在它们之间切换（参见[RFC6325]第4.2.6节和[RFC7357]第5.3节）。
LAALP guarantees that each frame will be sent to the AAE via exactly one uplink. RBridges in the AAE simply follow the process per [RFC6325] to ingress the frame. For example, each RBridge uses its own nickname as the ingress nickname to encapsulate the frame. In such a scenario, each RBridge takes for granted that it is the Appointed Forwarder for the VLANs enabled on the uplink of the LAALP.
LAALP保证每个帧将通过一个上行链路发送到AAE。AAE中的RBridge只需按照[RFC6325]的流程进入帧。例如，每个RBridge使用自己的昵称作为入口昵称来封装帧。在这种情况下，每个RBridge都理所当然地认为它是LAALP上行链路上启用的VLAN的指定转发器。
A fundamental design goal of AAE is that there must be no duplication or forwarding loop.
AAE的一个基本设计目标是必须没有复制或转发循环。
When multi-destination TRILL Data packets for a specific Data Label are received from the campus, it is important that exactly one RBridge out of the AAE group let through each multi-destination
当从校园接收到特定数据标签的多目的地TRILL数据包时，AAE组中只有一个RBridge通过每个多目的地是很重要的
packet so that no duplication will happen. The LAALP will have defined its selection function (using hashing or an election algorithm) to designate a forwarder for a multi-destination frame. Since AAE member RBridges support the LAALP, they are able to utilize that selection function to determine the single exit point. If the output of the selection function points to the port attached to the receiving RBridge itself (i.e., the packet should be egressed out of this node), the receiving RBridge MUST egress this packet for that AAE group. Otherwise, the packet MUST NOT be egressed for that AAE group. (For ports that lead to non-AAE links, the receiving RBridge determines whether to egress the packet or not, according to [RFC6325], which is updated by [RFC7172].)
这样就不会发生重复。LAALP将定义其选择函数（使用散列或选择算法）为多目的帧指定转发器。由于AAE成员RBridge支持LAALP，因此它们能够利用该选择功能来确定单个出口点。如果选择功能的输出指向连接到接收RBridge本身的端口（即，数据包应该从该节点中退出），则接收RBridge必须针对该AAE组退出该数据包。否则，该AAE组的数据包不得退出。（对于导致非AAE链路的端口，接收RBridge根据[RFC6325]确定是否退出数据包，该数据包由[RFC7172]更新。）
When a multi-destination frame originated from an LAALP is ingressed by an RBridge of an AAE group, distributed to the TRILL network, and then received by another RBridge in the same AAE group, it is important that this receiving RBridge does not egress this frame back to this LAALP. Otherwise, it will cause a forwarding loop (echo). The well-known "split horizon" technique (as discussed in Section 2.2.1 of [RFC1058]) is used to eliminate the echo issue.
当源自LAALP的多目的地帧由AAE组的RBridge进入、分布到TRILL网络，然后由同一AAE组中的另一RBridge接收时，重要的是，该接收RBridge不将该帧返回该LAALP。否则，它将导致转发循环（echo）。众所周知的“分割地平线”技术（如[RFC1058]第2.2.1节所述）用于消除回波问题。
RBridges in the AAE group need to perform split horizon based on the ingress RBridge nickname plus the VLAN of the TRILL Data packet. They need to set up per-port filtering lists consisting of the tuple of <ingress nickname, VLAN>. Packets with information matching any entry in the filtering list MUST NOT be egressed out of that port. The information for such filters is obtained by listening to the AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVs, as defined in Section 4.1.2. Note that all enabled VLANs MUST be consistent on all ports connected to an LAALP. So, the enabled VLANs need not be included in these TRILL APPsub-TLVs. They can be locally obtained from the port attached to that LAALP. By parsing these APPsub-TLVs, the receiving RBridge discovers all other RBridges connected to the same LAALP. The Sender Nickname of the originating RBridge will be added to the filtering list of the port attached to the LAALP. For example, RB3 in Figure 1 will set up a filtering list that looks like {<RB1, VLAN 10>, <RB2, VLAN 10>} on its port attached to LAALP1. According to split horizon, TRILL Data packets within VLAN 10 ingressed by RB1 or RB2 will not be egressed out of this port.
AAE组中的RBridge需要基于入口RBridge昵称加上TRILL数据包的VLAN执行拆分地平线。他们需要设置每个端口的过滤列表，由<ingress昵称，VLAN>的元组组成。信息与筛选列表中的任何条目匹配的数据包不得从该端口退出。通过收听第4.1.2节中定义的AA-LAALP-GROUP-RBRINGS TRILL APPsub TLV，可获得此类过滤器的信息。请注意，所有启用的VLAN必须在连接到LAALP的所有端口上保持一致。因此，启用的VLAN不需要包含在这些TRILL APPsub TLV中。它们可以从连接到LAALP的端口本地获取。通过解析这些APPsub TLV，接收RBridge发现连接到同一LAALP的所有其他RBridge。原始RBridge的发送方昵称将添加到连接到LAALP的端口的筛选列表中。例如，图1中的RB3将在其连接到LAALP1的端口上设置一个类似{<RB1，VLAN 10>，<RB2，VLAN 10>}的过滤列表。根据split horizon，由RB1或RB2进入的VLAN 10内的TRILL数据包不会从该端口流出。
When there are multiple LAALPs connected to the same RBridge, these LAALPs may have VLANs that overlap. Here, a VLAN overlap means that this VLAN ID is enabled by multiple LAALPs. A customer may require that hosts within these overlapped VLANs communicate with each other.
当有多个LAALP连接到同一个RBridge时，这些LAALP可能有重叠的VLAN。这里，VLAN重叠意味着该VLAN ID由多个LAALP启用。客户可能要求这些重叠VLAN内的主机相互通信。
Appendix A provides several scenarios to explain how hosts communicate within the overlapped VLANs and how split horizon happens.
附录A提供了几个场景来解释主机如何在重叠的VLAN内通信以及如何发生拆分。
If a sub-link of the LAALP fails while remote RBridges continue to send packets towards the failed port, a black-hole happens. If the AAE member RBridge with that failed port starts to redirect the packets to other member RBridges for delivery, triangular forwarding occurs.
如果LAALP的子链路出现故障，而远程RBridge继续向故障端口发送数据包，则会发生黑洞。如果端口发生故障的AAE成员RBridge开始将数据包重定向到其他成员RBridge进行传递，则会发生三角转发。
The member RBridge attached to the failed sub-link makes use of the ESADI protocol to flush those MAC addresses affected by the failure, as defined in Section 5.2 of [RFC7357]. After doing that, no packets will be sent towards the failed port, and hence no black-hole will happen. Nor will the member RBridge need to redirect packets to other member RBridges; thus, triangular forwarding is avoided.
按照[RFC7357]第5.2节的定义，连接到故障子链路的成员RBridge使用ESADI协议刷新受故障影响的MAC地址。这样做之后，将不会向故障端口发送数据包，因此不会发生黑洞。成员RBridge也不需要将数据包重定向到其他成员RBridge；因此，避免了三角转发。
Since a remote RBridge can see multiple attachments of one MAC address in ESADI, this remote RBridge can choose to spread the traffic towards the AAE members on a per-flow basis. Each of them is able to act as the egress point. In doing this, the forwarding paths need not be limited to the least-cost path selection from the ingress RBridge to the AAE RBridges. The traffic load from the remote RBridge towards the AAE RBridges can be balanced based on a pseudorandom selection method (see Section 4.1.3).
由于远程RBridge可以在ESADI中看到一个MAC地址的多个附件，因此该远程RBridge可以选择在每个流的基础上向AAE成员分发流量。它们中的每一个都可以充当出口点。在这样做时，转发路径不需要限于从入口RBridge到AAE RBridge的最小成本路径选择。从远程RBridge到AAE RBridge的交通负荷可以基于伪随机选择方法进行平衡（见第4.1.3节）。
Note that the load-balance method adopted at a remote ingress RBridge is not to replace the load-balance mechanism of LAALP. These two load-spreading mechanisms should take effect separately.
请注意，远程入口RBridge采用的负载平衡方法并不是要取代LAALP的负载平衡机制。这两种荷载分散机制应分别生效。
With Option A, multiple attachments need to be recorded for a MAC address learned from AAE RBridges. More entries may be consumed in the MAC learning table. However, MAC addresses attached to an LAALP are usually only a small part of all MAC addresses in the whole TRILL campus. As a result, the extra table memory space required by multi-attached MAC addresses can usually be accommodated in an RBridge's unused MAC table space.
使用选项A时，需要为从AAE RBridges学习到的MAC地址记录多个附件。MAC学习表中可能会消耗更多条目。然而，连接到LAALP的MAC地址通常只是整个TRILL校园中所有MAC地址的一小部分。因此，多连接MAC地址所需的额外表内存空间通常可以容纳在RBridge未使用的MAC表空间中。
With Option B, remote RBridges will keep the multiple attachments of a MAC address in the ESADI link-state databases, which are usually maintained by software. In the MAC table, which is normally implemented in hardware, an RBridge still establishes only one entry for each MAC address.
使用选项B，远程RBridges将在ESADI链路状态数据库中保留MAC地址的多个附件，该数据库通常由软件维护。在通常在硬件中实现的MAC表中，RBridge仍然只为每个MAC地址建立一个条目。
The Extended TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document are to be used in an Extended Level 1 Flooding Scope (E-L1FS) PDU [RFC7356] [RFC7780]. For those RBridges that do not support E-L1FS, the EXTENDED-RBRIDGE-CAP TRILL APPsub-TLV will not be sent out either, and MAC multi-attach active-active is not supported.
本文件第4.1.2节、第4.1.3节和第4.2节中定义的扩展TLV将用于扩展1级洪水范围（E-L1FS）PDU[RFC7356][RFC7780]。对于不支持E-L1FS的RBRIDGE，也不会发送EXTENDED-RBRIDGE-CAP TRILL APPsub TLV，并且不支持MAC multi-attach active。
For security considerations pertaining to extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357].
有关TRILL ESADI传输的扩展的安全注意事项，请参阅[RFC7357]中的安全注意事项部分。
For extensions not transported by TRILL ESADI, RBridges may be configured to include the IS-IS Authentication TLV (10) in the IS-IS PDUs to use IS-IS security [RFC5304] [RFC5310].
对于不是由TRILL ESADI传输的扩展，RBridge可以配置为在IS-IS PDU中包括IS-IS认证TLV（10），以使用IS-IS安全[RFC5304][RFC5310]。
Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, AAE groups is proprietary. In environments where the above authentication is not adopted, a rogue RBridge that insinuates itself into an AAE group can disrupt end-station traffic flowing into or out of that group. For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group.
由于当前部署的LAALP[RFC7379]是专有的，因此AAE组成员资格和内部管理的安全性是专有的。在不采用上述身份验证的环境中，潜入AAE组的恶意RBridge会中断流入或流出该组的终端站流量。例如，如果组中有N个rbridge，则它通常可以控制流出该组的1/N的通信量和流入该组的类似数量的单播通信量。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
IANA has allocated three new types under the TRILL GENINFO TLV [RFC7357] for the TRILL APPsub-TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document. The following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on the TRILL Parameters IANA web page.
IANA在TRILL GENINFO TLV[RFC7357]下为本文件第4.1.2、4.1.3和4.2节中定义的TRILL APPsub TLV分配了三种新类型。以下条目已添加到TRILL Parameters IANA网页上的“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中。
Type Name Reference
---- ---- ---------
252 AA-LAALP-GROUP-RBRIDGES RFC 7782
253 AA-LAALP-GROUP-MAC RFC 7782
254 EXTENDED-RBRIDGE-CAP RFC 7782
Type Name Reference
---- ---- ---------
252 AA-LAALP-GROUP-RBRIDGES RFC 7782
253 AA-LAALP-GROUP-MAC RFC 7782
254 EXTENDED-RBRIDGE-CAP RFC 7782
IANA has created a registry under the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
IANA在“大量链接透明互连（TRILL）参数”注册表下创建了一个注册表，如下所示：
Name: Extended RBridge Capabilities
名称：扩展RBridge功能
Registration Procedure: Expert Review
登记程序：专家审评
Reference: RFC 7782
参考：RFC 7782
Bit Mnemonic Description Reference
---- -------- ----------- ---------
0 E Option B Support RFC 7782
1 H Option A Support RFC 7782
2-63 - Unassigned
Bit Mnemonic Description Reference
---- -------- ----------- ---------
0 E Option B Support RFC 7782
1 H Option A Support RFC 7782
2-63 - Unassigned
IANA has allocated two flag bits, with mnemonic "AA", as follows:
IANA分配了两个标志位，带有助记符“AA”，如下所示：
One flag bit is allocated from the Interested VLANs Flag Bits.
从感兴趣的VLAN标志位分配一个标志位。
Bit Mnemonic Description Reference
--- -------- ----------- ---------
16 AA VLANs for Active-Active RFC 7782
Bit Mnemonic Description Reference
--- -------- ----------- ---------
16 AA VLANs for Active-Active RFC 7782
One flag bit is allocated from the Interested Labels Flag Bits.
从感兴趣的标签标志位分配一个标志位。
Bit Mnemonic Description Reference
--- -------- ----------- ---------
4 AA FGLs for Active-Active RFC 7782
Bit Mnemonic Description Reference
--- -------- ----------- ---------
4 AA FGLs for Active-Active RFC 7782
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[802.1AX]IEEE，“局域网和城域网的IEEE标准-链路聚合”，IEEE标准802.1AX-2014，DOI 10.1109/IEEESTD.2014.7055197，2014年12月。
[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>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 6165，DOI 10.17487/RFC6165，2011年4月<http://www.rfc-editor.org/info/rfc6165>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 6439，DOI 10.17487/RFC6439，2011年11月<http://www.rfc-editor.org/info/rfc6439>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（颤音）：邻接”，RFC 7177，DOI 10.17487/RFC7177，2014年5月<http://www.rfc-editor.org/info/rfc7177>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<http://www.rfc-editor.org/info/rfc7780>.
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, DOI 10.17487/RFC1058, June 1988, <http://www.rfc-editor.org/info/rfc1058>.
[RFC1058]Hedrick，C.，“路由信息协议”，RFC1058，DOI 10.17487/RFC1058，1988年6月<http://www.rfc-editor.org/info/rfc1058>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，DOI 10.17487/RFC5304，2008年10月<http://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379]Li，Y.，Hao，W.，Perlman，R.，Hudson，J.，和H.Zhai，“大量链路透明互连（TRILL）边缘主动连接的问题陈述和目标”，RFC 7379，DOI 10.17487/RFC7379，2014年10月<http://www.rfc-editor.org/info/rfc7379>.
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <http://www.rfc-editor.org/info/rfc7781>.
[RFC7781]翟，H.，Senevirathne，T.，Perlman，R.，张，M.，和Y.Li，“大量链路的透明互连（TRILL）：主动-主动访问的伪昵称”，RFC 7781，DOI 10.17487/RFC7781，2016年2月<http://www.rfc-editor.org/info/rfc7781>.
[TRILL-MT] Eastlake 3rd, D., Zhang, M., Banerjee, A., and V. Manral, "TRILL: Multi-Topology", Work in Progress, draft-ietf-trill-multi-topology-00, September 2015.
[TRILL-MT]Eastlake 3rd，D.，Zhang，M.，Banerjee，A.，和V.Manral，“TRILL:Multi-Topology”，正在进行的工作，草案-ietf-TRILL-Multi-Topology-00，2015年9月。
+------------------+ +------------------+ +------------------+
| RB1 | | RB2 | | RB3 |
+------------------+ +------------------+ +------------------+
L1 L2 L3 L1 L2 L3 L1 L2 L3
VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN
B1 B2 B10 B1 B2 B20 B1 B2 B30
+------------------+ +------------------+ +------------------+
| RB1 | | RB2 | | RB3 |
+------------------+ +------------------+ +------------------+
L1 L2 L3 L1 L2 L3 L1 L2 L3
VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN
B1 B2 B10 B1 B2 B20 B1 B2 B30
Figure 2: An Example Topology to Explain Split Horizon
图2：解释拆分地平线的拓扑示例
Suppose that RB1, RB2, and RB3 are the active-active group connecting LAALP1 and LAALP2. LAALP1 and LAALP2 are connected to B1 and B2 at their other ends. Suppose that all these RBridges use port L1 to connect LAALP1 while they use port L2 to connect LAALP2. Assume that all three L1 ports enable VLANs 10-20 while all three L2 ports enable VLANs 15-25, so that there is an overlap of VLANs 15-20. A customer may require that hosts within these overlapped VLANs communicate with each other. That is, hosts attached to B1 in VLANs 15-20 need to communicate with hosts attached to B2 in VLANs 15-20. Assume that the remote plain RBridge RB4 also has hosts attached in VLANs 15-20 that need to communicate with those hosts in these VLANs attached to B1 and B2.
假设RB1、RB2和RB3是连接LAALP1和LAALP2的活性基团。LAALP1和LAALP2在其另一端连接到B1和B2。假设所有这些RBridge使用端口L1连接LAALP1，而使用端口L2连接LAALP2。假设所有三个L1端口启用VLAN 10-20，而所有三个L2端口启用VLAN 15-25，因此VLAN 15-20存在重叠。客户可能要求这些重叠VLAN内的主机相互通信。也就是说，连接到VLAN 15-20中B1的主机需要与连接到VLAN 15-20中B2的主机通信。假设远程普通RBridge RB4还有连接在VLAN 15-20中的主机，这些主机需要与连接到B1和B2的VLAN中的主机通信。
There are two major requirements:
有两个主要要求：
1. Frames ingressed from RB1-L1-VLANs 15-20 MUST NOT be egressed out of ports RB2-L1 and RB3-L1.
1. 从RB1-L1-VLAN 15-20进入的帧不得从端口RB2-L1和RB3-L1退出。
2. At the same time, frames coming from B1-VLANs 15-20 should reach B2-VLANs 15-20.
2. 同时，来自B1 VLAN 15-20的帧应到达B2 VLAN 15-20。
RB3 stores the information for split horizon on its ports L1 and L2.
RB3将拆分地平线的信息存储在其端口L1和L2上。
On L1: {<ingress_nickname_RB1, VLANs 10-20>, <ingress_nickname_RB2, VLANs 10-20>}.
在L1上：{<ingress\u昵称\u RB1，VLAN 10-20>，<ingress\u昵称\u RB2，VLAN 10-20>。
On L2: {<ingress_nickname_RB1, VLANs 15-25>, <ingress_nickname_RB2, VLANs 15-25>}.
在L2上：{<ingress_昵称_RB1，VLAN 15-25>，<ingress_昵称_RB2，VLAN 15-25>。
Five clarification scenarios follow:
以下是五种澄清情况：
a. Suppose that RB2 or RB3 receives a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB1. RB3 is the single exit point (selected according to the hashing function of LAALP) for this packet. On ports L1 and L2, RB3 has covered <ingress_nickname_RB1, VLAN 15>, so that RB3 will not egress this packet out of either L1 or L2. Here, "split horizon" happens.
a. 假设RB2或RB3接收到一个带有VLAN 15和入口昵称RB1的TRILL多目的地数据包。RB3是该数据包的单个出口点（根据LAALP的哈希函数选择）。在端口L1和L2上，RB3已覆盖<ingress\u昵称\u RB1，VLAN 15>，因此RB3不会将此数据包从L1或L2中传出。在这里，“分裂地平线”发生了。
Beforehand, RB1 obtains a native frame on port L1 from B1 in VLAN 15. RB1 determines that it should be forwarded as a multi-destination packet across the TRILL campus. Also, RB1 replicates this frame without TRILL encapsulation and sends it out of port L2, so that B2 will get this frame.
事先，RB1从VLAN 15中的B1获得端口L1上的本机帧。RB1确定它应该作为多目标数据包在TRILL校园中转发。此外，RB1复制此帧而不进行颤音封装，并将其从端口L2发送出去，以便B2获得此帧。
b. Suppose that RB2 or RB3 receives a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB4. RB3 is the single exit point. On ports L1 and L2, since RB3 has not stored any tuple with ingress_nickname_RB4, RB3 will decapsulate the packet and egress it out of both ports L1 and L2. So, both B1 and B2 will receive the frame.
b. 假设RB2或RB3接收到一个带有VLAN 15和入口昵称RB4的TRILL多目的地数据包。RB3是单一出口点。在端口L1和L2上，由于RB3未存储任何具有入口_昵称_RB4的元组，RB3将解除数据包的封装并将其从端口L1和L2中取出。因此，B1和B2都将接收帧。
c. Suppose that there is a plain LAN link port L3 on RB1, RB2, and RB3, connecting to B10, B20, and B30, respectively. These L3 ports happen to be configured with VLAN 15. On port L3, RB2 and RB3 store no information for split horizon for AAE (since this port has not been configured to be in any LAALP). They will egress the packet ingressed from RB1-L1 in VLAN 15.
c. 假设RB1、RB2和RB3上有一个普通LAN链路端口L3，分别连接到B10、B20和B30。这些L3端口恰好配置了VLAN 15。在端口L3上，RB2和RB3不存储AAE拆分地平线的信息（因为此端口尚未配置为位于任何LAALP中）。它们将退出从VLAN 15中的RB1-L1进入的数据包。
d. If a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, port RB1-L3 will not egress packets with ingress_nickname_RB1. RB1 needs to replicate this frame without encapsulation and sends it out of port L3. This kind of "bounce" behavior for multi-destination frames is just as specified in paragraph 3 of Section 4.6.1.2 of [RFC6325].
d. 如果数据包是从带有VLAN 15的RB1-L1或RB1-L2进入的，则端口RB1-L3将不会退出带有入口\昵称\ RB1的数据包。RB1需要在不封装的情况下复制此帧，并将其从端口L3发送出去。多目标帧的这种“反弹”行为如[RFC6325]第4.6.1.2节第3段所述。
e. If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2 cannot egress packets with VLAN 15 and ingress_nickname_RB1, RB1 needs to replicate this frame without encapsulation and sends it out of ports L1 and L2. (Also see paragraph 3 of Section 4.6.1.2 of [RFC6325].)
e. 如果数据包是从RB1-L3进入的，由于RB1-L1和RB1-L2无法退出带有VLAN 15和入口昵称_RB1的数据包，RB1需要在不封装的情况下复制此帧，并将其从端口L1和L2发送出去。（另见[RFC6325]第4.6.1.2节第3段）
Acknowledgments
致谢
The authors would like to thank the following people for their comments and suggestions: Andrew Qu, Donald Eastlake, Erik Nordmark, Fangwei Hu, Liang Xia, Weiguo Hao, Yizhou Li, and Mukhtiar Shaikh.
作者感谢以下人士的评论和建议：安德鲁·瞿、唐纳德·伊斯特莱克、埃里克·诺德马克、胡方伟、梁霞、魏国豪、李益周和穆赫蒂亚尔·谢赫。
Authors' Addresses
作者地址
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
Radia Perlman EMC 2010美国华盛顿州贝尔维尤市东北第256大道200号，邮编：98007
Email: radia@alum.mit.edu
Email: radia@alum.mit.edu
Hongjun Zhai Nanjing Astute Software Technology Co. Ltd 57 Andemen Avenue, Yuhuatai District Nanjing, Jiangsu 210016 China
中国江苏省南京市雨花台区安第门大道57号南京骏智软件科技有限公司邮编：210016
Email: honjun.zhai@tom.com
Email: honjun.zhai@tom.com
Muhammad Durrani Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 United States
Muhammad Durrani Cisco Systems 170美国加利福尼亚州圣何塞市西塔斯曼博士，邮编95134
Email: mdurrani@cisco.com
Email: mdurrani@cisco.com
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India
苏杰·古普塔（Sujay Gupta）印度班加罗尔马哈德瓦普拉百周年纪念酒店
Email: sujay.gupta@ipinfusion.com
Email: sujay.gupta@ipinfusion.com