Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 7783 Consultant
Updates: 6325 J. Pathangi
Category: Standards Track Dell
ISSN: 2070-1721 J. Hudson
Brocade
February 2016
Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 7783 Consultant
Updates: 6325 J. Pathangi
Category: Standards Track Dell
ISSN: 2070-1721 J. Hudson
Brocade
February 2016
Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)
用于大量链路（TRILL）透明互连的协调多播树（CMT）
Abstract
摘要
TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide VLAN-based load sharing with an active-standby model. High-performance applications require an active-active load-sharing model. The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.
TRILL（大量链路的透明互连）通过为一组VLAN选择指定的转发器，促进与非TRILL网络的无环连接。指定的转发器通过主备模式提供基于VLAN的负载共享。高性能应用需要主动负载共享模型。通过使用单个虚拟RBridge（也称为虚拟路由桥或虚拟TRILL交换机）表示任何给定的非TRILL网络，可以实现主动-主动负载共享模型。用单个RBridge虚拟表示非TRILL网络在多目标RPF（反向路径转发）检查计算中面临严重挑战。本文档规定了在TRILL园区内构建协调多播树（CMT）以解决相关RPF问题所需的增强功能。CMT只需要软件升级，在选择与给定TRILL多目的地分发树关联的所需路径时为RBridges提供了灵活性。本文档更新了RFC 6325。
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/rfc7783.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7783.
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
1.1. Scope and Applicability ....................................4
2. Conventions Used in This Document ...............................5
2.1. Acronyms and Phrases .......................................5
3. The Affinity Sub-TLV ............................................6
4. Multicast Tree Construction and Use of Affinity Sub-TLV .........6
4.1. Update to RFC 6325 .........................................7
4.2. Announcing Virtual RBridge Nickname ........................8
4.3. Affinity Sub-TLV Capability ................................8
5. Theory of Operation .............................................8
5.1. Distribution Tree Assignment ...............................8
5.2. Affinity Sub-TLV Advertisement .............................9
5.3. Affinity Sub-TLV Conflict Resolution .......................9
5.4. Ingress Multi-Destination Forwarding ......................10
5.4.1. Forwarding when n < k ..............................10
5.5. Egress Multi-Destination Forwarding .......................11
5.5.1. Traffic Arriving on an Assigned Tree to RBk-RBv ....11
5.5.2. Traffic Arriving on Other Trees ....................11
5.6. Failure Scenarios .........................................11
5.6.1. Edge RBridge RBk Failure ...........................11
5.7. Backward Compatibility ....................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Acknowledgments ...................................................16
Contributors ......................................................16
Authors' Addresses ................................................16
1. Introduction ....................................................3
1.1. Scope and Applicability ....................................4
2. Conventions Used in This Document ...............................5
2.1. Acronyms and Phrases .......................................5
3. The Affinity Sub-TLV ............................................6
4. Multicast Tree Construction and Use of Affinity Sub-TLV .........6
4.1. Update to RFC 6325 .........................................7
4.2. Announcing Virtual RBridge Nickname ........................8
4.3. Affinity Sub-TLV Capability ................................8
5. Theory of Operation .............................................8
5.1. Distribution Tree Assignment ...............................8
5.2. Affinity Sub-TLV Advertisement .............................9
5.3. Affinity Sub-TLV Conflict Resolution .......................9
5.4. Ingress Multi-Destination Forwarding ......................10
5.4.1. Forwarding when n < k ..............................10
5.5. Egress Multi-Destination Forwarding .......................11
5.5.1. Traffic Arriving on an Assigned Tree to RBk-RBv ....11
5.5.2. Traffic Arriving on Other Trees ....................11
5.6. Failure Scenarios .........................................11
5.6.1. Edge RBridge RBk Failure ...........................11
5.7. Backward Compatibility ....................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Acknowledgments ...................................................16
Contributors ......................................................16
Authors' Addresses ................................................16
TRILL (Transparent Interconnection of Lots of Links), as presented in [RFC6325] and other related documents, provides methods of utilizing all available paths for active forwarding, with minimum configuration. TRILL utilizes IS-IS (Intermediate System to Intermediate System) [IS-IS] as its control plane and uses a TRILL Header that includes a Hop Count.
如[RFC6325]和其他相关文件所述，TRILL（大量链路的透明互连）提供了利用所有可用路径进行主动转发的方法，且配置最少。TRILL使用IS-IS（中间系统到中间系统）[IS-IS]作为其控制平面，并使用包含跳数的TRILL报头。
[RFC6325], [RFC7177], and [RFC6439] provide methods for interoperability between TRILL and Ethernet end stations and bridged networks. [RFC6439] provides an active-standby solution, where only one of the RBridges (aka Routing Bridges or TRILL switches) on a link with end stations is in the active forwarding state for end-station traffic for any given VLAN. That RBridge is referred to as the Appointed Forwarder (AF). All frames ingressed into a TRILL network via the AF are encapsulated with the TRILL Header with a nickname held by the ingress AF RBridge. Due to failures, reconfigurations, and other network dynamics, the AF for any set of VLANs may change. RBridges maintain forwarding tables that contain bindings for destination Media Access Control (MAC) addresses and Data Labels (VLAN or Fine-Grained Labels (FGLs)) to egress RBridges. In the event of an AF change, forwarding tables of remote RBridges may continue to forward traffic to the previous AF. That traffic may get discarded at the egress, causing traffic disruption.
[RFC6325]、[RFC7177]和[RFC6439]提供了TRILL和以太网终端站以及桥接网络之间的互操作性方法。[RFC6439]提供了一种主备解决方案，其中对于任何给定VLAN的端站流量，与端站连接的链路上只有一个RBridge（也称为路由桥或TRILL交换机）处于活动转发状态。RBridge被称为指定货运代理（AF）。通过AF进入TRILL网络的所有帧用TRILL报头封装，TRILL报头具有入口AF RBridge持有的昵称。由于故障、重新配置和其他网络动态，任何一组VLAN的AF都可能发生变化。RBridges维护转发表，其中包含目标媒体访问控制（MAC）地址和数据标签（VLAN或细粒度标签（FGL））的绑定，以退出RBridges。在AF改变的情况下，远程rbridge的转发表可以继续将业务转发到前一AF。该业务可能在出口处被丢弃，导致业务中断。
High-performance applications require resiliency during failover. The active-active forwarding model minimizes impact during failures and maximizes the available network bandwidth. A typical deployment scenario, depicted in Figure 1, may have end stations and/or bridges attached to the RBridges. These devices typically are multi-homed to several RBridges and treat all of the uplinks independently using a Local Active-Active Link Protocol (LAALP) [RFC7379], such as a single Multi-Chassis Link Aggregation (MC-LAG) bundle or Distributed Resilient Network Interconnect [802.1AX]. The AF designation presented in [RFC6439] requires each of the edge RBridges to exchange TRILL Hello packets. By design, an LAALP does not forward packets received on one of the member ports of the MC-LAG to other member ports of the same MC-LAG. As a result, the AF designation methods presented in [RFC6439] cannot be applied to the deployment scenario depicted in Figure 1.
高性能应用程序在故障切换期间需要恢复能力。主动转发模型将故障期间的影响降至最低，并使可用网络带宽最大化。图1所示的典型部署场景可能具有连接到RBridge的终端站和/或网桥。这些设备通常是多宿多个RBridge，并使用本地主动链路协议（LAALP）[RFC7379]独立处理所有上行链路，例如单个多机箱链路聚合（MC-LAG）捆绑或分布式弹性网络互连[802.1AX]。[RFC6439]中的AF指定要求每个边缘RBridge交换TRILL Hello数据包。根据设计，LAALP不会将在MC-LAG的一个成员端口上接收的数据包转发到同一MC-LAG的其他成员端口。因此，[RFC6439]中介绍的AF指定方法无法应用于图1所示的部署场景。
An active-active load-sharing model can be implemented by representing the edge of the network connected to a specific edge group of RBridges by a single virtual RBridge. Each virtual RBridge MUST have a nickname unique within its TRILL campus. In addition to an active-active forwarding model, there may be other applications that may require similar representations.
通过用单个虚拟RBridge表示连接到RBridge的特定边缘组的网络边缘，可以实现主动负载共享模型。每个虚拟RBridge必须在其TRILL校园内有一个唯一的昵称。除了主动转发模型外，还可能存在其他可能需要类似表示的应用程序。
Sections 4.5.1 and 4.5.2 of [RFC6325], as updated by [RFC7780], specify distribution tree calculation and RPF (Reverse Path Forwarding) check calculation algorithms for multi-destination forwarding. These algorithms strictly depend on link cost and parent RBridge priority. As a result, based on the network topology, it may be possible that a given edge RBridge, if it is forwarding on behalf of the virtual RBridge, may not have a candidate multicast tree on which it (the edge RBridge) can forward traffic, because there is no tree for which the virtual RBridge is a leaf node from the edge RBridge.
[RFC6325]第4.5.1节和第4.5.2节（由[RFC7780]更新）规定了多目标转发的分布树计算和RPF（反向路径转发）检查计算算法。这些算法严格依赖于链路开销和父RBridge优先级。结果，基于网络拓扑，如果给定边缘RBridge代表虚拟RBridge转发，则可能不具有其（边缘RBridge）可以转发业务的候选多播树，因为不存在虚拟RBridge是来自边缘RBridge的叶节点的树。
In this document, we present a method that allows RBridges to specify the path of association for real or virtual child nodes to distribution trees. Remote RBridges calculate their forwarding tables and derive the RPF for distribution trees based on the distribution tree association advertisements. In the absence of distribution tree association advertisements, remote RBridges derive the SPF (Shortest Path First) based on the algorithm specified in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. This document updates [RFC6325] by changing, when Coordinated Multicast Trees (CMT) sub-TLVs are present, [RFC6325] mandatory provisions as to how distribution trees are constructed.
在本文中，我们提出了一种方法，允许RBridges指定真实或虚拟子节点到分布树的关联路径。远程RBridge根据分发树关联广告计算其转发表并导出分发树的RPF。在没有分发树关联广告的情况下，远程RBF根据[RFC6325]第4.5.1节规定的算法推导SPF（最短路径优先），并由[RFC7780]更新。本文件更新了[RFC6325]，当存在协调多播树（CMT）子TLV时，更改了[RFC6325]关于如何构建分发树的强制性规定。
In addition to the above-mentioned active-active forwarding model, other applications may utilize the distribution tree association framework presented in this document to associate to distribution trees through a preferred path.
除了上述主动转发模型之外，其他应用程序还可以利用本文中提供的分发树关联框架通过优选路径关联到分发树。
This proposal requires (1) the presence of multiple multi-destination trees within the TRILL campus and (2) that all the RBridges in the network be updated to support the new Affinity sub-TLV (Section 3). It is expected that both of these requirements will be met, as they are control-plane changes and will be common deployment scenarios. In case either of the above two conditions is not met, RBridges MUST support a fallback option for interoperability. Since the fallback is expected to be a temporary phenomenon until all RBridges are upgraded, this proposal gives guidelines for such fallbacks and does not mandate or specify any specific set of fallback options.
该提案要求（1）TRILL园区内存在多个多目的地树，（2）更新网络中的所有RBridge以支持新的关联子TLV（第3节）。预计这两项要求都将得到满足，因为它们是控制平面变更，并且是常见的部署场景。如果不满足上述两个条件之一，RBridges必须支持互操作性的回退选项。由于在所有RBridge升级之前，回退预计是一种暂时现象，因此本提案为此类回退提供了指南，并不强制或指定任何特定的回退选项集。
This document specifies an Affinity sub-TLV to solve RPF issues at the active-active edge. Specific methods in this document for making use of the Affinity sub-TLV are applicable where a virtual RBridge is used to represent multiple RBridges connected to an edge Customer Equipment (CE) device through an LAALP, such as MC-LAG or some similar arrangement where the RBridges cannot see each other's Hellos.
本文档指定了一个关联子TLV，用于解决活动边缘的RPF问题。当虚拟RBridge用于表示通过LAALP连接到边缘客户设备（CE）设备的多个RBridge时，本文件中使用亲和子TLV的具体方法适用，例如MC-LAG或RBridge无法看到彼此的hello的一些类似安排。
This document does not provide other required operational elements to implement an active-active edge solution, such as MC-LAG methods. Solution-specific operational elements are outside the scope of this document and will be covered in other documents. (See, for example, [RFC7781].)
本文件不提供实施主动边缘解决方案所需的其他操作要素，如MC-LAG方法。特定于解决方案的操作要素不在本文档的范围内，将在其他文档中介绍。（例如，参见[RFC7781]。）
Examples provided in this document are for illustration purposes only.
本文件中提供的示例仅用于说明目的。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying [RFC2119] significance.
在本文件中，只有在所有大写字母中，这些单词才会以该解释出现。这些词语的小写用法不得解释为具有[RFC2119]意义。
The following acronyms and phrases are used in this document:
本文件中使用了以下首字母缩略词和短语：
AF: Appointed Forwarder [RFC6439].
AF：指定货代[RFC6439]。
CE: Customer Equipment device, that is, a device that performs forwarding based on 802.1Q bridging. This also can be an end station or a server.
CE：客户设备设备，即基于802.1Q桥接执行转发的设备。这也可以是终端站或服务器。
Data Label: VLAN or FGL.
数据标签：VLAN或FGL。
FGL: Fine-Grained Label [RFC7172].
FGL：细粒度标签[RFC7172]。
LAALP: Local Active-Active Link Protocol [RFC7379].
LAALP：本地主动链路协议[RFC7379]。
MC-LAG: Multi-Chassis Link Aggregation. A proprietary extension to [802.1AX] that facilitates connecting a group of links from an originating device (A) to a group of discrete devices (B). Device (A) treats all of the links in a given MC-LAG bundle as a single logical interface and treats all devices in Group (B) as a single logical device for all forwarding purposes. Device (A) does not forward packets received on the multi-chassis link bundle out of the same multi-chassis link bundle. Figure 1 depicts a specific use case example.
MC-LAG：多机箱链路聚合。[802.1AX]的专有扩展，有助于将一组链路从原始设备（A）连接到一组离散设备（B）。设备（A）将给定MC-LAG捆绑包中的所有链路视为单个逻辑接口，并将组（B）中的所有设备视为用于所有转发目的的单个逻辑设备。设备（A）不会将多机箱链路捆绑上接收到的数据包从同一多机箱链路捆绑中转发出去。图1描述了一个特定的用例示例。
RPF: Reverse Path Forwarding. See Section 4.5.2 of [RFC6325].
反向路径转发。见[RFC6325]第4.5.2节。
Virtual RBridge: A purely conceptual RBridge that represents an active-active edge group and is in turn represented by a nickname. For example, see [RFC7781].
虚拟RBridge：一个纯粹概念性的RBridge，表示一个活动边组，并依次由昵称表示。例如，请参见[RFC7781]。
Association of an RBridge to a multi-destination distribution tree through a specific path is accomplished by using a new IS-IS sub-TLV, the Affinity sub-TLV.
RBridge通过特定路径与多目标分发树的关联是通过使用新的is-is子TLV（关联子TLV）实现的。
The Affinity sub-TLV appears in Router Capability TLVs or MT Capability TLVs that are within Link State PDUs (LSPs), as described in [RFC7176]. [RFC7176] specifies the code point and data structure for the Affinity sub-TLV.
关联子TLV出现在链路状态PDU（LSP）内的路由器能力TLV或MT能力TLV中，如[RFC7176]所述。[RFC7176]指定关联子TLV的代码点和数据结构。
Figures 1 and 2 below show the reference topology and a logical topology using CMT to provide active-active service.
下面的图1和图2显示了使用CMT提供主动服务的参考拓扑和逻辑拓扑。
--------------------
/ \
| |
| TRILL Campus |
| |
\ /
--------------------
| | |
----- | --------
| | |
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
(| | |) <-- MC-LAG (| | |) <-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
--------------------
/ \
| |
| TRILL Campus |
| |
\ /
--------------------
| | |
----- | --------
| | |
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
(| | |) <-- MC-LAG (| | |) <-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
Figure 1: Reference Topology
图1：参考拓扑
-------------------- Sample Multicast Tree (T1)
/ \
| | |
| TRILL Campus | o RBn
| | / | \
\ / / | ---\
-------------------- RB1 o o o
| | | | RB2 RBk
| | -------------- |
| | | o RBv
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|--|--|-------------+ |
| +-|---|--+ +--------------+ |
| | | +------------------+ | |
MC-LAG -->(| | |) (| | |)<-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
-------------------- Sample Multicast Tree (T1)
/ \
| | |
| TRILL Campus | o RBn
| | / | \
\ / / | ---\
-------------------- RB1 o o o
| | | | RB2 RBk
| | -------------- |
| | | o RBv
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|--|--|-------------+ |
| +-|---|--+ +--------------+ |
| | | +------------------+ | |
MC-LAG -->(| | |) (| | |)<-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
RBv: virtual RBridge
虚拟桥
Figure 2: Example Logical Topology
图2：逻辑拓扑示例
This document updates Section 4.5.1 of [RFC6325] and changes the calculation of distribution trees, as specified below:
本文件更新了[RFC6325]第4.5.1节，并更改了分布树的计算，如下所述：
Each RBridge that desires to be the parent RBridge for a child RBridge (RBy) in a multi-destination distribution tree (Tree x) announces the desired association using an Affinity sub-TLV. The child is specified by its nickname. If an RBridge (RB1) advertises an Affinity sub-TLV designating one of its own nicknames (N1) as its "child" in some distribution tree, the effect is that nickname N1 is ignored when constructing other distribution trees. Thus, the RPF check will enforce the rule that only RB1 can use nickname N1 to do ingress/egress on Tree x. (This has no effect on least-cost path calculations for unicast traffic.)
希望成为多目标分发树（树x）中的子RBridge（RBy）的父RBridge的每个RBridge使用关联子TLV宣布所需关联。子项由其昵称指定。如果RBridge（RB1）在某个分发树中宣传将其自己的昵称（N1）之一指定为其“子”的亲缘子TLV，其效果是在构建其他分发树时忽略昵称N1。因此，RPF检查将强制执行只有RB1可以使用昵称N1在树x上进行入口/出口的规则。（这对单播流量的最低成本路径计算没有影响。）
When such an Affinity sub-TLV is present, the association specified by the Affinity sub-TLV MUST be used when constructing the multi-destination distribution tree, except in the case of a
当存在这样的关联子TLV时，在构造多目的地分发树时，必须使用关联子TLV指定的关联，但存在关联的情况除外
conflicting Affinity sub-TLV; such cases are resolved as specified in Section 5.3. In the absence of such an Affinity sub-TLV, or if there are any RBridges in the campus that do not support the Affinity sub-TLV, distribution trees are calculated as specified in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. Section 4.3 below specifies how to identify RBridges that support the Affinity sub-TLV.
冲突亲缘子TLV；此类情况按照第5.3节的规定解决。在没有此类关联子TLV的情况下，或者如果校园中有任何RBridge不支持关联子TLV，则按照[RFC6325]第4.5.1节的规定计算分发树，并由[RFC7780]更新。下文第4.3节规定了如何识别支持关联子TLV的RBridge。
Each edge RBridge (RB1 to RBk) advertises its LSP virtual RBridge nickname (RBv) by using the Nickname sub-TLV (6) [RFC7176], along with their regular nickname or nicknames.
每个边缘RBridge（RB1到RBk）通过使用昵称sub-TLV（6）[RFC7176]及其常规昵称来宣传其LSP虚拟RBridge昵称（RBv）。
It will be possible for any RBridge to determine that RBv is a virtual RBridge, because each RBridge (RB1 to RBk) that appears to be advertising that it is holding RBv is also advertising an Affinity sub-TLV asking that RBv be its child in one or more trees.
任何RBridge都有可能确定RBv是虚拟RBridge，因为似乎在宣传其持有RBv的每个RBridge（RB1到RBk）也在宣传亲缘子TLV，要求RBv在一个或多个树中作为其子树。
Virtual RBridges are ignored when determining the distribution tree roots for the campus.
在确定校园的分布树根时，将忽略虚拟RBridge。
All RBridges outside the edge group assume that multi-destination packets with their TRILL Header Ingress Nickname field set to RBv might use any of the distribution trees that any member of the edge group advertises that it might use.
边缘组之外的所有RBridge都假定，其TRILL报头入口昵称字段设置为RBv的多目的地数据包可能使用边缘组的任何成员宣传可能使用的任何分发树。
RBridges that announce the TRILL Version sub-TLV [RFC7176] and set the Affinity capability bit (Section 7) support the Affinity sub-TLV, calculation of multi-destination distribution trees, and RPF checks, as specified herein.
宣布TRILL版本子TLV[RFC7176]并设置关联能力位（第7节）的RBridge支持关联子TLV、计算多目标分发树和RPF检查，如本文所述。
Let's assume that there are n distribution trees and k edge RBridges in the edge group of interest.
Let's assume that there are n distribution trees and k edge RBridges in the edge group of interest.translate error, please retry
If n >= k
如果n>=k
Let's assume that edge RBridges are sorted in numerically ascending order by IS-IS System ID such that RB1 < RB2 < RBk. Each RBridge in the numerically sorted list is assigned a monotonically increasing number j such that RB1 = 0, RB2 = 1,
让我们假设边RBridges按IS-IS系统ID按数字升序排序，以便RB1<RB2<RBk。数字排序列表中的每个RBridge被分配一个单调递增的数字j，使得RB1=0，RB2=1，
RBi = j, and RBi + 1 = j + 1. (See Section 4.5 of [RFC6325], as updated by Section 3.4 of [RFC7780], for how tree numbers are determined.)
RBi=j，RBi+1=j+1。（参见[RFC6325]第4.5节，该节由[RFC7780]第3.4节更新，以了解如何确定树编号。）
Assign each tree to RBi such that tree number (((tree_number) % k) + 1) is assigned to edge group RBridge i for tree_number from 1 to n, where n is the number of trees, k is the number of edge group RBridges considered for tree allocation, and "%" is the integer division remainder operation.
将每棵树分配给RBi，以便将树编号（（（树编号）%k）+1）分配给树编号从1到n的边组RBridge i，其中n是树的数量，k是考虑分配树的边组RBridge的数量，“%”是整数除法余数运算。
If n < k
如果n<k
Distribution trees are assigned to edge group RBridges RB1 to RBn, using the same algorithm as the n >= k case. RBridges RBn + 1 to RBk do not participate in the active-active forwarding process on behalf of RBv.
使用与n>=k情况相同的算法，将分布树指定给边组RB1到RBn。RBn+1到RBk之间的桥接不代表RBv参与主动转发过程。
Each RBridge in the RB1 through RBk domain advertises an Affinity sub-TLV for RBv to be its child.
RB1到RBk域中的每个RBridge为RBv播发一个亲缘子TLV作为其子代。
As an example, let's assume that RB1 has chosen Trees t1 and tk + 1 on behalf of RBv.
例如，假设RB1代表RBv选择了树t1和tk+1。
RB1 advertises the Affinity sub-TLV; {RBv, Num of Trees = 2, t1, tk + 1}.
RB1宣传亲缘子TLV；{RBv，树的数量=2，t1，tk+1}。
Other RBridges in the RB1 through RBk edge group follow the same procedure.
RB1到RBk边缘组中的其他RBridge遵循相同的过程。
In TRILL, multi-destination distribution trees are built outward from the root by each RBridge so that they all derive the same set of distribution trees [RFC6325].
在TRILL中，每个RBridge从根向外构建多目的地分发树，以便它们都派生相同的分发树集[RFC6325]。
If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for RBridge RBroot to be its child in a tree rooted at RBroot, that AFFINITY RECORD is in conflict with TRILL distribution tree root determination and MUST be ignored.
如果RBridge RB1播发具有要求RBridge RBroot作为其在以RBroot为根的树中的子级的关联记录的关联子TLV，则该关联记录与TRILL分发树根确定冲突，必须忽略。
If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for nickname RBn to be its child in any tree and RB1 is not adjacent to RBn nor does nickname RBn identify RB1 itself, that AFFINITY RECORD is in conflict with the campus topology and MUST be ignored.
如果RBridge RB1播发一个关联子TLV，该关联记录要求昵称RBn在任何树中作为其子级，并且RB1与RBn不相邻，昵称RBn也没有标识RB1本身，则该关联记录与校园拓扑冲突，必须忽略。
If different RBridges advertise Affinity sub-TLVs that try to associate the same virtual RBridge as their child in the same tree or trees, those Affinity sub-TLVs are in conflict with each other for those trees. The nicknames of the conflicting RBridges are compared to identify which RBridge holds the nickname that is the highest priority to be a tree root, with the System ID as the tiebreaker.
如果不同的RBridge宣传试图将同一虚拟RBridge与其在同一树或多棵树中的子RBridge关联的关联子TLV，则这些关联子TLV在这些树中相互冲突。将对冲突RBridge的昵称进行比较，以确定哪个RBridge拥有作为树根的最高优先级的昵称，系统ID作为分界线。
The RBridge with the highest priority to be a tree root will retain the Affinity association. Other RBridges with lower priority to be a tree root MUST stop advertising their conflicting Affinity sub-TLVs, recalculate the multicast tree affinity allocation, and, if appropriate, advertise new non-conflicting Affinity sub-TLVs.
最高优先级为树根的RBridge将保留亲和关联。作为树根的优先级较低的其他RBridge必须停止公布其冲突的关联子TLV，重新计算多播树关联分配，并在适当的情况下公布新的非冲突关联子TLV。
Similarly, remote RBridges MUST honor the Affinity sub-TLV from the RBridge with the highest priority to be a tree root (using System ID as the tiebreaker in the event of conflicting priorities) and ignore the conflicting Affinity sub-TLV entries advertised by the RBridges with lower priorities to be tree roots.
类似地，远程RBridge必须将来自具有最高优先级的RBridge的关联子TLV作为树根（在优先级冲突的情况下使用系统ID作为分界线），并忽略由具有较低优先级的RBridge发布的冲突关联子TLV条目作为树根。
If there is at least one tree on which RBv has affinity via RBk, then RBk performs the following operations for multi-destination frames received from a CE node:
如果至少有一个树上的RBv通过RBk具有亲缘关系，则RBk对从CE节点接收的多目标帧执行以下操作：
1. Flood to locally attached CE nodes subjected to VLAN and multicast pruning.
1. 对本地连接的CE节点进行VLAN和多播修剪。
2. Ingress (by encapsulating with a TRILL Header) and set the Ingress Nickname field of the TRILL Header to RBv (the nickname of the virtual RBridge).
2. Ingress（通过使用TRILL头进行封装）并将TRILL头的Ingress昵称字段设置为RBv（虚拟RBridge的昵称）。
3. Forward to one of the distribution trees, Tree x, in which RBv is associated with RBk.
3. 转发到其中一个分布树，树x，其中RBv与RBk关联。
If there is no tree on which RBv can claim affinity via RBk (probably because the number of trees (n) built is less than the number of RBridges (k) announcing the Affinity sub-TLV), then RBk MUST fall back to one of the following:
如果没有RBv可以通过RBk声明亲缘关系的树（可能是因为构建的树数（n）小于宣布亲缘关系子TLV的RBridge数（k）），则RBk必须返回到以下任一情况：
1. This RBridge (RBk) should stop forwarding frames from the CE nodes and should mark its port towards those CE nodes as disabled. This will prevent the CE nodes from forwarding data to this RBridge. Thus, the CE nodes will only use those RBridges that have been assigned a tree.
1. 此RBridge（RBk）应停止从CE节点转发帧，并应将其指向这些CE节点的端口标记为禁用。这将阻止CE节点将数据转发到此RBridge。因此，CE节点将仅使用已分配了树的RBridge。
-OR-
-或-
2. This RBridge tunnels multi-destination frames received from attached native devices to an RBridge RBy that has an assigned tree. The tunnel destination should forward it to the TRILL network and also to its local access links. (The mechanism of tunneling and handshaking between the tunnel source and destination are out of scope for this specification and may be addressed in other documents, such as [ChannelTunnel].)
2. 此RBridge将从连接的本机设备接收的多目标帧隧道到具有指定树的RBridge RBy。隧道目的地应将其转发至TRILL网络及其本地接入链路。（隧道源和目的地之间的隧道和握手机制不在本规范的范围内，可在其他文件中讨论，如[ChannelTunnel]。）
The above fallback options may be specific to the active-active forwarding scenario. However, as stated above, the Affinity sub-TLV may be used in other applications. In such an event, the application SHOULD specify applicable fallback options.
上述回退选项可能特定于活动转发场景。然而，如上所述，亲和子TLV可用于其他应用中。在这种情况下，应用程序应指定适用的回退选项。
Multi-destination frames arriving at RBk on a Tree x, where RBk has announced the affinity of RBv via x, MUST be forwarded to CE members of RBv that are in the frame's VLAN. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325].
到达树x上RBk的多目标帧（其中RBk已通过x宣布RBv的亲缘关系）必须转发给帧VLAN中RBv的CE成员。转发到不属于虚拟RBridge昵称（RBv）表示的网络的其他终端节点和RBridge必须遵循[RFC6325]中指定的转发规则。
Multi-destination frames arriving at RBk on a Tree y, where RBk has not announced the affinity of RBv via y, MUST NOT be forwarded to CE members of RBv. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325].
到达树y上RBk的多目的帧，其中RBk未通过y宣布RBv的亲缘关系，不得转发给RBv的CE成员。转发到不属于虚拟RBridge昵称（RBv）表示的网络的其他终端节点和RBridge必须遵循[RFC6325]中指定的转发规则。
The failure recovery algorithm below is presented only as a guideline. An active-active edge group MAY use other failure recovery algorithms; it is recommended that only one algorithm be used in an edge group at a time. Details of such algorithms are outside the scope of this document.
以下故障恢复算法仅供参考。活动边缘组可以使用其他故障恢复算法；建议一次只能在边缘组中使用一种算法。此类算法的详细信息不在本文件范围内。
Each of the member RBridges of a given virtual RBridge edge group is aware of its member RBridges through configuration, LSP advertisements, or some other method.
给定虚拟RBridge边缘组的每个成员RBridge通过配置、LSP广告或某种其他方法知道其成员RBridge。
Member RBridges detect nodal failure of a member RBridge through IS-IS LSP advertisements or lack thereof.
构件RBridge通过IS-IS LSP广告或其缺失检测构件RBridge的节点故障。
Upon detecting a member failure, each of the member RBridges of the RBv edge group start recovery timer T_rec for failed RBridge RBi. If the previously failed RBridge RBi has not recovered after the expiry of timer T_rec, member RBridges perform the distribution tree assignment algorithm specified in Section 5.1. Each of the member RBridges re-advertises the Affinity sub-TLV with the new tree assignment. This action causes the campus to update the tree calculation with the new assignment.
在检测到成员故障时，RBv边缘组的每个成员RBridge启动故障RBridge RBi的恢复计时器T_rec。如果先前失败的RBridge RBi在计时器T_rec到期后仍未恢复，则成员RBridge将执行第5.1节中规定的分发树分配算法。每个成员rbridge使用新的树分配重新播发关联子TLV。此操作导致校园使用新分配更新树计算。
RBi, upon startup, advertises its presence through IS-IS LSPs and starts a timer T_i. Other member RBridges of the edge group, detecting the presence of RBi, start a timer T_j.
RBi在启动时，通过IS-IS LSP宣传其存在，并启动计时器T_i。边缘组的其他成员rbridge检测到RBi的存在，启动计时器T_j。
Upon expiry of timer T_j, other member RBridges recalculate the multi-destination tree assignment and advertise the related trees using the Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculates the multi-destination tree assignment and advertises the related trees using the Affinity sub-TLV.
计时器T_j到期后，其他成员rbridge重新计算多目标树分配，并使用关联子TLV公布相关树。定时器T_i到期后，RBi重新计算多目标树分配，并使用关联子TLV播发相关树。
If the new RBridge in the edge group calculates trees and starts to use one or more of them before the existing RBridges in the edge group recalculate, there could be duplication of packets (for example, more than one edge group RBridge could decapsulate and forward a multi-destination frame on links into the active-active group) or loss of packets (for example, due to the Reverse Path Forwarding check, in the rest of the campus, if two edge group RBridges are trying to forward on the same tree, those from one will be discarded). Alternatively, if the new RBridge in the edge group calculates trees and starts to use one or more of them after the existing RBridges recalculate, there could be loss of data due to frames arriving at the new RBridge being black-holed. Timers T_i and T_j should be initialized to values designed to minimize these problems, keeping in mind that, in general, duplication of packets is a more serious problem than dropped packets. It is RECOMMENDED that T_j be less than T_i, and a reasonable default is 1/2 of T_i.
如果边缘组中的新RBridge计算树并在边缘组中的现有RBridge重新计算之前开始使用其中一个或多个树，则可能存在数据包重复（例如，多个边缘组RBridge可能会解封装并将链路上的多目标帧转发到活动组）或数据包丢失（例如，由于反向路径转发检查，在校园的其余部分，如果两个边缘组RBridge试图在同一棵树上转发，则其中一个边缘组RBridge的数据包将被丢弃）。或者，如果“边”组中的新RBridge计算树并在现有RBridge重新计算后开始使用其中一个或多个树，则可能会由于到达新RBridge的帧被黑洞覆盖而丢失数据。定时器T_i和T_j应初始化为设计用于最小化这些问题的值，记住，一般来说，数据包的重复比丢弃的数据包更严重。建议T_j小于T_i，合理违约率为T_i的1/2。
Implementations MUST support a backward compatibility modes to interoperate with "pre-Affinity sub-TLV" RBridges in the network. Such backward compatibility operations MAY include, but are not limited to, tunneling and/or active-standby modes of operation. It should be noted that tunneling would require silicon changes. However, CMT in itself is a software upgrade.
实现必须支持向后兼容模式，以便与网络中的“pre-Affinity sub-TLV”RBridge进行互操作。此类向后兼容性操作可包括但不限于隧道和/或主备操作模式。应该注意的是，隧穿需要硅的变化。然而，CMT本身就是一种软件升级。
Example:
例子：
Step 1. Stop using the virtual RBridge nickname for traffic ingressing from CE nodes.
第一步。停止使用虚拟RBridge昵称从CE节点进入流量。
Step 2. Stop performing active-active forwarding. Fall back to active standby forwarding, based on locally defined policies. The definition of such policies is outside the scope of this document and may be addressed in other documents.
第二步。停止执行主动转发。根据本地定义的策略，退回到主备转发。此类政策的定义不在本文件的范围内，可在其他文件中予以说明。
In general, the RBridges in a campus are trusted routers, and the authenticity of their link-state information (LSPs) and link-local PDUs (e.g., Hellos) can be enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310]. This includes authenticating the contents of the PDUs used to transport Affinity sub-TLVs.
通常，校园中的RBridge是受信任的路由器，它们的链路状态信息（LSP）和链路本地PDU（例如，Hellos）的真实性可以使用常规IS-IS安全机制[IS-IS][RFC5310]强制执行。这包括验证用于传输关联子TLV的PDU的内容。
The particular security considerations involved with different applications of the Affinity sub-TLV will be covered in the document(s) specifying those applications.
亲和力子TLV的不同应用所涉及的特定安全注意事项将包含在指定这些应用的文件中。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
This document serves as the reference for the registration of "Affinity sub-TLV support" (bit 0) in the "TRILL-VER Sub-TLV Capability Flags" registry.
本文件作为在“TRILL-VER子TLV能力标志”注册表中注册“亲和性子TLV支持”（位0）的参考。
This document mentions the registration of "AFFINITY" (value 17) in the "Sub-TLVs for TLV 144" registry, but it is intentionally not listed as a reference for that registration; the reference remains [RFC7176].
本文件提及在“TLV 144子TLV”登记册中登记“亲缘关系”（值17），但有意不将其列为该登记的参考；参考文献仍为[RFC7176]。
[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月。
[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>.
[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>.
[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>.
[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>.
[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>.
[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月。
[ChannelTunnel] Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge Channel Tunnel Protocol", Work in Progress, draft-ietf-trill-channel-tunnel-07, August 2015.
[ChannelTunnel]Eastlake 3rd，D.，Umair，M.，和Y.Li，“TRILL:RBridge通道隧道协议”，正在进行的工作，草案-ietf-TRILL-Channel-Tunnel-072015年8月。
[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>.
Acknowledgments
致谢
The authors wish to extend their appreciations towards individuals who volunteered to review and comment on the work presented in this document and who provided constructive and critical feedback. Specific acknowledgments are due for Anoop Ghanwani, Ronak Desai, Gayle Noble, and Varun Shah. Very special thanks to Donald Eastlake for his careful review and constructive comments.
作者希望向自愿审查和评论本文件所述工作并提供建设性和批判性反馈的个人表示感谢。应向阿努普·加瓦尼、罗纳克·德赛、盖尔·诺布尔和瓦伦·沙阿致谢。非常感谢Donald Eastlake的仔细审查和建设性评论。
Contributors
贡献者
The work in this document is a result of many passionate discussions and contributions from the following individuals, listed in alphabetical order by their first names:
本文件中的工作是以下个人的许多热情讨论和贡献的结果，按姓名字母顺序排列：
Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Hongjun Zhai, Mingui Zhang, Radia Perlman, Sam Aldrin, and Shivakumar Sundaram.
Ayan Banerjee、Dinesh Dutt、Donald Eastlake、翟红军、张明贵、Radia Perlman、Sam Aldrin和Shivakumar Sundaram。
Authors' Addresses
作者地址
Tissa Senevirathne Consultant
Tissa Senevirathne顾问公司
Email: tsenevir@gmail.com
Email: tsenevir@gmail.com
Janardhanan Pathangi Dell/Force10 Networks Olympia Technology Park Guindy Chennai 600 032 India
Janardhanan Pathangi Dell/Force10 Networks奥林匹亚科技园Guindy Chennai 600 032印度
Phone: +91-44-42208400
Email: Pathangi_Janardhanan@Dell.com
Phone: +91-44-42208400
Email: Pathangi_Janardhanan@Dell.com
Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 United States
Jon Hudson Brocade美国加利福尼亚州圣何塞霍尔格大道130号，邮编95134
Phone: +1-408-333-4062
Email: jon.hudson@gmail.com
Phone: +1-408-333-4062
Email: jon.hudson@gmail.com