Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7172 M. Zhang
Updates: 6325 Huawei
Category: Standards Track P. Agarwal
ISSN: 2070-1721 Broadcom
R. Perlman
Intel Labs
D. Dutt
Cumulus Networks
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7172 M. Zhang
Updates: 6325 Huawei
Category: Standards Track P. Agarwal
ISSN: 2070-1721 Broadcom
R. Perlman
Intel Labs
D. Dutt
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling
大量链接的透明互连（TRILL）：细粒度标记
Abstract
摘要
The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.
IETF标准化了大量链路的透明互连（TRILL），这是一种在具有任意拓扑和链路技术的多跳网络中使用链路状态路由和跳数的最低成本透明帧路由协议。TRILL基本协议标准支持使用最多4K ID标记TRILL数据包。但是，有些应用程序需要更多的标签来提供可配置的数据隔离。本文档通过指定TRILL基本协议的可选扩展来更新RFC 6325，以安全地完成此操作。这些被称为细粒度标记的扩展主要用于大型数据中心，即那些拥有超过4K用户且需要彼此之间进行可配置数据隔离的数据中心。
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/rfc7172.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7172.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................4
1.1. Terminology ................................................5
1.2. Contributors ...............................................5
2. Fine-Grained Labeling ...........................................5
2.1. Goals ......................................................6
2.2. Base Protocol TRILL Data Labeling ..........................7
2.3. Fine-Grained Labeling (FGL) ................................7
2.4. Reasons for VL and FGL Coexistence .........................9
3. VL versus FGL Label Differences ................................10
4. FGL Processing .................................................11
4.1. Ingress Processing ........................................11
4.1.1. Multi-Destination FGL Ingress ......................11
4.2. Transit Processing ........................................12
4.2.1. Unicast Transit Processing .........................12
4.2.2. Multi-Destination Transit Processing ...............12
4.3. Egress Processing .........................................13
4.4. Appointed Forwarders and the DRB ..........................14
4.5. Distribution Tree Construction ............................14
4.6. Address Learning ..........................................15
4.7. ESADI Extension ...........................................15
5. FGL TRILL Interaction with VL TRILL ............................15
5.1. FGL and VL Mixed Campus ...................................15
5.2. FGL and VL Mixed Links ....................................17
5.3. Summary of FGL-Safe Requirements ..........................18
6. IS-IS Extensions ...............................................19
7. Comparison with Goals ..........................................19
8. Allocation Considerations ......................................20
8.1. IEEE Allocation Considerations ............................20
8.2. IANA Considerations .......................................20
9. Security Considerations ........................................20
Appendix A. Serial Unicast ........................................22
Appendix B. Mixed Campus Characteristics ..........................23
B.1. Mixed Campus with High Cost Adjacencies ...................23
B.2. Mixed Campus with Data Blocked Adjacencies ................24
Acknowledgements ..................................................25
References ........................................................25
Normative References ...........................................25
Informative References .........................................26
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Contributors ...............................................5
2. Fine-Grained Labeling ...........................................5
2.1. Goals ......................................................6
2.2. Base Protocol TRILL Data Labeling ..........................7
2.3. Fine-Grained Labeling (FGL) ................................7
2.4. Reasons for VL and FGL Coexistence .........................9
3. VL versus FGL Label Differences ................................10
4. FGL Processing .................................................11
4.1. Ingress Processing ........................................11
4.1.1. Multi-Destination FGL Ingress ......................11
4.2. Transit Processing ........................................12
4.2.1. Unicast Transit Processing .........................12
4.2.2. Multi-Destination Transit Processing ...............12
4.3. Egress Processing .........................................13
4.4. Appointed Forwarders and the DRB ..........................14
4.5. Distribution Tree Construction ............................14
4.6. Address Learning ..........................................15
4.7. ESADI Extension ...........................................15
5. FGL TRILL Interaction with VL TRILL ............................15
5.1. FGL and VL Mixed Campus ...................................15
5.2. FGL and VL Mixed Links ....................................17
5.3. Summary of FGL-Safe Requirements ..........................18
6. IS-IS Extensions ...............................................19
7. Comparison with Goals ..........................................19
8. Allocation Considerations ......................................20
8.1. IEEE Allocation Considerations ............................20
8.2. IANA Considerations .......................................20
9. Security Considerations ........................................20
Appendix A. Serial Unicast ........................................22
Appendix B. Mixed Campus Characteristics ..........................23
B.1. Mixed Campus with High Cost Adjacencies ...................23
B.2. Mixed Campus with Data Blocked Adjacencies ................24
Acknowledgements ..................................................25
References ........................................................25
Normative References ...........................................25
Informative References .........................................26
The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325], which provides a solution for least-cost transparent routing in multi-hop networks with arbitrary topologies and link technologies, using [IS-IS] [RFC6165] [RFC7176] link-state routing and a hop count. TRILL switches are sometimes called RBridges (Routing Bridges).
IETF标准化了大量链路的透明互连（TRILL）协议[RFC6325]，该协议使用[IS-IS][RFC6165][RFC7176]链路状态路由和跳数，为具有任意拓扑和链路技术的多跳网络中成本最低的透明路由提供了解决方案。TRILL交换机有时称为RBridges（路由桥）。
The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels of data for configurable isolation based on different tenants, service instances, or the like. This document updates [RFC6325] by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.
TRILL基本协议标准支持使用最多4K ID标记TRILL数据包。但是，有些应用程序需要更多的数据标签，以便根据不同的租户、服务实例等进行可配置隔离。本文档通过指定TRILL基本协议的可选扩展来更新[RFC6325]，以安全地完成此操作。这些被称为细粒度标记的扩展主要用于大型数据中心，即那些拥有超过4K用户且需要彼此之间进行可配置数据隔离的数据中心。
This document describes a format for allowing a data label of 24 bits, known as a "fine-grained label", or FGL. It also describes coexistence and migration from current RBridges, known as "VL" (for "VLAN Labeled") RBridges, to TRILL switches that can support FGL ("Fine-Grained Labeled") packets. Because various VL implementations might handle FGL packets incorrectly, FGL packets cannot be introduced until either all VL RBridges are upgraded to what we will call "FGL-safe", which means that they will not "do anything bad" with FGL packets, or all FGL RBridges take special precautions on any port by which they are connected to a VL RBridge. FGL-safe requirements are summarized in Section 5.3.
本文档描述了一种允许24位数据标签的格式，称为“细粒度标签”或FGL。它还描述了从当前RBridge（称为“VL”（表示“VLAN标记”）RBridge到支持FGL（“细粒度标记”）数据包的TRILL交换机的共存和迁移。因为各种VL实现可能会错误地处理FGL数据包，所以在所有VL RBridge升级到我们称之为“FGL安全”之前，不能引入FGL数据包，这意味着它们不会对FGL数据包“做任何坏事”，或所有FGL RBridge在其连接到VL RBridge的任何端口上采取特殊预防措施。第5.3节总结了FGL安全要求。
It is hoped that many RBridges can become FGL-safe through a software upgrade. VL RBridges and FGL-safe RBridges can coexist without any disruption to service, as long as no FGL packets are introduced.
希望通过软件升级，许多RBridge可以变得FGL安全。只要不引入FGL数据包，VL RBridges和FGL安全RBridges就可以共存而不中断服务。
If all RBridges are upgraded to FGL-safe, FGL traffic can be successfully handled by the campus without any topology restrictions. The existence of FGL traffic is known to all FGL RBridges because some RBridge (say, RB3) that might source or sink FGL traffic will advertise interest in one or more fine-grained labels in its contribution to the link state (its LSP). If any VL RBridges remain at the point when any RBridge announces that it might source or sink FGL traffic, the adjacent FGL-safe RBridges MUST ensure that no FGL packets are forwarded to their VL RBridge neighbor(s). The details are specified in Section 5.1 below.
如果所有RBridge都升级到FGL-safe，则校园可以成功处理FGL流量，而无需任何拓扑限制。所有FGL RBridge都知道FGL流量的存在，因为可能产生或接收FGL流量的某些RBridge（例如，RB3）将在其对链路状态（其LSP）的贡献中宣传对一个或多个细粒度标签的兴趣。如果任何VL RBridge保留在任何RBridge宣布其可能发起或接收FGL流量的点上，则相邻的FGL安全RBridge必须确保没有FGL数据包转发给其VL RBridge邻居。详情见下文第5.1节。
The terminology and acronyms of [RFC6325] are used in this document with the additions listed below.
本文件使用了[RFC6325]的术语和首字母缩略词，并添加了以下内容。
DEI - Drop Eligibility Indicator [802.1Q].
DEI-删除合格指标[802.1Q]。
FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label.
FGL-细粒度标签或细粒度标签或细粒度标签。
FGL-edge - An FGL TRILL switch advertising interest in an FGL label.
FGL边缘-一个FGL颤音开关，用于宣传FGL标签中的兴趣。
FGL link - A link where all of the attached TRILL switches are FGL.
FGL链路-所有连接的颤音开关均为FGL的链路。
FGL-safe - A TRILL switch that can safely be given an FGL data packet, as summarized in Section 5.3.
FGL safe-如第5.3节所述，可安全提供FGL数据包的颤音开关。
RBridge - Alternative name for a TRILL switch.
RBridge-颤音开关的替代名称。
TRILL switch - Alternative name for an RBridge.
颤音开关-RBridge的替代名称。
VL - VLAN Labeling or VLAN Labeled or VLAN Label.
VL-VLAN标签或VLAN标签或VLAN标签。
VL link - A link where any one or more of the attached RBridges are VL.
VL链路-任何一个或多个连接的RBridge为VL的链路。
VL RBridge - A TRILL switch that supports VL but is not FGL-safe.
VL RBridge-支持VL但不支持FGL的颤音开关。
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]中所述进行解释。
Thanks for the contributions of the following:
感谢以下方面的贡献：
Tissa Senevirathne and Jon Hudson
蒂萨·塞内维拉斯和乔恩·哈德森
The essence of Fine-Grained Labeling (FGL) is that (a) when frames are ingressed or created they may incorporate a data label from a set consisting of significantly more than 4K labels, (b) TRILL switch ports can be labeled with a set of such fine-grained data labels,
细粒度标记（FGL）的本质是：（a）当帧进入或创建时，它们可以包含一组明显多于4K的标签中的数据标签，（b）TRILL交换机端口可以使用一组这样的细粒度数据标签进行标记，
and (c) an FGL TRILL Data packet cannot be egressed through a TRILL switch port unless its fine-grained label (FGL) matches one of the data labels of the port.
和（c）除非其细粒度标签（FGL）与端口的数据标签之一匹配，否则FGL TRILL数据分组不能通过TRILL交换机端口退出。
Section 2.1 lists FGL goals. Section 2.2 briefly outlines the more coarse TRILL base protocol standard [RFC6325] data labeling. Section 2.3 outlines FGL for TRILL Data packets. Section 2.4 discusses VL and FGL coexistence.
第2.1节列出了FGL目标。第2.2节简要概述了更粗糙的TRILL基本协议标准[RFC6325]数据标签。第2.3节概述了TRILL数据包的FGL。第2.4节讨论VL和FGL共存。
There are several goals that would be desirable for FGL TRILL. They are briefly described in the list below in approximate order by priority, with the most important first.
FGL TRILL有几个理想的目标。在下面的列表中，按照优先级的大致顺序对它们进行了简要描述，最重要的优先顺序。
1. Fine-Grained
1. 细粒度
Some networks have a large number of entities that need configurable isolation, whether those entities are independent customers, applications, or branches of a single endeavor or some combination of these or other entities. The labeling supported by [RFC6325] provides for only 2**12 - 2 valid identifiers or labels (VLANs). A substantially larger number is required.
有些网络有大量需要可配置隔离的实体，无论这些实体是独立的客户、应用程序或单个业务的分支，还是这些实体或其他实体的组合。[RFC6325]支持的标签仅提供2**12-2个有效标识符或标签（VLAN）。需要一个大得多的数字。
2. Silicon
2. 硅
Fine-grained labeling (FGL) should, to the extent practical, use existing features, processing, and fields that are already supported in many fast path silicon implementations that support the TRILL base protocol.
细粒度标记（FGL）应尽可能使用现有功能、处理和字段，这些功能、处理和字段已在许多支持TRILL-base协议的快速路径硅实现中得到支持。
3. Base RBridge Interoperation
3. 基础RBridge互操作
To support some incremental conversion scenarios, it is desirable that not all RBridges in a campus using FGL be required to be FGL aware. That is, it is desirable if RBridges not implementing the FGL features can exchange VL TRILL Data packets with FGL TRILL switches.
为了支持某些增量转换场景，不需要要求校园中使用FGL的所有RBridge都具有FGL意识。也就是说，如果未实现FGL特征的rbridge可以与FGL TRILL交换机交换VL TRILL数据分组，则是期望的。
4. Alternate Priority
4. 备用优先级
Under some circumstances, it would be desirable for traffic from an attached non-TRILL network to be handled, while transiting a TRILL network, with a different priority from the priority of the original native frames. This could be accomplished by the ingress TRILL switch assigning a different priority to the FGL TRILL Data packet resulting from ingressing the native frames. The original priority should be restored on egress.
在某些情况下，在传输TRILL网络时，希望以与原始本机帧不同的优先级处理来自连接的非TRILL网络的流量。这可以通过入口颤音开关为进入本机帧产生的FGL颤音数据分组分配不同的优先级来实现。出口时应恢复原始优先级。
This section provides a brief review of the [RFC6325] TRILL Data packet VL Labeling and changes the description of the TRILL Header by moving the point at which the TRILL Header ends. This change in description does not involve any change in the bits on the wire or in the behavior of VL TRILL switches.
本节简要回顾[RFC6325]颤音数据包VL标签，并通过移动颤音头结束点更改颤音头的描述。描述中的这种变化不涉及导线上的位或VL TRILL开关行为的任何变化。
VL TRILL Data packets have the structure shown below:
VL TRILL数据包的结构如下所示：
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x8100 | (2 bytes) |
| +-----------------------+ |
| | Inner.VLAN Label | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x8100 | (2 bytes) |
| +-----------------------+ |
| | Inner.VLAN Label | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
Figure 1: TRILL Data with VL
图1:VL的颤音数据
In the base protocol as specified in [RFC6325], the 0x8100 value is always present and is followed by the Inner.VLAN field, which includes the 12-bit VL.
在[RFC6325]中指定的基本协议中，0x8100值始终存在，后面是包含12位VL的Inner.VLAN字段。
FGL expands the variety of data labels available under the TRILL protocol to include a fine-grained label (FGL) with a 12-bit high order part and a 12-bit low order part. In this document, FGLs are denoted as "(X.Y)", where X is the high order part and Y is the low order part of the FGL.
FGL扩展了TRILL协议下可用的各种数据标签，包括具有12位高阶部分和12位低阶部分的细粒度标签（FGL）。在本文件中，FGL表示为“（X.Y）”，其中X是FGL的高阶部分，Y是FGL的低阶部分。
FGL TRILL Data packets have the structure shown below.
FGL TRILL数据包的结构如下所示。
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label High Part | (2 bytes) |
| +-----------------------+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label Low Part | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label High Part | (2 bytes) |
| +-----------------------+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label Low Part | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
Figure 2: TRILL Data with FGL
图2：带FGL的颤音数据
For FGL packets, the inner Media Access Control (MAC) address fields are followed by the FGL information using 0x893B. There MUST be two occurrences of 0x893B, as shown. Should a TRILL switch processing an FGL TRILL Data packet notice that the second occurrence is actually some other value, it MUST discard the packet. (A TRILL switch transiting a TRILL Data packet is not required to examine any fields past the initial fixed fields and options, although it may do so to support Equal-Cost Multi-Path (ECMP) or distribution tree pruning.)
对于FGL数据包，内部媒体访问控制（MAC）地址字段后跟使用0x893B的FGL信息。0x893B必须出现两次，如图所示。如果处理FGL TRILL数据包的TRILL交换机注意到第二次出现实际上是其他值，则必须丢弃该数据包。（传输TRILL数据包的TRILL交换机无需检查超过初始固定字段和选项的任何字段，尽管它可以这样做以支持等成本多路径（ECMP）或分发树修剪。）
The two bytes following each 0x893B have, in their low order 12 bits, fine-grained label information. The upper 4 bits of those two bytes are used for a 3-bit priority field and one Drop Eligibility Indicator (DEI) bit as shown below.
每个0x893B后面的两个字节的低阶12位具有细粒度标签信息。这两个字节的上4位用于3位优先级字段和一个Drop资格指示器（DEI）位，如下所示。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
|priority|DEI| label information |
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
|priority|DEI| label information |
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: FGL Part Data Structure
图3:FGL零件数据结构
The priority field of the Inner.Label High Part is the priority used for frame transport across the TRILL campus from ingress to egress. The label bits in the Inner.Label High Part are the high order part of the FGL, and those bits in the Inner.Label Low Part are the low order part of the FGL. The priority field of the Inner.Label Low Part is remembered from the data frame as ingressed and is restored on egress.
内部标签高部分的优先级字段是用于跨TRILL园区从入口到出口的帧传输的优先级。内部的标签位。标签高部分是FGL的高阶部分，而内部的标签位。标签低部分是FGL的低阶部分。从数据帧中记住Inner.Label Low部分的优先级字段作为入口，并在出口时恢复。
The appropriate FGL value for an ingressed or locally originated native frame is determined by the ingress TRILL switch port as specified in Section 4.1.
第4.1节中规定的入口颤音交换机端口确定入口或本地源本地帧的适当FGL值。
For several reasons, as listed below, it is desirable for FGL TRILL switches to be able to handle both FGL and VL TRILL Data packets.
出于以下几个原因，FGL TRILL交换机需要能够处理FGL和VL TRILL数据包。
o Continued support of VL packets means that, by taking the precautions specified herein, in many cases such arrangements as VL TRILL switches easily exchanging VL packets through a core of FGL TRILL switches are possible.
o 继续支持VL分组意味着，通过采取本文规定的预防措施，在许多情况下，诸如VL TRILL交换机之类的布置可以通过FGL TRILL交换机的核心轻松地交换VL分组。
o Due to the way TRILL works, it may be desirable to have a maintenance VLAN or FGL [RFC7174] in which all TRILL switches in the campus indicate interest. It will be simpler to use the same type of label for all TRILL switches for this purpose. That implies using VL if there might be any VL TRILL switches in the campus.
o 由于TRILL的工作方式，可能需要一个维护VLAN或FGL[RFC7174]，其中校园中的所有TRILL交换机都表示感兴趣。为此，对于所有颤音开关使用相同类型的标签会更简单。这意味着如果校园中可能有任何VL TRILL交换机，则使用VL。
o If a campus is being upgraded from VL to FGL, continued support of VL allows long-term support of edges labeled as VL.
o 如果校园正在从VL升级到FGL，继续支持VL可以长期支持标记为VL的边缘。
There are differences between the semantics across a TRILL campus for TRILL Data packets that are data labeled with VL and FGL.
对于使用VL和FGL标记的数据的TRILL数据包，整个TRILL校园的语义存在差异。
With VL, data label IDs have the same meaning throughout the campus and are from the same label space as the C-VLAN IDs used on Ethernet links to end stations.
对于VL，数据标签ID在整个校园内具有相同的含义，并且来自于与终端站以太网链路上使用的C-VLAN ID相同的标签空间。
The larger FGL data label space is a different space from the VL data label space. For ports configured for FGL, the C-VLAN on an ingressed native frame is stripped and mapped to the FGL data label space with a potentially different mapping for each port. A similar FGL-to-C-VLAN mapping occurs per port on egress. Thus, for ports configured for FGL, the native frame C-VLAN on one link corresponding to an FGL can be different from the native frame C-VLAN corresponding to that same FGL on a different link elsewhere in the campus or even a different link attached to the same TRILL switch. The FGL label space is flat and does not hierarchically encode any particular number of native frame C-VLAN bits or the like. FGLs appear only inside TRILL Data packets after the inner MAC addresses.
较大的FGL数据标签空间与VL数据标签空间不同。对于为FGL配置的端口，入口本机帧上的C-VLAN被剥离并映射到FGL数据标签空间，每个端口的映射可能不同。出口上的每个端口都会发生类似的FGL到C-VLAN映射。因此，对于为FGL配置的端口，与FGL对应的一条链路上的本机帧C-VLAN可以不同于与校园中其他地方的不同链路上的相同FGL对应的本机帧C-VLAN，甚至与连接到相同TRILL交换机的不同链路上的相同FGL对应的本机帧C-VLAN。FGL标签空间是平坦的，并且不分层编码任何特定数量的本机帧C-VLAN比特等。FGL仅出现在内部MAC地址之后的TRILL数据包中。
It is the responsibility of the network manager to properly configure the TRILL switches in the campus to obtain the desired mappings. Such configuration is expected to be automatic in many cases, based on configuration databases and orchestration systems.
网络管理员负责在园区内正确配置TRILL交换机，以获得所需的映射。这种配置在许多情况下都是基于配置数据库和编排系统的自动配置。
With FGL TRILL switches, many things remain the same because an FGL can appear only as the Inner.Label inside a TRILL Data packet. As such, only TRILL-aware devices will see a fine-grained label. The Outer.VLAN that may appear on native frames and that may appear on TRILL Data packets if they are on an Ethernet link can only be a C-VLAN tag. Thus, ports of FGL TRILL switches, up through the usual VLAN and priority processing, act as they do for VL TRILL switches: TRILL switch ports provide a C-VLAN ID for an incoming frame and accept a C-VLAN ID for a frame being queued for output. Appointed Forwarders [RFC6439] on a link are still appointed for a C-VLAN. The Designated VLAN for an Ethernet link is still a C-VLAN.
使用FGL TRILL开关，许多事情保持不变，因为FGL只能显示为TRILL数据包中的内部.Label。因此，只有感知颤音的设备才能看到细粒度的标签。可能出现在本机帧上的Outer.VLAN和可能出现在TRILL数据包（如果它们位于以太网链路上）上的Outer.VLAN只能是C-VLAN标记。因此，通过通常的VLAN和优先级处理，FGL TRILL交换机的端口与VL TRILL交换机的端口一样：TRILL交换机端口为传入帧提供C-VLAN ID，并为排队等待输出的帧接受C-VLAN ID。链路上的指定转发器[RFC6439]仍然为C-VLAN指定。以太网链路的指定VLAN仍然是C-VLAN。
FGL TRILL switches have capabilities that are a superset of those for VL TRILL switches. FGL TRILL switch ports can be configured for FGL or VL, with VL being the default. As with a base protocol [RFC6325] TRILL switch, an unconfigured FGL TRILL switch port reports an untagged frame it receives as being in VLAN 1.
FGL颤音开关的功能是VL颤音开关的超集。FGL TRILL交换机端口可配置为FGL或VL，VL为默认值。与基本协议[RFC6325]TRILL交换机一样，未配置的FGL TRILL交换机端口报告它收到的未标记帧位于VLAN 1中。
This section specifies ingress, transit, egress, and other processing details for FGL TRILL switches. A transit or egress FGL TRILL switch determines that a TRILL Data packet is FGL by detecting that the Inner.MacSA is followed by 0x893B.
本节规定了FGL颤音开关的入口、传输、出口和其他处理细节。传输或出口FGL TRILL开关通过检测INTERNAR.MacSA后跟0x893B来确定TRILL数据包为FGL。
FGL-edge TRILL switch ports are configurable to ingress native frames as FGL. Any port not so configured performs the previously specified [RFC6325] VL ingress processing on native frames resulting in a VL TRILL Data packet. (There is no change in Appointed Forwarder logic (see Section 4.4).) An FGL-safe TRILL switch may have only VL ports, in which case it is not required to support the capabilities for FGL ingress described in this section.
FGL edge TRILL交换机端口可配置为作为FGL进入本机帧。任何未配置的端口在本机帧上执行先前指定的[RFC6325]VL入口处理，从而产生VL TRILL数据包。（指定的转发器逻辑没有变化（见第4.4节）。）FGL-safe TRILL交换机可能只有VL端口，在这种情况下，不需要支持本节所述的FGL进入功能。
FGL-edge TRILL switches support configurable per-port mapping from the C-VLAN of a native frame, as reported by the ingress port, to an FGL. FGL TRILL switches MAY support other methods to determine the FGL of an incoming native frame, such as methods based on the protocol of the native frame or based on local knowledge.
FGL edge TRILL交换机支持从入口端口报告的本机帧的C-VLAN到FGL的可配置逐端口映射。FGL-TRILL开关可支持确定传入本机帧的FGL的其他方法，例如基于本机帧的协议或基于本地知识的方法。
The FGL ingress process MUST copy the priority and DEI (Drop Eligibility Indicator) associated with an ingressed native frame to the upper 4 bits of the Inner.Label Low Order part. It SHOULD also associate a possibly different mapped priority and DEI with an ingressed frame, but a TRILL switch might not be able to do so because of implementation limitations. The mapped priority is placed in the Inner.Label High Part. If such mapping is not supported, then the original priority and DEI MUST be placed in the Inner.Label High Part.
FGL入口进程必须将与入口本机帧相关的优先级和DEI（丢弃合格性指示器）复制到内部标签低阶部件的上4位。它还应该将可能不同的映射优先级和DEI与进入帧相关联，但是TRILL开关可能无法这样做，因为实现限制。映射的优先级放置在内部。标签高部分。如果不支持这种映射，则原始优先级和DEI必须放在内部.Label高部分。
If a native frame that has a broadcast, multicast, or unknown MAC destination address is FGL ingressed, it MUST be handled in one of the following two ways. The choice of which method to use can vary from frame to frame, at the choice of the ingress TRILL switch.
如果具有广播、多播或未知MAC目标地址的本机帧是FGL入口，则必须通过以下两种方式之一进行处理。使用哪种方法的选择可能因帧而异，具体取决于入口颤音开关的选择。
1. Ingress as a TRILL multi-destination data packet (TRILL Header M bit = 1) on a distribution tree rooted at a nickname held by an FGL RBridge or by the pseudonode of an FGL link. FGL TRILL Data packets MUST NOT be sent on a tree rooted at a nickname held by a VL TRILL switch or by the pseudonode of a VL link.
1. 在以FGL RBridge或FGL链路的伪节点持有的昵称为根的分发树上作为TRILL多目的地数据包（TRILL报头M位=1）进入。FGL TRILL数据包不得在以VL TRILL交换机或VL链路的伪节点所持有的昵称为根的树上发送。
2. Serially TRILL unicast the ingressed frame to the relevant egress TRILL switches by using a known unicast TRILL Header (M bit = 0). An FGL ingress TRILL switch SHOULD unicast a multi-destination TRILL Data packet if there is only one relevant egress FGL TRILL switch. The relevant egress TRILL switches are determined by starting with those announcing interest in the frame's (X.Y) label. That set SHOULD be further filtered based on multicast listener and multicast router attachment LSP announcements if the native frame was a multicast frame.
2. 通过使用已知的单播颤音报头（M位=0），将进入帧串行颤音单播到相关的出口颤音开关。如果只有一个相关的出口FGL TRILL交换机，则FGL入口TRILL交换机应单播多目的地TRILL数据包。相关出口颤音开关由宣布对框架（X.Y）标签感兴趣的开关开始确定。如果本机帧是多播帧，则应根据多播侦听器和多播路由器附件LSP通知进一步过滤该集。
Using a TRILL unicast header for a multi-destination frame when it has only one actual destination RBridge almost always improves traffic spreading and decreases latency as discussed in Appendix A. How to decide whether to use a distribution tree or serial unicast for a multi-destination TRILL Data packet that has more than one destination TRILL switch is beyond the scope of this document.
如附录a所述，当多目的帧只有一个实际目的地RBridge时，使用TRILL单播报头几乎总是可以改善流量扩散并减少延迟。如何决定对具有多个目的地TRILL的多目的地TRILL数据包使用分发树还是串行单播开关超出了本文档的范围。
Any FGL TRILL switch MUST be capable of TRILL Data packet transit processing. Such processing is fairly straightforward as described in Section 4.2.1 for known unicast TRILL Data packets and in Section 4.2.2 for multi-destination TRILL Data packets.
任何FGL TRILL交换机必须能够进行TRILL数据包传输处理。如第4.2.1节对已知单播颤音数据包和第4.2.2节对多目的地颤音数据包所述，此类处理相当简单。
There is very little change in TRILL Data packet unicast transit processing. A transit TRILL switch forwards any unicast TRILL Data packet to the next hop towards the egress TRILL switch as specified in the TRILL Header. All transit TRILL switches MUST take the priority and DEI used to forward a packet from the Inner.VLAN label or the FGL Inner.Label High Part. These bits are in the same place in the packet.
TRILL数据包单播传输处理几乎没有变化。传输颤音交换机将任何单播颤音数据分组转发到下一跳，该下一跳朝向TRILL报头中指定的出口颤音交换机。所有transit TRILL交换机都必须具有用于从Inner.VLAN标签或FGL Inner.label高部分转发数据包的优先级和DEI。这些位在数据包中的相同位置。
An FGL TRILL switch MUST properly distinguish flows if it provides ECMP for unicast FGL TRILL Data packets.
如果FGL TRILL交换机为单播FGL TRILL数据包提供ECMP，则必须正确区分流。
Multi-destination TRILL Data packets are forwarded on a distribution tree selected by the ingress TRILL switch, except that an FGL ingress TRILL switch MAY TRILL unicast such a frame to all relevant egress TRILL switches, all as described in Section 4.1. The distribution trees do not distinguish between FGL and VL multi-destination packets, except in pruning behavior if they provide pruning. There is no change in the Reverse Path Forwarding Check.
多目的地颤音数据包在入口颤音交换机选择的分发树上转发，但FGL入口颤音交换机可以将这样的帧颤音单播到所有相关出口颤音交换机，如第4.1节所述。分布树不区分FGL和VL多目的地数据包，除非它们提供了修剪，否则在修剪行为中不进行区分。反向路径转发检查中没有更改。
An FGL TRILL switch (say, RB1) having an FGL multi-destination frame for label (X.Y) to forward on a distribution tree SHOULD prune that tree based on whether there are any TRILL switches on a tree branch that are advertising connectivity to label (X.Y). In addition, RB1 SHOULD prune multicast frames based on reported multicast listener and multicast router attachment in (X.Y).
在分发树上具有用于标签（X.Y）转发的FGL多目标帧的FGL TRILL交换机（例如，RB1）应根据树分支上是否有任何TRILL交换机宣传与标签（X.Y）的连接来修剪该树。此外，RB1应该根据（X.Y）中报告的多播侦听器和多播路由器附件修剪多播帧。
Pruning is an optimization. If a transit TRILL switch does less pruning than it could, there may be greater link utilization than strictly necessary but the campus will still operate correctly. A transit TRILL switch MAY prune based on an arbitrary subset of the bits in the FGL label, for example, only the High Part or only the Low Part of the label.
修剪是一种优化。如果transit TRILL交换机所做的修剪比它所能做的要少，则链路利用率可能比严格要求的要高，但校园仍将正常运行。传输颤音开关可以基于FGL标签中的比特的任意子集（例如，仅标签的高部分或低部分）进行修剪。
Egress processing is generally the reverse of ingress progressing described in Section 4.1. An FGL-safe TRILL switch may have only VL ports, in which case it is not required to support the capabilities for FGL egress described in this section.
出口处理通常与第4.1节中描述的入口处理相反。FGL安全TRILL交换机可能只有VL端口，在这种情况下，不需要支持本节所述的FGL出口功能。
An FGL-edge TRILL switch MUST be able to convert, in a configurable fashion, from the FGL in an FGL TRILL Data packet it is egressing to the C-VLAN ID for the resulting native frame with different mappings on a per-port basis. The priority and DEI of the egressed native frame are taken from the Inner.Label Low Order Part. A port MAY be configured to strip output VLAN tagging.
FGL edge TRILL交换机必须能够以可配置的方式将其正在输出的FGL TRILL数据包中的FGL转换为生成的本机帧的C-VLAN ID，每个端口具有不同的映射。退出的本机帧的优先级和DEI取自内部.Label低阶部分。端口可以配置为剥离输出VLAN标记。
It is the responsibility of the network manager to properly configure the TRILL switches in the campus to obtain the desired mappings.
网络管理员负责在园区内正确配置TRILL交换机，以获得所需的映射。
FGL egress is similar to VL egress, as follows:
FGL出口与VL出口类似，如下所示：
1. If the Inner.MacDA is All-Egress-RBridges, special processing applies, based on the payload Ethertype (for example, End-Station Address Distribution Information (ESADI) [RFC6325] or RBridge Channel [RFC7178]), and if the payload Ethertype is unknown, the packet is discarded. If the Inner.MacDA is not All-Egress-RBridges, then either item 2 or item 3 below applies, as appropriate.
1. 如果Inner.MacDA是所有出口RBridges，则基于有效负载以太类型（例如，端站地址分布信息（ESADI）[RFC6325]或RBridge信道[RFC7178]）应用特殊处理，并且如果有效负载以太类型未知，则丢弃数据包。如果INTERNAR.MacDA不是所有出口，则以下第2项或第3项适用（视情况而定）。
2. A known unicast FGL TRILL Data packet (TRILL Header M bit = 0) with a unicast Inner.MacDA is egressed to the FGL port or ports matching its FGL and Inner.MacDA. If there are no such ports, it is flooded out of all FGL ports that have its FGL, except any ports for which the TRILL switch has knowledge that the frame's Inner.MacDA cannot be present on the link out of that port.
2. 具有单播Inner.MacDA的已知单播FGL TRILL数据包（TRILL报头M位=0）被导出到FGL端口或与其FGL和Inner.MacDA匹配的端口。如果没有这样的端口，它将从具有其FGL的所有FGL端口中溢出，除了TRILL交换机知道帧的Inner.MacDA不能出现在该端口之外的链路上的任何端口。
3. A multi-destination FGL TRILL Data packet is decapsulated and flooded out of all ports that have its FGL, subject to multicast pruning. The same processing applies to a unicast FGL TRILL Data packet with a broadcast or multicast Inner.MacDA that might be received due to serial unicast.
3. 多目标FGL TRILL数据包被解除封装，并从具有其FGL的所有端口中溢出，以进行多播修剪。同样的处理也适用于单播FGL TRILL数据包，该数据包具有可能由于串行单播而被接收的广播或多播Inner.MacDA。
An FGL TRILL switch MUST NOT egress an FGL packet with label (X.Y) to any port not configured with that FGL, even if the port is configured to egress VL packets in VLAN X.
FGL TRILL交换机不得将带有标签（X.Y）的FGL数据包出口到未配置该FGL的任何端口，即使该端口配置为出口VLAN X中的VL数据包。
FGL TRILL switches MUST accept multi-destination TRILL Data packets that are sent to them as TRILL unicast packets (packets with the TRILL Header M bit set to 0). They locally egress such packets, if appropriate, but MUST NOT forward them (other than egressing them as native frames on their local links).
FGL TRILL交换机必须接受作为TRILL单播数据包发送给它们的多目标TRILL数据包（TRILL报头M位设置为0的数据包）。如果合适的话，它们在本地退出这些包，但不能转发它们（除了在本地链路上将它们作为本机帧退出）。
There is no change in adjacency [RFC7177], DRB (Designated RBridge) election, or Appointed Forwarder logic [RFC6439] on a link, regardless of whether some or all the ports on the link are for FGL TRILL switches, with one exception: implementations SHOULD provide that their default priority for a VL RBridge port to be the DRB is less than their default priority for an FGL RBridge to be the DRB. This will assure that, in the unconfigured case, an FGL RBridge will be elected DRB when using that implementation.
链路上的邻接[RFC7177]、DRB（指定RBridge）选择或指定转发器逻辑[RFC6439]没有变化，无论链路上的部分或所有端口是否用于FGL TRILL交换机，有一个例外：实现应该提供VL RBridge端口作为DRB的默认优先级小于FGL RBridge作为DRB的默认优先级。这将确保在未配置的情况下，在使用该实现时，FGL RBridge将被选为DRB。
All distribution trees are calculated as provided for in the TRILL base protocol standard [RFC6325] as updated by [RFC7180], with the exception that the default tree root priority for a nickname held by an FGL TRILL switch or an FGL link pseudonode is 0x9000. As a result, they will be chosen in preference to VL nicknames in the absence of configuration. If distribution tree roots are configured, there MUST be at least one tree rooted at a nickname held by an FGL TRILL switch or by an FGL link pseudonode. If distribution tree roots are misconfigured so there would not be such a tree, then the highest priority FGL nickname to be a tree root is used to construct an additional tree, regardless of configuration. (VL TRILL switches will not know about this additional distribution tree but, through the use of Step (A) or (B) in Section 5.1, no VL TRILL switch should ever receive a multi-destination TRILL Data packet using this additional tree.)
除FGL TRILL交换机或FGL链路伪节点持有的昵称的默认树根优先级为0x9000外，所有分发树均按照[RFC7180]更新的TRILL基本协议标准[RFC6325]中的规定进行计算。因此，在没有配置的情况下，将优先选择VL昵称。如果配置了分发树根，则必须至少有一棵树在FGL TRILL交换机或FGL链路伪节点持有的昵称处扎根。如果分布树根配置错误，因此不会有这样的树，那么不管配置如何，都将使用树根的最高优先级FGL昵称来构造额外的树。（VL TRILL交换机不知道该附加分布树，但通过使用第5.1节中的步骤（A）或（B），任何VL TRILL交换机都不应使用该附加分布树接收多目标TRILL数据包。）
An FGL TRILL switch learns addresses from the data plane on ports configured for FGL based on the fine-grained label rather than the native frame's VLAN. Addresses learned from ingressed native frames on FGL ports are logically represented by { MAC address, FGL, port, confidence, timer }, while remote addresses learned from egressing FGL packets are logically represented by { MAC address, FGL, remote TRILL switch nickname, confidence, timer }.
FGL TRILL交换机根据细粒度标签（而不是本机帧的VLAN）从为FGL配置的端口上的数据平面学习地址。从FGL端口上的进入本机帧中学习到的地址在逻辑上由{MAC地址，FGL，端口，置信度，计时器}表示，而从退出FGL数据包中学习到的远程地址在逻辑上由{MAC地址，FGL，远程TRILL交换机昵称，置信度，计时器}表示。
The TRILL ESADI (End-Station Address Distribution Information) protocol is specified in [RFC6325] as optionally transmitting MAC address connection information through TRILL Data packets between participating TRILL switches over the virtual link provided by the TRILL multi-destination packet distribution mechanism. In [RFC6325], the VL to which an ESADI packet applies is indicated only by the Inner.VLAN label, and no indication of that VL is allowed within the ESADI payload.
TRILL ESADI（终端站地址分配信息）协议在[RFC6325]中指定为可选地通过TRILL多目的地分组分配机制提供的虚拟链路在参与的TRILL交换机之间通过TRILL数据分组传输MAC地址连接信息。在[RFC6325]中，ESADI数据包所应用的VL仅由Inner.VLAN标签指示，并且在ESADI有效负载内不允许指示该VL。
ESADI is extended to support FGL by providing for the indication of the FGL to which an ESADI packet applies only in the Inner.Label of that packet, and no indication of that FGL is allowed within the ESADI payload.
ESADI扩展为支持FGL，提供ESADI数据包仅在该数据包的内部标签中应用的FGL指示，并且在ESADI有效负载内不允许该FGL指示。
This section discusses mixing FGL-safe and VL TRILL switches in a campus. It does not apply if the campus is entirely FGL-safe or if there are no FGL-edges. Section 5.1 specifies what behaviors are needed to render such mixed campuses safe. See also Appendix B for a discussion of campus characteristics when these behaviors are in use. Section 5.2 gives details of link-local mixed behavior.
本节讨论在校园中混合使用FGL safe和VL TRILL交换机。如果校园是完全FGL安全的，或者没有FGL边缘，则不适用此规则。第5.1节规定了使混合校园安全所需的行为。有关使用这些行为时校园特征的讨论，请参见附录B。第5.2节给出了链路局部混合行为的详细信息。
It is best, if possible, for VL TRILL switches to be upgraded to FGL-safe before introducing FGL-edges (and therefore FGL data packets).
如果可能的话，最好在引入FGL边缘（以及FGL数据包）之前，将VL TRILL交换机升级到FGL safe。
By definition, it is not possible for VL TRILL switches to safely handle FGL traffic, even if the VL TRILL switch is only acting in the transit capacity. If a TRILL switch can safely transit FGL TRILL Data packets, then it qualifies as FGL-safe but will still be assumed to be VL until it advertises in its LSP that it is FGL-safe.
根据定义，VL TRILL交换机不可能安全处理FGL流量，即使VL TRILL交换机仅在运输能力范围内工作。如果TRILL交换机可以安全地传输FGL TRILL数据包，则它符合FGL安全的条件，但仍将被假定为VL，直到它在其LSP中声明它是FGL安全的。
VL frames are required to have 0x8100 at the beginning of the data label, where FGL frames have 0x893B. VL TRILL switches conformant to [RFC6325] should discard frames with this new value after the inner MAC addresses. However, if they do not discard such frames, they could be confused and egress them into the wrong VLAN (see Section 9 below) or persistently reorder them due to miscomputing flows for ECMP, or they could improperly prune their distribution if they are multi-destination so that they would fail to reach some intended destinations. Such difficulties are avoided by taking all practical steps to minimize the chance of a VL TRILL switch handling an FGL TRILL Data packet. These steps are specified below.
VL帧要求在数据标签的开头有0x8100，其中FGL帧有0x893B。符合[RFC6325]的VL TRILL开关应在内部MAC地址之后丢弃具有此新值的帧。但是，如果它们不丢弃这些帧，它们可能会被混淆并进入错误的VLAN（参见下面的第9节），或者由于ECMP的错误计算流而持续对它们进行重新排序，或者如果它们是多目的地，它们可能会不正确地修剪其分布，从而无法到达某些预期目的地。通过采取所有实际步骤尽量减少VL TRILL交换机处理FGL TRILL数据包的机会，可以避免此类困难。这些步骤如下所述。
FGL-safe switches will report their FGL capability in LSPs. Thus, FGL-safe TRILL switches (and any management system with access to the link-state database) will be able to detect the existence of TRILL switches in the campus that do not support FGL.
FGL安全交换机将在LSP中报告其FGL能力。因此，FGL安全TRILL交换机（以及任何可以访问链路状态数据库的管理系统）将能够检测到校园中存在不支持FGL的TRILL交换机。
Once a TRILL switch advertises an FGL-edge, any FGL-safe TRILL switch (RB1 in this discussion) that observes, on one of its ports, a VL RBridge on the link out of that port, MUST take Step (A) or (B) below for that port and also take Step (C) further below. ("Observes" means that it has an adjacency to the VL TRILL switch that is in any state other than Down [RFC7177] and holds an LSP fragment zero for it, showing that it is not FGL-safe.) Finally, for there to be full FGL connectivity, the campus topology must be such that all FGL TRILL switches are reachable from all other FGL TRILL switches without going through a VL TRILL switch.
一旦TRILL交换机播发FGL边缘，任何FGL安全TRILL交换机（本讨论中的RB1）如果在其一个端口上观察到该端口外链路上的VL RBridge，则必须对该端口执行以下步骤（a）或（B），并进一步执行以下步骤（C）。（“观察”意味着它与处于除Down[RFC7177]以外的任何状态的VL TRILL开关相邻，并为其保留LSP片段零，表明它不是FGL安全的。）最后，为了实现完整的FGL连接，校园拓扑必须确保所有FGL TRILL交换机都可以从所有其他FGL TRILL交换机访问，而无需通过VL TRILL交换机。
(A) If RB1 can discard any FGL TRILL Data packet that would be output through a port where it observes a VL RBridge, while allowing the output of VL TRILL Data packets through that port, then
（A） 如果RB1可以丢弃通过观察VL RBridge的端口输出的任何FGL TRILL数据包，同时允许通过该端口输出VL TRILL数据包，则
A1. RB1 MUST so discard all FGL TRILL Data output packets that would otherwise be output through the port, and
A1。RB1必须丢弃所有FGL颤音数据输出包，否则将通过端口输出，以及
A2. For all adjacencies out of that port (even adjacencies to other FGL RBridges or a pseudonode) in the Report state [RFC7177], RB1 MUST report that adjacency cost as 2**23 greater than it would have otherwise reported, but not more than 2**24 - 2 (the highest link cost still usable in least-cost path calculations and distribution tree construction). This assures that if any path through FGL-safe TRILL switches exists, such a path will be computed.
A2。对于处于报告状态[RFC7177]的该端口之外的所有邻接（即使是与其他FGL RBridge或伪节点的邻接），RB1必须报告该邻接成本为2**23，比它本来报告的要大，但不超过2**24-2（在最小成本路径计算和分布树构建中仍然可用的最高链路成本）. 这确保了如果存在通过FGL安全颤音开关的任何路径，则将计算该路径。
(B) If RB1 cannot discard any FGL TRILL Data packet that would be output through a port where it observes a VL RBridge while allowing VL TRILL Data packets, then RB1 MUST, for all adjacencies out of that port (even adjacencies to other FGL-safe
（B） 如果RB1不能丢弃通过端口输出的任何FGL TRILL数据包，该端口在允许VL TRILL数据包的同时观察VL RBridge，则RB1必须针对该端口以外的所有邻接（即使是与其他FGL safe的邻接）
RBridges or a pseudonode) in the Report state [RFC7177], report the adjacency cost as 2**24 - 1. As specified in IS-IS [RFC5305], that cost will stop the adjacency from being used in least-cost path calculations, including distribution tree construction (see Section 2.1 of [RFC7180]) but will still leave it visible in the topology and usable, for example, by any traffic engineered path mechanism.
RBridges或伪节点）在报告状态[RFC7177]中，报告邻接成本为2**24-1。如IS-IS[RFC5305]中所述，该成本将阻止邻接用于最小成本路径计算，包括分布树构建（见[RFC7180]第2.1节），但仍将使其在拓扑中可见，并可供任何流量工程路径机制使用。
(C) The roots for all distribution trees used for FGL TRILL Data packets must be nicknames held by an FGL-safe TRILL switch or by a pseudonode representing an FGL link. As provided in Section 4.5, there will always be such a distribution tree.
（C） 用于FGL颤音数据包的所有分布树的根必须是FGL安全颤音交换机或代表FGL链路的伪节点所持有的昵称。如第4.5节所述，始终会有这样一个分发树。
Using the increased adjacency cost specified in part A2 of Step (A) above, VL links will be avoided unless no other path is available for typical data center link speeds using the default link cost determination method specified in Item 1 of Section 4.2.4.4 of [RFC6325]. However, if links have low speed (such as about 100 megabits/second or less) or some non-default method is used for determining link costs, then link costs MUST be adjusted such that no adjacency between FGL-safe TRILL switches has a cost greater than 200,000.
使用上述步骤（A）第A2部分中规定的增加的邻接成本，将避免VL链路，除非使用[RFC6325]第4.2.4.4节第1项中规定的默认链路成本确定方法，没有其他路径可用于典型数据中心链路速度。但是，如果链路的速度较低（例如大约100兆比特/秒或更低），或者使用一些非默认方法来确定链路成本，则必须调整链路成本，以便FGL安全颤音开关之间的邻接成本不超过200000。
To summarize, for a mixed TRILL campus to be safe once FGL-edges are introduced, it is essential that the steps above be followed by FGL-safe RBridges, to ensure that paths between such RBridges do not include VL RBridges, and to ensure that FGL packets are never forwarded to VL RBridges. That is, all FGL-safe switches MUST do Step (A) or (B) for any port out of which they observe a VL RBridge neighbor. Also, for full FGL connectivity, all FGL-safe TRILL switches MUST do Step (C) and be connected in a single FGL contiguous area.
总之，为了使混合TRILL校园在引入FGL边缘后变得安全，必须遵循上述步骤进行FGL安全RBridges，以确保此类RBridges之间的路径不包括VL RBridges，并确保FGL数据包永远不会转发到VL RBridges。也就是说，所有FGL安全交换机必须对其观察到VL RBridge邻居的任何端口执行步骤（A）或（B）。此外，对于完整的FGL连接，所有FGL安全颤音开关必须执行步骤（C）并连接到单个FGL连续区域中。
The usual DRB election operates on a link with mixed FGL and VL ports. If an FGL TRILL switch port is a DRB, it can handle all native traffic. It MUST appoint only other FGL TRILL switch ports as Appointed Forwarder for any VLANs that are to be mapped to FGL.
通常的DRB选择在混合FGL和VL端口的链路上运行。如果FGL TRILL交换机端口是DRB，则它可以处理所有本机流量。它必须仅指定其他FGL TRILL交换机端口作为要映射到FGL的任何VLAN的指定转发器。
For VLANs that are not being mapped to FGL, if Step (A) is being followed (see Section 5.1), it can appoint either a VL or FGL TRILL switch for a VLAN on the link to be handled by a VL. If Step (B) is being followed, an FGL DRB MUST only appoint FGL Appointed Forwarders, so that all end stations will get service to the FGL campus. If a VL RBridge is a DRB, it will not understand that FGL TRILL switch ports are different. To the extent that Step (B) is in effect and a VL DRB handles native frames or appoints other VL TRILL
对于未映射到FGL的VLAN，如果遵循步骤（A）（参见第5.1节），则可以为VL处理的链路上的VLAN指定VL或FGL TRILL交换机。如果遵循步骤（B），FGL DRB必须只指定FGL指定的货运代理，以便所有终点站都能获得FGL园区的服务。如果VL RBridge是DRB，它将不理解FGL TRILL交换机端口是不同的。在步骤（B）有效且VL DRB处理本机帧或指定其他VL颤音的范围内
switch ports on a link to handle native frames for one or more VLANs, the end stations sending and receiving those native frames may be isolated from the FGL campus. When a VL DRB happens to appoint an FGL port as Appointed Forwarder for one or more VLANs, the end stations sending and receiving native frames in those VLANs will get service to the FGL campus.
交换链路上的端口以处理一个或多个VLAN的本机帧，发送和接收这些本机帧的终端站可以与FGL园区隔离。当VL DRB碰巧指定一个FGL端口作为一个或多个VLAN的指定转发器时，在这些VLAN中发送和接收本机帧的终端站将获得FGL园区的服务。
The list below summarizes the requirements for a TRILL switch to be FGL-safe.
下表总结了颤音开关对FGL安全的要求。
1. For both unicast and multi-destination data, RB1 MUST NOT forward an FGL packet to a VL neighbor RB2. This is accomplished as specified in Section 5.1.
1. 对于单播和多目的地数据，RB1不得将FGL数据包转发给VL邻居RB2。这是按照第5.1节的规定完成的。
2. For both unicast and multi-destination data, RB1 MUST NOT egress a packet onto a link that does not belong in that FGL.
2. 对于单播和多目的地数据，RB1不得将数据包导出到不属于该FGL的链路上。
3. For unicast data, RB1 must forward the FGL packet properly to the egress nickname in the TRILL Header. This means that it MUST NOT delete the packet because of not having the expected VLAN tag, it MUST NOT insert a VLAN tag, and it MUST NOT misclassify a flow so as to persistently misorder packets, because the TRILL fields are now 4 bytes longer than in VL TRILL packets.
3. 对于单播数据，RB1必须将FGL数据包正确转发到TRILL报头中的出口昵称。这意味着它不能因为没有预期的VLAN标记而删除数据包，它不能插入VLAN标记，它不能错误分类流以持续错误排序数据包，因为TRILL字段现在比VL TRILL数据包长4字节。
4. For multi-destination data, RB1 must forward the packet properly along the specified tree. This means that RB1 MUST NOT falsely prune the packet. RB1 is allowed not to prune at all, but it MUST NOT prevent an FGL packet from reaching all the links with that FGL by incorrectly refusing to forward the FGL packet along a branch in the tree.
4. 对于多目的地数据，RB1必须沿着指定的树正确转发数据包。这意味着RB1不能错误地删减数据包。RB1完全不允许修剪，但它不能通过错误地拒绝沿树中的分支转发FGL数据包来阻止FGL数据包到达具有该FGL的所有链路。
5. RB1 must advertise, in its LSP, that it is FGL-safe.
5. RB1必须在其LSP中声明其是FGL安全的。
Point 1 above, for a TRILL switch to correctly support ECMP, and point 2, for a TRILL switch to correctly prune distribution trees, require that the TRILL switch properly recognize and distinguish between the two Ethertypes that can occur immediately after the Inner.MacSA in a TRILL Data packet.
上面的第1点（TRILL switch正确支持ECMP）和第2点（TRILL switch正确修剪分布树）要求TRILL switch正确识别和区分在TRILL数据包中的Inner.MacSA之后立即出现的两个Ethertype。
Extensions related to TRILL's use of IS-IS are required to support FGL and must include the following:
需要与TRILL使用IS-IS相关的扩展来支持FGL，并且必须包括以下内容：
1. A method for a TRILL switch to announce itself in its LSP as FGL-safe (see Section 8.2).
1. 颤音开关在其LSP中宣布自身为FGL安全的一种方法（见第8.2节）。
2. A sub-TLV analogous to the Interested VLANs and Spanning Tree Roots sub-TLV of the Router Capabilities TLV but indicating FGLs rather than VLs. This is called the Interested Labels and Spanning Tree Roots (INT-LABEL) sub-TLV in [RFC7176].
2. 类似于感兴趣的VLAN的子TLV和路由器功能TLV的生成树根子TLV，但表示FGL而不是VLs。这在[RFC7176]中称为感兴趣的标签和生成树根（INT-LABEL）子TLV。
3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group Address TLV that specifies an FGL rather than a VL. These are called the GLMAC-ADDR, GLIP-ADDR, and GLIPV6-ADDR sub-TLVs in [RFC7176].
3. 子TLV类似于组地址TLV的GMAC-ADDR子TLV，指定FGL而不是VL。这些被称为[RFC7176]中的GLMAC-ADDR、GLIP-ADDR和GLIPV6-ADDR子TLV。
Comparing TRILL FGL, as specified in this document, with the goals given in Section 2.1, we find the following:
将本文件中规定的TRILL FGL与第2.1节中给出的目标进行比较，我们发现：
1. Fine-Grained: FGL provides 2**24 labels, vastly more than the 4094 (4K) VLAN labels supported in TRILL as specified in [RFC6325].
1. 细粒度：FGL提供2**24个标签，远远超过[RFC6325]中指定的TRILL支持的4094（4K）VLAN标签。
2. Silicon: Existing TRILL fast path silicon chips can perform base TRILL Header insertion and removal to support ingress and egress. In addition, it is believed that most such silicon chips can also perform the native-frame-to-FGL mapping and the encoding of the FGL as specified herein, as well as the inverse decoding and mapping. Some existing silicon chips can perform only one of these operations on a frame in one pass through the fast path; however, other existing chips are believed to be able to perform both operations on the same frame in one pass through their fast path. It is also believed that most FGL TRILL switches will be capable of having their ports configured to discard FGL packets. Such a capability makes interoperation with VL TRILL switches practical using Step (A) as opposed to Step (B) (see Section 5.1).
2. 硅：现有TRILL快速路径硅芯片可以执行基本TRILL报头插入和移除，以支持入口和出口。此外，相信大多数这样的硅芯片还可以执行本机帧到FGL的映射和如本文所述的FGL的编码，以及逆解码和映射。一些现有的硅芯片在通过快速路径的一次过程中只能在一个帧上执行其中一个操作；然而，其他现有芯片被认为能够在通过其快速路径的一次过程中在同一帧上执行这两个操作。人们还认为，大多数FGL TRILL交换机将能够将其端口配置为丢弃FGL数据包。这种能力使得使用步骤（a）而不是步骤（B）（参见第5.1节）与VL TRILL交换机进行互操作变得切实可行。
3. Base RBridge Interoperation: As described in Section 3, FGL is not generally compatible with TRILL switches conformant to the base specification [RFC6325]. In particular, a VL TRILL switch cannot be an FGL TRILL switch because there is a risk that it would mishandle FGL packets. However, a contiguous set of VL TRILL switches can exchange VL frames, regardless of the presence of FGL TRILL switches in the campus. The provisions of Section 5 support reasonable interoperation and migration scenarios.
3. 基本RBridge互操作：如第3节所述，FGL通常与符合基本规范[RFC6325]的TRILL交换机不兼容。特别是，VL颤音开关不能是FGL颤音开关，因为存在错误处理FGL数据包的风险。然而，一组相邻的VL TRILL交换机可以交换VL帧，而不管校园中是否存在FGL TRILL交换机。第5节的规定支持合理的互操作和迁移场景。
4. Alternate Priority: The encoding specified in Section 2.3 and the ingress/egress processing specified in Section 4 provide for a new priority and DEI in the Inner.Label High Part and a place to preserve the original user priority and DEI in the Low Part so that it can be restored on egress.
4. 备用优先级：第2.3节中规定的编码和第4节中规定的入口/出口处理在内部提供了新的优先级和DEI。标记高部分，并在低部分保留原始用户优先级和DEI，以便在出口时恢复。
Allocations by the IEEE Registration Authority and IANA are listed below.
IEEE注册机构和IANA的分配如下所示。
The IEEE Registration Authority has assigned Ethertype 0x893B for TRILL FGL.
IEEE注册机构已为TRILL FGL分配Ethertype 0x893B。
IANA has allocated capability flag 1 in the TRILL-VER sub-TLV capability flags [RFC7176] to indicate that a TRILL switch is FGL-safe.
IANA已在TRILL-VER子TLV能力标志[RFC7176]中分配了能力标志1，以指示TRILL交换机是FGL安全的。
See [RFC6325] for general TRILL security considerations.
参见[RFC6325]了解一般TRILL安全注意事项。
As with any communications system, end-to-end encryption and authentication should be considered for sensitive data. In this case, that would be encryption and authentication extending from a source end station and carried through the TRILL campus to a destination end station.
与任何通信系统一样，应考虑对敏感数据进行端到端加密和身份验证。在这种情况下，这将是从源端站扩展并通过TRILL校园传输到目标端站的加密和身份验证。
Confusion between a packet with VL X and a packet with FGL (X.Y) or confusion due to a malformed frame is a potential problem if an FGL TRILL switch did not properly check for the occurrence of 0x8100 or 0x893B immediately after the Inner.MacSA (see Sections 2.2 and 2.3) and handle the frame appropriately.
如果FGL颤音开关没有正确检查INTERNAR.MacSA（参见第2.2节和第2.3节）之后是否立即出现0x8100或0x893B，并适当处理帧，则具有VL X的数据包与具有FGL（X.Y）的数据包之间的混淆或由于帧格式错误而导致的混淆是一个潜在问题。
[RFC6325] requires that the Ethertype immediately after the Inner.MacSA be 0x8100. A VL TRILL switch that did not discard a packet with some other value there could cause problems. If it received a TRILL Data packet with FGL (X.Y) or with junk after the Inner.MacSA that included X where a VLAN ID would appear, then:
[RFC6325]要求紧跟在Inner.MacSA之后的Ethertype为0x8100。如果VL TRILL交换机没有丢弃具有其他值的数据包，则可能会导致问题。如果它收到一个带有FGL（X.Y）的TRILL数据包，或在包含X的Inner.MacSA之后带有垃圾，其中会出现VLAN ID，则：
1. It could egress the packet to an end station in VLAN X. If the packet was a well-formed FGL frame, the payload of such an egressed native frame would appear to begin with Ethertype 0x893B, which would likely be discarded by an end station. In any case,
1. 它可以将数据包导出到VLAN X中的终端站。如果数据包是格式良好的FGL帧，则这种导出的本机帧的有效负载似乎以Ethertype 0x893B开始，终端站可能会丢弃它。无论如何，
such an egress would almost certainly be a violation of security policy requiring the configurable separation of differently labeled data.
这样的出口几乎肯定会违反安全策略，需要对不同标签的数据进行可配置的分离。
2. If the packet was multi-destination and the TRILL switch pruned the distribution tree, it would incorrectly prune it on the basis of VLAN X. For an FGL packet, this would probably lead to the multi-destination data packet not being delivered to all of its intended recipients.
2. 如果数据包是多目的地数据包，且TRILL交换机修剪了分发树，则会根据VLAN X对其进行错误的修剪。对于FGL数据包，这可能会导致多目的地数据包无法发送到其所有预期收件人。
Possible problems with an FGL TRILL switch that (a) received a TRILL Data packet with junk after the Inner.MacSA that included X where a VLAN ID would appear and (b) did not check the Ethertype immediately after the Inner.MacSA would be that it could improperly egress the packet in VLAN X, violating security policy. If the packet was multi-destination and was improperly forwarded, it should be discarded by properly implemented TRILL switches downstream in the distribution tree and never egressed, but the propagation of the packet would still waste bandwidth.
FGL TRILL交换机可能存在以下问题：（a）在包含X（其中会出现VLAN ID）的Inner.MacSA之后接收到带有垃圾的TRILL数据包，以及（b）在Inner.MacSA之后没有立即检查Ethertype。这可能是因为它可能不正确地退出VLAN X中的数据包，从而违反安全策略。如果数据包是多目的地的，并且被不正确地转发，它应该被分发树中正确实现的TRILL交换机丢弃，并且永远不会离开，但是数据包的传播仍然会浪费带宽。
To avoid these problems, all TRILL switches MUST check the Ethertype immediately after the Inner.MacSA and, if it is a value they do not know how to handle, either discard the frame or make no decisions based on any data after that Ethertype. In addition, care must be taken to avoid FGL packets being sent to or through VL TRILL switches that will discard them if the VL TRILL switch is properly implemented or mishandle them if it is not properly implemented. This is accomplished as specified in Section 5.1.
为了避免这些问题，所有TRILL交换机必须在Inner.MacSA之后立即检查Ethertype，如果这是一个他们不知道如何处理的值，则放弃帧或不根据该Ethertype之后的任何数据做出决定。此外，必须注意避免向VL TRILL交换机发送FGL数据包或通过VL TRILL交换机发送FGL数据包，如果VL TRILL交换机正确实现，FGL数据包将被丢弃；如果VL TRILL交换机未正确实现，FGL数据包将被错误处理。这是按照第5.1节的规定完成的。
This informational appendix discusses the advantages and disadvantages of using serial unicast instead of a distribution tree for multi-destination TRILL Data packets. See Sections 4.1 and 4.3. This document requires that FGL TRILL switches accept serial unicast, but there is no requirement that they be able to send serial unicast.
本信息性附录讨论了使用串行单播代替多目标TRILL数据包的分发树的优缺点。见第4.1节和第4.3节。本文档要求FGL TRILL交换机接受串行单播，但不要求它们能够发送串行单播。
Consider a large TRILL campus with hundreds of TRILL switches in which, say, 300 end stations are in some particular FGL data label.
考虑一个大的颤音校园与数百个颤音开关，其中，300个终端站是在一些特定的FGL数据标签。
At one extreme, if all 300 end stations were on links attached to a single TRILL switch, then no other TRILL switch would be advertising interest in that FGL. As a result, it is likely that because of pruning a multi-destination (say, broadcast) frame from one such end station would not be sent to any another TRILL switch, even if put on a distribution tree.
在一个极端情况下，如果所有300个终端站都在连接到单个颤音开关的链路上，那么就不会有其他颤音开关对该FGL感兴趣。因此，由于剪枝，来自这样一个终端站的多目的地（例如，广播）帧很可能不会被发送到任何另一个颤音交换机，即使放在分发树上也是如此。
At the other extreme, assume that the 300 end stations are attached, one each, to 300 different TRILL switches; in that case, you are almost certainly better off using a distribution tree because if you tried to serially unicast you would have to output 300 copies, probably including multiple copies through the same port, and would cause much higher link utilization.
在另一个极端，假设300个终端站分别连接到300个不同的颤音开关；在这种情况下，使用分发树几乎肯定会更好，因为如果尝试串行单播，则必须输出300个副本，可能包括通过同一端口的多个副本，并且会导致更高的链路利用率。
Now assume that these 300 end stations are connected to exactly two TRILL switches, say, 200 to one and 100 to the other. Using unicast TRILL Data packets between these two TRILL switches is best because the frames will follow least-cost paths, possibly with such traffic spread over a number of least-cost paths with equal cost. On the other hand, if distribution trees were used, each frame would be constrained to the tree used for that frame and would likely follow a higher cost route and only a single path would be available per tree. Thus, this document says that unicast SHOULD be used if there are exactly two TRILL switches involved.
现在假设这300个终端站正好连接到两个颤音开关，比如说，200到一个，100到另一个。在这两个TRILL交换机之间使用单播TRILL数据包是最好的，因为帧将遵循最低成本路径，可能这样的通信量以相等的成本分布在多个最低成本路径上。另一方面，如果使用分布树，则每个帧将被约束到用于该帧的树，并且可能遵循更高成本的路径，并且每个树只有一条路径可用。因此，本文档指出，如果恰好涉及两个颤音开关，则应使用单播。
The decision of whether to use a distribution tree or serial unicast if the end stations are connected to more than two TRILL switches is more complex. Which would be better would depend on many factors, including network topology and application data patterns. How to make this decision in such cases is beyond the scope of this document.
如果终端站连接到两个以上的TRILL交换机，则决定是使用分发树还是串行单播更为复杂。哪个更好取决于许多因素，包括网络拓扑和应用程序数据模式。在这种情况下如何作出这一决定超出了本文件的范围。
This informational appendix describes the characteristics of a TRILL campus with mixed FGL-safe and VL TRILL switches for two cases: Appendix B.1 discusses the case where all FGL adjacencies with VL are handled by Step (A) in Section 5.1, and Appendix B.2 discusses the case where all FGL adjacencies with VL are handled by Step (B) in Section 5.1.
本信息性附录描述了两种情况下混合FGL安全和VL TRILL交换机的TRILL校园的特征：附录B.1讨论了第5.1节中的步骤（a）处理所有与VL的FGL邻接的情况，附录B.2讨论了第5.1节中的步骤（B）处理所有与VL的FGL邻接的情况。
If the FGL TRILL switches use Step (A) in Section 5.1, then VL and FGL TRILL switches will be able to interoperate for VL traffic. Least-cost paths will avoid any FGL -> VL TRILL switch hops unless no other reasonable path is available. In conjunction with Section 4.5, there will be at least one distribution tree rooted at a nickname held by an FGL TRILL switch or the pseudonode for an FGL link. Furthermore, if the FGL TRILL switches in the campus form a single contiguous island, this distribution tree will have a fully connected sub-tree covering that island. Thus, any FGL TRILL Data packets sent on this tree will be able to reach any other FGL TRILL switch without attempting to go through any VL TRILL switches. (Such an attempt would cause the FGL packet to be discarded as specified in part A1 of Step (A).)
如果FGL TRILL交换机使用第5.1节中的步骤（A），则VL和FGL TRILL交换机将能够针对VL流量进行互操作。成本最低的路径将避免任何FGL->VL颤音切换跳数，除非没有其他合理的路径可用。结合第4.5节，至少有一个分布树以FGL颤音开关或FGL链路的伪节点持有的昵称为根。此外，如果校园中的FGL TRILL交换机形成单个连续岛，则此分发树将具有覆盖该岛的完全连接的子树。因此，在该树上发送的任何FGL TRILL数据包将能够到达任何其他FGL TRILL交换机，而无需尝试通过任何VL TRILL交换机。（这种尝试将导致按照步骤（A）第A1部分的规定丢弃FGL数据包。）
If supported, Step (A) is particularly effective in a campus with an FGL TRILL switch core and VL TRILL switches in one or more islands around that core. For example, consider the campus below. This campus has an FGL core consisting of FGL01 to FGL14 and three VL islands consisting of VL01 to VL04, VL05, and VL06 to VL14.
如果支持，步骤（A）在具有FGL TRILL交换机核心和VL TRILL交换机位于该核心周围的一个或多个孤岛的园区中尤其有效。例如，考虑下面的校园。该校区有一个FGL核心，由FGL01至FGL14组成，三个VL岛由VL01至VL04、VL05和VL06至VL14组成。
*VL01--*VL02
| |
*VL03--*VL04 *VL05
| | |
FGL01--FGL02--FGL03--FGL04--FGL05
| | | | |
FGL06--FGL07--FGL08--FGL09--FGL10
| | | | |
FGL11--FGL12--*VL06--*VL07---FGL13
| | | |
*VL08--*VL09--*VL10---FGL14
| | | |
*VL11--*VL12--*VL13--*VL14
*VL01--*VL02
| |
*VL03--*VL04 *VL05
| | |
FGL01--FGL02--FGL03--FGL04--FGL05
| | | | |
FGL06--FGL07--FGL08--FGL09--FGL10
| | | | |
FGL11--FGL12--*VL06--*VL07---FGL13
| | | |
*VL08--*VL09--*VL10---FGL14
| | | |
*VL11--*VL12--*VL13--*VL14
Assuming that the FGL TRILL switches in this campus all implement Step (A), then end stations connected through a VL port can be connected anywhere in the campus to VL or FGL TRILL switches and, if in the same VLAN, will communicate. End stations connected through an FGL port on FGL TRILL switches will communicate if their local VLANs are mapped to the same FGL.
假设该园区内的FGL TRILL交换机都实现了步骤（A），那么通过VL端口连接的终端站可以连接到园区内的任何地方，与VL或FGL TRILL交换机连接，如果在同一VLAN中，则将进行通信。如果本地VLAN映射到同一FGL，则通过FGL TRILL交换机上的FGL端口连接的终端站将进行通信。
Due to the high cost of FGL-to-VL adjacencies used in path computations, VL TRILL switches are avoided on paths between FGL TRILL switches. For example, even if the speed and default adjacency cost of all the connections shown above were the same, traffic from FGL12 to FGL13 would follow the 5-hop path FGL12 - FGL07 - FGL08 - FGL09 - FGL10 - FGL13 rather than the 3-hop path FGL12 - VL09 - VL10 - FGL14.
由于路径计算中使用的FGL到VL邻接的高成本，避免在FGL颤音开关之间的路径上使用VL颤音开关。例如，即使上述所有连接的速度和默认邻接成本相同，从FGL12到FGL13的流量也将遵循5跳路径FGL12-FGL07-FGL08-FGL09-FGL10-FGL13，而不是3跳路径FGL12-VL09-VL10-FGL14。
If the FGL TRILL switches use Step (B) in Section 5.1, then least-cost and distribution tree TRILL Data communication between VL and FGL TRILL switches is blocked, although TRILL IS-IS communication is normal. This data blocking, although implemented only by FGL TRILL switches, has relatively symmetric effects. The following paragraphs assume that such data blocking between VL and FGL is in effect throughout the campus.
如果FGL颤音开关使用第5.1节中的步骤（B），则VL和FGL颤音开关之间的最低成本和分布树颤音数据通信被阻断，尽管颤音is-is通信正常。这种数据阻塞虽然仅由FGL TRILL开关实现，但具有相对对称的效果。以下段落假设VL和FGL之间的此类数据阻塞在整个校园内有效。
A campus of mostly FGL TRILL switches implementing Step (B) with a few isolated VL TRILL switches scattered throughout will work well in terms of connectivity for end stations attached to those FGL switches, except that they will be unable to communicate with any end stations for which a VL switch is appointed forwarder. The VL TRILL switches will be isolated and will only be able to route TRILL Data to the extent that they happen to be contiguously connected to other VL TRILL switches. Distribution trees computed by the FGL switches will not include any VL switches (see Section 2.1 of [RFC7180]).
大部分为FGL TRILL交换机的园区（实施步骤（B））和分散在各处的几个隔离VL TRILL交换机在连接连接到这些FGL交换机的终端站方面将运行良好，但它们将无法与指定VL交换机为转发器的任何终端站通信。VL TRILL交换机将被隔离，并且只能在其恰好与其他VL TRILL交换机连续连接的情况下路由TRILL数据。FGL开关计算的配电树不包括任何VL开关（见[RFC7180]第2.1节）。
A campus of mostly VL TRILL switches with a few isolated FGL TRILL switches scattered throughout will also work reasonably well as described immediately above but with all occurrences of "FGL" and "VL" swapped.
如上文所述，大部分VL TRILL交换机和分散在各处的几个孤立FGL TRILL交换机组成的园区也能正常工作，但所有出现的“FGL”和“VL”都已交换。
However, a campus so badly misconfigured that it consists of a randomly intermingled mixture of VL and FGL TRILL switches using Step (B) is likely to offer very poor data service, due to many links being blocked for data.
然而，由于许多链路被数据阻塞，一个严重错误配置的校园，其由使用步骤（B）的VL和FGL TRILL交换机随机混合而成，很可能提供非常差的数据服务。
Acknowledgements
致谢
The comments and suggestions of the following, listed in alphabetic order, are gratefully acknowledged:
感谢以下各方按字母顺序提出的意见和建议：
Stewart Bryant, Spencer Dawkins, Adrian Farrel, Anoop Ghanwani, Sujay Gupta, Weiguo Hao, Phanidhar Koganti, Yizhou Li, Vishwas Manral, Rajeev Manur, Thomas Narten, Gayle Nobel, Erik Nordmark, Pete Resnick, Olen Stokes, Sean Turner, Ilya Varlashkin, and Xuxiaohu.
斯图尔特·布莱恩特、斯宾塞·道金斯、阿德里安·法雷尔、阿努普·加瓦尼、苏杰·古普塔、魏国豪、帕尼达尔·科甘蒂、李益周、维什瓦·曼拉尔、拉吉耶夫·曼努尔、托马斯·纳滕、盖尔·诺贝尔、埃里克·诺德马克、皮特·雷斯尼克、奥伦·斯托克斯、肖恩·特纳、伊利亚·瓦拉什金和徐晓虎。
References
工具书类
Normative References
规范性引用文件
[802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q]IEEE 802.1，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q-2011，2011年8月。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "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)", 2002.
[IS-IS]ISO/IEC 10589:2002，第二版，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[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, May 2014.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，2014年5月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，2014年5月。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates" RFC 7180, May 2014.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链路的透明互连（TRILL）：澄清、更正和更新”，RFC 7180，2014年5月。
Informative References
资料性引用
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 61652011年4月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年11月。
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014.
[RFC7174]Salam，S.，Senevirathne，T.，Aldrin，S.，和D.Eastlake 3rd，“大量链路的透明互连（TRILL）运营、管理和维护（OAM）框架”，RFC 7174，2014年5月。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德市比弗街155号唐纳德东湖第三华为技术有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies Co., Ltd Huawei Building, No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District Beijing 100095 P.R. China
中国北京市海淀区创业科技十番园北青路Z园156号华为大厦
EMail: zhangmingui@huawei.com
EMail: zhangmingui@huawei.com
Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 USA
Puneet Agarwal Broadcom Corporation美国加利福尼亚州圣何塞市赞克路3151号，邮编95134
Phone: +1-949-926-5000
EMail: pagarwal@broadcom.com
Phone: +1-949-926-5000
EMail: pagarwal@broadcom.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
Radia Perlman英特尔实验室使命学院大道2200号。美国加利福尼亚州圣克拉拉95054
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Dinesh G. Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
Dinesh G.Dutt Cumulus Networks美国加利福尼亚州桑尼维尔西伊夫林大道1089号，邮编94086
EMail: ddutt.ietf@hobbesdutt.com
EMail: ddutt.ietf@hobbesdutt.com