Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7780 M. Zhang
Obsoletes: 7180 Huawei
Updates: 6325, 7177, 7179 R. Perlman
Category: Standards Track EMC
ISSN: 2070-1721 A. Banerjee
Cisco
A. Ghanwani
Dell
S. Gupta
IP Infusion
February 2016
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7780 M. Zhang
Obsoletes: 7180 Huawei
Updates: 6325, 7177, 7179 R. Perlman
Category: Standards Track EMC
ISSN: 2070-1721 A. Banerjee
Cisco
A. Ghanwani
Dell
S. Gupta
IP Infusion
February 2016
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
大量链接的透明互连（TRILL）：澄清、更正和更新
Abstract
摘要
Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.
自2011年发布TRILL（大量链路的透明互连）基本协议以来，TRILL的积极开发和部署揭示了RFC 6325中的勘误表以及可能需要澄清或更新的领域。RFC 7177、RFC 7357和RFC 6439的预期替代品分别对邻接、TRILL ESADI（终端站地址分配信息）协议和指定的转发器进行了澄清和更新。本文件提供了其他已知的澄清、更正和更新。它淘汰了RFC 7180（之前的“TRILL澄清、更正和更新”RFC），并更新了RFC 6325、7177和7179。
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/rfc7780.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7780.
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 (Changed) ..........................................5
1.1. Precedence (Changed) .......................................5
1.2. Changes That Are Not Backward Compatible (Unchanged) .......6
1.3. Terminology and Acronyms (Changed) .........................6
2. Overloaded and/or Unreachable RBridges (Unchanged) ..............7
2.1. Reachability ...............................................8
2.2. Distribution Trees .........................................8
2.3. Overloaded Receipt of TRILL Data Packets ...................9
2.3.1. Known Unicast Receipt ...............................9
2.3.2. Multi-Destination Receipt ...........................9
2.4. Overloaded Origination of TRILL Data Packets ...............9
2.4.1. Known Unicast Origination ..........................10
2.4.2. Multi-Destination Origination ......................10
2.4.2.1. An Example Network ........................10
2.4.2.2. Indicating OOMF Support ...................11
2.4.2.3. Using OOMF Service ........................11
3. Distribution Trees and RPF Check (Changed) .....................12
3.1. Number of Distribution Trees (Unchanged) ..................12
3.2. Distribution Tree Update Clarification (Unchanged) ........12
3.3. Multicast Pruning Based on IP Address (Unchanged) .........13
3.4. Numbering of Distribution Trees (Unchanged) ...............13
3.5. Link Cost Directionality (Unchanged) ......................13
3.6. Alternative RPF Check (New) ...............................14
3.6.1. Example of the Potential Problem ...................14
3.6.2. Solution and Discussion ............................15
4. Nickname Selection (Unchanged) .................................17
5. MTU (Maximum Transmission Unit) (Unchanged) ....................18
5.1. MTU-Related Errata in RFC 6325 ............................19
5.1.1. MTU PDU Addressing .................................19
5.1.2. MTU PDU Processing .................................20
5.1.3. MTU Testing ........................................20
5.2. Ethernet MTU Values .......................................20
6. TRILL Port Modes (Unchanged) ...................................21
7. The CFI/DEI Bit (Unchanged) ....................................22
8. Other IS-IS Considerations (Changed) ...........................23
8.1. E-L1FS Support (New) ......................................24
8.1.1. Backward Compatibility .............................24
8.1.2. E-L1FS Use for Existing (Sub-)TLVs .................25
8.2. Control Packet Priorities (New) ...........................26
8.3. Unknown PDUs (New) ........................................27
8.4. Nickname Flags APPsub-TLV (New) ...........................27
8.5. Graceful Restart (Unchanged) ..............................29
8.6. Purge Originator Identification (New) .....................29
9. Updates to RFC 7177 (Adjacency) (Changed) ......................30
1. Introduction (Changed) ..........................................5
1.1. Precedence (Changed) .......................................5
1.2. Changes That Are Not Backward Compatible (Unchanged) .......6
1.3. Terminology and Acronyms (Changed) .........................6
2. Overloaded and/or Unreachable RBridges (Unchanged) ..............7
2.1. Reachability ...............................................8
2.2. Distribution Trees .........................................8
2.3. Overloaded Receipt of TRILL Data Packets ...................9
2.3.1. Known Unicast Receipt ...............................9
2.3.2. Multi-Destination Receipt ...........................9
2.4. Overloaded Origination of TRILL Data Packets ...............9
2.4.1. Known Unicast Origination ..........................10
2.4.2. Multi-Destination Origination ......................10
2.4.2.1. An Example Network ........................10
2.4.2.2. Indicating OOMF Support ...................11
2.4.2.3. Using OOMF Service ........................11
3. Distribution Trees and RPF Check (Changed) .....................12
3.1. Number of Distribution Trees (Unchanged) ..................12
3.2. Distribution Tree Update Clarification (Unchanged) ........12
3.3. Multicast Pruning Based on IP Address (Unchanged) .........13
3.4. Numbering of Distribution Trees (Unchanged) ...............13
3.5. Link Cost Directionality (Unchanged) ......................13
3.6. Alternative RPF Check (New) ...............................14
3.6.1. Example of the Potential Problem ...................14
3.6.2. Solution and Discussion ............................15
4. Nickname Selection (Unchanged) .................................17
5. MTU (Maximum Transmission Unit) (Unchanged) ....................18
5.1. MTU-Related Errata in RFC 6325 ............................19
5.1.1. MTU PDU Addressing .................................19
5.1.2. MTU PDU Processing .................................20
5.1.3. MTU Testing ........................................20
5.2. Ethernet MTU Values .......................................20
6. TRILL Port Modes (Unchanged) ...................................21
7. The CFI/DEI Bit (Unchanged) ....................................22
8. Other IS-IS Considerations (Changed) ...........................23
8.1. E-L1FS Support (New) ......................................24
8.1.1. Backward Compatibility .............................24
8.1.2. E-L1FS Use for Existing (Sub-)TLVs .................25
8.2. Control Packet Priorities (New) ...........................26
8.3. Unknown PDUs (New) ........................................27
8.4. Nickname Flags APPsub-TLV (New) ...........................27
8.5. Graceful Restart (Unchanged) ..............................29
8.6. Purge Originator Identification (New) .....................29
9. Updates to RFC 7177 (Adjacency) (Changed) ......................30
10. TRILL Header Update (New) .....................................31
10.1. Color Bit ................................................32
10.2. Flags Word Changes (Update to RFC 7179) ..................32
10.2.1. Extended Hop Count ................................32
10.2.1.1. Advertising Support ......................33
10.2.1.2. Ingress Behavior .........................33
10.2.1.3. Transit Behavior .........................33
10.2.1.4. Egress Behavior ..........................34
10.2.2. Extended Color Field ..............................34
10.3. Updated Flags Word Summary ...............................35
11. Appointed Forwarder Status Lost Counter (New) .................35
12. IANA Considerations (Changed) .................................37
12.1. Previously Completed IANA Actions (Unchanged) ............37
12.2. New IANA Actions (New) ...................................37
12.2.1. Reference Updated .................................37
12.2.2. The "E" Capability Bit ............................37
12.2.3. NickFlags APPsub-TLV Number and Registry ..........38
12.2.4. Updated TRILL Extended Header Flags ...............38
12.2.5. TRILL-VER Sub-TLV Capability Flags ................39
12.2.6. Example Nicknames .................................39
13. Security Considerations (Changed) .............................39
14. References ....................................................40
14.1. Normative References .....................................40
14.2. Informative References ...................................42
Appendix A. Life Cycle of a TRILL Switch Port (New) ...............45
Appendix B. Example TRILL PDUs (New) ..............................48
B.1. LAN Hello over Ethernet ...................................48
B.2. LSP over PPP ..............................................50
B.3. TRILL Data over Ethernet ..................................51
B.4. TRILL Data over PPP .......................................52
Appendix C. Changes to Previous RFCs (New) ........................53
C.1. Changes to Obsoleted RFC 7180 .............................53
C.1.1. Changes ..............................................53
C.1.2. Additions ............................................53
C.1.3. Deletions ............................................54
C.2. Changes to RFC 6325 .......................................55
C.3. Changes to RFC 7177 .......................................55
C.4. Changes to RFC 7179 .......................................55
Acknowledgments ...................................................56
Authors' Addresses ................................................56
10. TRILL Header Update (New) .....................................31
10.1. Color Bit ................................................32
10.2. Flags Word Changes (Update to RFC 7179) ..................32
10.2.1. Extended Hop Count ................................32
10.2.1.1. Advertising Support ......................33
10.2.1.2. Ingress Behavior .........................33
10.2.1.3. Transit Behavior .........................33
10.2.1.4. Egress Behavior ..........................34
10.2.2. Extended Color Field ..............................34
10.3. Updated Flags Word Summary ...............................35
11. Appointed Forwarder Status Lost Counter (New) .................35
12. IANA Considerations (Changed) .................................37
12.1. Previously Completed IANA Actions (Unchanged) ............37
12.2. New IANA Actions (New) ...................................37
12.2.1. Reference Updated .................................37
12.2.2. The "E" Capability Bit ............................37
12.2.3. NickFlags APPsub-TLV Number and Registry ..........38
12.2.4. Updated TRILL Extended Header Flags ...............38
12.2.5. TRILL-VER Sub-TLV Capability Flags ................39
12.2.6. Example Nicknames .................................39
13. Security Considerations (Changed) .............................39
14. References ....................................................40
14.1. Normative References .....................................40
14.2. Informative References ...................................42
Appendix A. Life Cycle of a TRILL Switch Port (New) ...............45
Appendix B. Example TRILL PDUs (New) ..............................48
B.1. LAN Hello over Ethernet ...................................48
B.2. LSP over PPP ..............................................50
B.3. TRILL Data over Ethernet ..................................51
B.4. TRILL Data over PPP .......................................52
Appendix C. Changes to Previous RFCs (New) ........................53
C.1. Changes to Obsoleted RFC 7180 .............................53
C.1.1. Changes ..............................................53
C.1.2. Additions ............................................53
C.1.3. Deletions ............................................54
C.2. Changes to RFC 6325 .......................................55
C.3. Changes to RFC 7177 .......................................55
C.4. Changes to RFC 7179 .......................................55
Acknowledgments ...................................................56
Authors' Addresses ................................................56
Since the TRILL base protocol [RFC6325] was published in 2011, active development and deployment of TRILL have revealed errors in the specification [RFC6325] and several areas that could use clarifications or updates.
自2011年发布TRILL基本协议[RFC6325]以来，TRILL的积极开发和部署揭示了规范[RFC6325]中的错误以及可能需要澄清或更新的几个领域。
[RFC7177], [RFC7357], and [RFC6439bis] provide clarifications and
updates with respect to adjacency, the TRILL ESADI (End Station
Address Distribution Information) protocol, and Appointed Forwarders,
respectively. This document provides other known clarifications,
corrections, and updates to [RFC6325], [RFC7177], and [RFC7179].
This document obsoletes [RFC7180] (the previous TRILL
"clarifications, corrections, and updates" document), updates
[RFC6325], updates [RFC7177] as described in Section 9, and updates
[RFC7179] as described in Sections 10.2 and 10.3. The changes to
these RFCs are summarized in Appendix C.
[RFC7177], [RFC7357], and [RFC6439bis] provide clarifications and
updates with respect to adjacency, the TRILL ESADI (End Station
Address Distribution Information) protocol, and Appointed Forwarders,
respectively. This document provides other known clarifications,
corrections, and updates to [RFC6325], [RFC7177], and [RFC7179].
This document obsoletes [RFC7180] (the previous TRILL
"clarifications, corrections, and updates" document), updates
[RFC6325], updates [RFC7177] as described in Section 9, and updates
[RFC7179] as described in Sections 10.2 and 10.3. The changes to
these RFCs are summarized in Appendix C.
Sections of this document are annotated as to whether they are "New" technical material, material that has been technically "Changed", or material that is technically "Unchanged", by the appearance of one of these three words in parentheses at the end of the section header. A section with only editorial changes is annotated as "(Unchanged)". If no such notation appears, then the first notation encountered on going to successively higher-level section headers (those with shorter section numbers) applies. Appendix C describes changes, summarizes material added, and lists material deleted.
通过在章节标题末尾的括号中出现这三个词中的一个，对本文件各章节进行注释，说明它们是“新”技术材料、技术上已“更改”的材料还是技术上“未更改”的材料。仅作编辑性修改的部分注释为“（未更改）”。如果没有出现这样的标记，那么在转到更高级别的节头（节号更短的节头）时遇到的第一个标记将适用。附录C描述了变更，总结了添加的材料，并列出了删除的材料。
In the event of any conflicts between this document and [RFC6325], [RFC7177], or [RFC7179], this document takes precedence.
如果本文件与[RFC6325]、[RFC7177]或[RFC7179]之间存在任何冲突，则以本文件为准。
In addition, Section 1.2 of [RFC6325] ("Normative Content and Precedence") is updated to provide a more complete precedence ordering of the sections of [RFC6325], as shown below, where sections to the left take precedence over sections to their right. There are no known conflicts between these sections; however, Sections 1 and 2 are less detailed and do not mention every corner case, while subsequent sections of [RFC6325] are more detailed. This precedence is specified as a fallback in case some conflict is found in the future.
此外，更新了[RFC6325]第1.2节（“规范性内容和优先顺序”），以提供[RFC6325]各节更完整的优先顺序，如下所示，其中左侧各节优先于右侧各节。这些部分之间没有已知的冲突；但是，第1节和第2节不太详细，没有提到每个角落的情况，而[RFC6325]的后续章节更详细。此优先级指定为将来发现冲突时的回退。
4 > 3 > 7 > 5 > 2 > 6 > 1
4 > 3 > 7 > 5 > 2 > 6 > 1
The change made by Section 3.4 below (unchanged from Section 3.4 of [RFC7180]) is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes.
下文第3.4节所做的更改（与[RFC7180]第3.4节相同）与[RFC6325]不向后兼容，但已被采用以减少拓扑更改导致的配电树更改。
Several other changes herein that are fixes to errata for [RFC6325] -- [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508] -- may not be backward compatible with previous implementations that conformed to errors in the specification.
此处对[RFC6325]-[Err3002]、[Err3003]、[Err3004]、[Err3052]、[Err3053]和[Err3508]的勘误表进行的其他几项修改可能与符合规范中错误的先前实现不向后兼容。
This document uses the acronyms defined in [RFC6325], some of which are repeated below for convenience, along with some additional acronyms and terms, as follows:
本文件使用了[RFC6325]中定义的首字母缩略词，为了方便起见，下面重复了其中一些首字母缩略词和术语，如下所示：
BFD - Bidirectional Forwarding Detection.
双向转发检测。
Campus - A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
校园-一个TRILL网络，由TRILL交换机、链路和可能由终端站和IP路由器连接的网桥组成。对于TRILL来说，“校园”这个名字没有“学术”含义。
CFI - Canonical Format Indicator [802].
CFI-规范格式指示符[802]。
CSNP - Complete Sequence Number PDU.
CSNP-完整序列号PDU。
DEI - Drop Eligibility Indicator [802.1Q-2014].
DEI-删除资格指标[802.1Q-2014]。
FGL - Fine-Grained Labeling [RFC7172].
FGL-细粒度标记[RFC7172]。
FS-LSP - Flooding Scope LSP.
FS-LSP-泛洪范围LSP。
OOMF - Overload Originated Multi-destination Frame.
OOMF-重载起源于多目标帧。
P2P - Point-to-point.
点对点。
PDU - Protocol Data Unit.
协议数据单元。
PSNP - Partial Sequence Number PDU.
PSNP-部分序列号PDU。
RBridge - Routing Bridge, an alternative name for a TRILL switch.
RBridge-路由桥，TRILL交换机的另一个名称。
RPFC - Reverse Path Forwarding Check.
RPFC-反向路径转发检查。
SNPA - Subnetwork Point of Attachment (for example, Media Access Control (MAC) address).
SNPA-子网连接点（例如，媒体访问控制（MAC）地址）。
ToS - Type of Service.
ToS-服务类型。
TRILL - Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL-链路层中大量链路的透明互连或隧道路由。
TRILL switch - A device implementing the TRILL protocol. An alternative name for an RBridge.
颤音开关-实现颤音协议的设备。RBridge的替代名称。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
In this document, a "packet" usually refers to a TRILL Data packet or TRILL IS-IS packet received from or sent to a TRILL switch, while a "frame" usually refers to a native frame being received from or sent to an end station. (The word "frame" also occurs in other contexts, such as the "Frame Check Sequence" that is at the end of Ethernet transmissions.)
在本文档中，“分组”通常指从TRILL交换机接收或发送到TRILL交换机的TRILL数据分组或TRILL IS-IS分组，而“帧”通常指从终端站接收或发送到终端站的本机帧。（单词“frame”也出现在其他上下文中，例如以太网传输结束时的“frame Check Sequence”。）
In this section, the term "neighbor" refers only to actual RBridges and ignores pseudonodes.
在本节中，术语“邻居”仅指实际RBridge，而忽略伪节点。
RBridges may be in overload, as indicated by the [IS-IS] overload flag in their LSPs (Link State PDUs). This means that either (1) they are incapable of holding the entire link-state database and thus do not have a view of the entire topology or (2) they have been configured to have the overload bit set. Although networks should be engineered to avoid actual link-state overload, it might occur under various circumstances -- for example, if a very large campus included one or more low-end TRILL switches.
RBridge可能处于过载状态，如其LSP（链路状态PDU）中的[IS-IS]过载标志所示。这意味着（1）它们无法保存整个链路状态数据库，因此没有整个拓扑的视图，或者（2）它们已配置为设置过载位。尽管网络的设计应该避免实际的链路状态过载，但在各种情况下都可能发生这种情况——例如，如果一个非常大的校园包含一个或多个低端TRILL交换机。
It is a common operational practice to set the overload bit in an [IS-IS] router (such as a TRILL switch) when performing maintenance on that router that might affect its ability to correctly forward packets; this will usually leave the router reachable for maintenance traffic, but transit traffic will not be routed through it. (Also, in some cases, TRILL provides for setting the overload bit in the pseudonode of a link to stop TRILL Data traffic on an access link (see Section 4.9.1 of [RFC6325]).)
在[is-is]路由器（如TRILL交换机）上执行可能影响其正确转发数据包能力的维护时，通常在该路由器中设置过载位；这通常会使维护流量可以到达路由器，但传输流量不会通过路由器路由。（此外，在某些情况下，TRILL用于设置链路伪节点中的过载位，以停止接入链路上的TRILL数据流量（参见[RFC6325]第4.9.1节）
[IS-IS] and TRILL make a reasonable effort to do what they can, even if some TRILL switches/routers are in overload. They can do reasonably well if a few scattered nodes are in overload. However, actual least-cost paths are no longer assured if any TRILL switches are in overload.
[IS-IS]和TRILL尽其所能做出合理的努力，即使一些TRILL交换机/路由器过载。如果几个分散的节点处于过载状态，它们可以做得相当好。然而，如果任何颤音开关处于过载状态，实际的最低成本路径将不再得到保证。
For the effect of overload on the appointment of forwarders, see [RFC6439bis].
有关超载对货运代理人任命的影响，请参见[RFC6439bis]。
Packets are not least-cost routed through an overloaded TRILL switch, although they may originate or terminate at an overloaded TRILL switch. In addition, packets will not be least-cost routed over links with cost 2**24 - 1 [RFC5305]; such links are reserved for traffic-engineered packets, the handling of which is beyond the scope of this document.
数据包不是通过重载TRILL交换机路由的成本最低的，尽管它们可以在重载TRILL交换机上发起或终止。此外，数据包不会在成本为2**24-1[RFC5305]的链路上以最低成本路由；此类链接是为流量工程包保留的，其处理超出了本文档的范围。
As a result, a portion of the campus may be unreachable for least-cost routed TRILL Data because all paths to it would be either through a link with cost 2**24 - 1 or through an overloaded RBridge. For example, an RBridge (TRILL switch) RB1 is not reachable by TRILL Data if all of its neighbors are connected to RB1 by links with cost 2**24 - 1. Such RBridges are called "data unreachable".
因此，对于成本最低的路由TRILL数据，校园的一部分可能无法访问，因为到它的所有路径要么通过成本为2**24-1的链路，要么通过过载的RBridge。例如，如果RBridge（TRILL switch）RB1的所有邻居都通过成本为2**24-1的链路连接到RB1，则TRILL数据无法访问RBridge（TRILL switch）RB1。这种RBridge称为“数据不可访问”。
The link-state database at an RBridge -- for example, RB1 -- can also contain information on TRILL switches that are unreachable by IS-IS link-state flooding due to link or RBridge failures. When such failures partition the campus, the TRILL switches adjacent to the failure and on the same side of the failure as RB1 will update their LSPs to show the lack of connectivity, and RB1 will receive those updates. As a result, RB1 will be aware of the partition. Nodes on the far side of the partition are both IS-IS unreachable and data unreachable from RB1. However, LSPs held by RB1 for TRILL switches on the far side of the failure will not be updated and may stay around until they time out, which could be tens of minutes or longer. (The default in [IS-IS] is twenty minutes.)
RBridge上的链路状态数据库（例如RB1）还可以包含由于链路或RBridge故障导致IS-IS链路状态洪泛无法访问的TRILL交换机的信息。当此类故障对校园进行分区时，与故障相邻且与RB1位于故障同一侧的TRILL交换机将更新其LSP以显示缺乏连接，RB1将接收这些更新。因此，RB1将知道分区。分区远端的节点既不能从RB1访问IS-IS，也不能从RB1访问数据。但是，RB1为故障远端的TRILL交换机持有的LSP将不会更新，并且可能会一直保留，直到超时为止，这可能需要几十分钟或更长时间。（在[IS-IS]中，默认值为20分钟。）
An RBridge in overload cannot be trusted to correctly calculate distribution trees or correctly perform the RPFC (Reverse Path Forwarding Check). Therefore, it cannot be trusted to forward multi-destination TRILL Data packets. It can only appear as a leaf node in a TRILL multi-destination distribution tree. Furthermore, if all the immediate neighbors of an RBridge are overloaded, then it is omitted from all trees in the campus and is unreachable by multi-destination packets.
无法信任RBridge in重载正确计算分发树或正确执行RPFC（反向路径转发检查）。因此，转发多目的TRILL数据包是不可信的。它只能显示为TRILL多目标分发树中的叶节点。此外，如果RBridge的所有近邻都过载，那么它将从校园中的所有树中忽略，并且多目标数据包无法访问。
When an RBridge determines what nicknames to use as the roots of the distribution trees it calculates, it MUST ignore all nicknames held by TRILL switches that are in overload or are data unreachable. When calculating RPFCs for multi-destination packets, an RBridge such as RB1 MAY, to avoid calculating unnecessary RPFC state information,
当RBridge确定使用什么昵称作为其计算的分发树的根时，它必须忽略TRILL开关持有的所有处于过载或数据无法访问状态的昵称。当计算多目的地分组的RPFC时，诸如RB1的RBridge可以避免计算不必要的RPFC状态信息，
ignore any trees that cannot reach RB1, even if other RBridges list those trees as trees that other TRILL switches might use. (However, see Section 3.)
忽略任何无法到达RB1的树，即使其他RBridge将这些树列为其他颤音开关可能使用的树。（但是，请参见第3节。）
The receipt of TRILL Data packets by overloaded RBridge RB2 is discussed in the subsections below. In all cases, the normal Hop Count decrement is performed, and the TRILL Data packets are discarded if the result is less than one or if the Egress Nickname is illegal.
在下面的小节中讨论了过载的RBridge RB2对TRILL数据包的接收。在所有情况下，执行正常跳数递减，如果结果小于1或出口昵称非法，则丢弃TRILL数据包。
RB2 will not usually receive unicast TRILL Data packets unless it is the egress, in which case it egresses and delivers the data normally. If RB2 receives a unicast TRILL Data packet for which it is not the egress, perhaps because a neighbor does not yet know it is in overload, RB2 MUST NOT discard the packet because the egress is an unknown nickname, as it might not know about all nicknames due to its overloaded condition. If any neighbor other than the neighbor from which it received the packet is not overloaded, it MUST attempt to forward the packet to one of those neighbors selected at random [RFC4086]. If there is no such neighbor, the packet is discarded.
RB2通常不会接收单播颤音数据包，除非它是出口，在这种情况下，它正常出口并发送数据。如果RB2接收到其不是出口的单播TRILL数据包，可能是因为邻居还不知道该数据包处于过载状态，RB2不得丢弃该数据包，因为出口是未知的昵称，因为由于其过载状态，RB2可能不知道所有的昵称。如果接收数据包的邻居之外的任何邻居没有过载，则必须尝试将数据包转发给随机选择的邻居之一[RFC4086]。如果没有这样的邻居，则丢弃数据包。
If RB2 in overload receives a multi-destination TRILL Data packet, RB2 MUST NOT apply an RPFC because, due to overload, it might not do so correctly. RB2 egresses and delivers the frame locally where it is Appointed Forwarder for the frame's VLAN (or, if the packet is FGL, for the VLAN that FGL maps to at the port), subject to any multicast pruning. But because, as stated above, RB2 can only be the leaf of a distribution tree, it MUST NOT forward a multi-destination TRILL Data packet (except as an egressed native frame where RB2 is Appointed Forwarder).
如果过载中的RB2接收到多目标TRILL数据包，RB2不得应用RPFC，因为由于过载，它可能无法正确应用RPFC。RB2在本地退出并交付帧，该帧被指定为帧VLAN的转发器（或者，如果数据包是FGL，则为FGL在端口映射到的VLAN），并接受任何多播修剪。但是，如上所述，由于RB2只能是分发树的叶子，因此它不能转发多目的地TRILL数据包（RB2被指定为转发器的出口本机帧除外）。
Overloaded origination of unicast TRILL Data packets with known egress and of multi-destination packets is discussed in the subsections below.
以下小节将讨论具有已知出口的单播TRILL数据包和多目的地数据包的过载发起。
When RB2, an overloaded RBridge, ingresses or creates a known destination unicast data packet, it delivers it locally if the destination is local. Otherwise, RB2 unicasts it to any neighbor TRILL switch that is not overloaded. It MAY use what routing information it has to help select the neighbor.
当RB2（过载的RBridge）进入或创建已知的目的地单播数据包时，如果目的地是本地的，它将在本地传送该数据包。否则，RB2将其单播到任何未过载的相邻TRILL交换机。它可以使用它拥有的路由信息来帮助选择邻居。
Overloaded RBridge RB2 ingressing or creating a multi-destination data packet presents a more complex scenario than that of the known unicast case, as discussed below.
过载的RBridge RB2进入或创建多目的地数据分组呈现出比已知单播情况更复杂的场景，如下所述。
For example, consider the network diagram below in which, for simplicity, end stations and any bridges are not shown. There is one distribution tree of which RB4 is the root, as represented by double lines. Only RBridge RB2 is overloaded.
例如，考虑下面的网络图，为了简单起见，没有示出终端站和任何桥梁。有一个以RB4为根的分布树，用双线表示。只有RBridge RB2过载。
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--+
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +====+ RB6 +===++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--+
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +====+ RB6 +===++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+
Since RB2 is overloaded, it does not know what the distribution tree or trees are for the network. Thus, there is no way it can provide normal TRILL Data service for multi-destination native frames. So, RB2 tunnels the frame in a TRILL Data packet to a neighbor that is not overloaded if it has such a neighbor that has signaled that it is willing to offer this service. RBridges indicate this in their Hellos as described below. This service is called the OOMF (Overload Originated Multi-destination Frame) service.
由于RB2过载，它不知道网络的分发树是什么。因此，它无法为多目标本机帧提供正常的颤音数据服务。因此，RB2通过隧道将TRILL数据包中的帧传送给一个没有过载的邻居，如果它有这样一个邻居表示它愿意提供此服务。RBridges在其Hello中表示这一点，如下所述。此服务称为OOMF（重载起源的多目标帧）服务。
- The multi-destination frame MUST NOT be locally distributed in native form at RB2, because this would cause the frame to be delivered twice. Instead, it is tunneling to a neighbor as described in this section. For example, if RB2 locally distributed a multicast native frame and then tunneled it to RB5, RB2 would get a copy of the frame when RB3 transmitted it as a TRILL Data packet
- 多目标帧不能在RB2以本机形式本地分发，因为这将导致帧被传递两次。相反，它是通过隧道传输到邻居，如本节所述。例如，如果RB2本地分发一个多播本机帧，然后通过隧道将其传输到RB5，那么当RB3将其作为TRILL数据包传输时，RB2将获得该帧的副本
on the multi-access RB2-RB3-RB4 link. Since RB2 would, in general, not be able to tell that this was a frame it had tunneled for distribution, RB2 would decapsulate it and locally distribute it a second time.
在多址RB2-RB3-RB4链路上。一般来说，由于RB2无法判断这是一个为分发而挖隧道的帧，因此RB2将对其进行去封装，并在本地进行第二次分发。
- On the other hand, if there is no neighbor of RB2 offering RB2 the OOMF service, RB2 cannot tunnel the frame to a neighbor. In this case, RB2 MUST locally distribute the frame where it is Appointed Forwarder for the frame's VLAN and optionally subject to multicast pruning.
- 另一方面，如果RB2的邻居没有向RB2提供OOMF服务，则RB2无法通过隧道将帧传输到邻居。在这种情况下，RB2必须在本地分发帧，它被指定为帧VLAN的转发器，并且可以选择性地进行多播修剪。
An RBridge RB3 indicates its willingness to offer the OOMF service to RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit associated with the SNPA (Subnetwork Point of Attachment, also known as MAC address) of RB2 on the link (see the IANA Considerations section). Overloaded RBridge RB2 can only distribute multi-destination TRILL Data packets to the campus if a neighbor of RB2 not in overload offers RB2 the OOMF service. If RB2 does not have OOMF service available to it, RB2 can still receive multi-destination packets from non-overloaded neighbors, and if RB2 should originate or ingress such a frame, it distributes it locally in native form.
RBridge RB3表示其愿意通过在链路上设置与RB2的SNPA（子网连接点，也称为MAC地址）相关的位，向RB3的TRILL Hellos中的TRILL邻居TLV中的RB2提供OOMF服务（参见IANA注意事项部分）。如果RB2的邻居未处于过载状态，则过载的RBridge RB2只能将多目标TRILL数据包分发到校园，并向RB2提供OOMF服务。如果RB2没有可用的OOMF服务，RB2仍然可以从未过载的邻居接收多个目的地数据包，并且如果RB2应该发起或进入这样的帧，它将以本机形式在本地分发它。
If RB2 sees this OOMF (Overload Originated Multi-destination Frame) service advertised for it by any of its neighbors on any link to which RB2 connects, it selects one such neighbor by a means that is beyond the scope of this document. Assuming that RB2 selects RB3 to handle multi-destination packets it originates, RB2 MUST advertise in its LSP that it might use any of the distribution trees that RB3 advertises so that the RPFC will work in the rest of the campus. Thus, notwithstanding its overloaded state, RB2 MUST retain this information from RB3 LSPs, which it will receive, as it is directly connected to RB3.
如果RB2看到其任何邻居在RB2连接的任何链路上为其播发的OOMF（重载起源的多目标帧）服务，它将通过超出本文档范围的方式选择一个这样的邻居。假设RB2选择RB3来处理它发起的多目的地数据包，RB2必须在其LSP中通告它可能使用RB3通告的任何分发树，以便RPFC将在校园的其余部分工作。因此，尽管RB2处于过载状态，但它必须保留来自RB3 LSP的该信息，因为它将直接连接到RB3。
RB2 then encapsulates such frames as TRILL Data packets to RB3 as follows: "M" bit = 0; Hop Count = 2; Ingress Nickname = a nickname held by RB2; and, since RB2 cannot tell what distribution tree RB3 will use, Egress Nickname = a special nickname indicating an OOMF packet (see the IANA Considerations section). RB2 then unicasts this TRILL Data packet to RB3. (Implementation of Item 4 in Section 4 below provides reasonable assurance that, notwithstanding its overloaded state, the ingress nickname used by RB2 will be unique within at least the portion of the campus that is IS-IS reachable from RB2.)
然后，RB2将这些帧作为颤音数据包封装到RB3，如下所示：“M”位=0；跳数=2；Ingress昵称=RB2持有的昵称；而且，由于RB2无法判断RB3将使用哪个分发树，因此出口昵称=表示OOMF数据包的特殊昵称（请参阅IANA注意事项部分）。RB2然后将该颤音数据包单播到RB3。（下文第4节第4项的实施提供了合理的保证，即尽管RB2处于过载状态，但RB2使用的入口昵称在至少可从RB2访问的校园部分内是唯一的。）
On receipt of such a packet, RB3 does the following:
收到此类数据包后，RB3执行以下操作：
- changes the Egress Nickname field to designate a distribution tree that RB3 normally uses,
- 更改出口昵称字段以指定RB3通常使用的分发树，
- sets the "M" bit to one,
- 将“M”位设置为1，
- changes the Hop Count to the value it would normally use if it were the ingress, and
- 将跃点计数更改为入口时通常使用的值，以及
- forwards the TRILL Data packet on that tree.
- 转发树上的颤音数据包。
RB3 MAY rate-limit the number of packets for which it is providing this service by discarding some such packets from RB2. The provision of even limited bandwidth for OOMFs by RB3, perhaps via the slow path, may be important to the bootstrapping of services at RB2 or at end stations connected to RB2, such as supporting DHCP and ARP/ND (Address Resolution Protocol / Neighbor Discovery). (Everyone sometimes needs a little OOMF (pronounced "oomph") to get off the ground.)
RB3可以通过从RB2丢弃一些这样的包来限制其提供此服务的包的数量。RB3为OOMFs提供甚至有限的带宽（可能通过慢路径）对于RB2或连接到RB2的终端站的服务引导可能很重要，例如支持DHCP和ARP/ND（地址解析协议/邻居发现）。（每个人有时都需要一点OOMF（发音为“oomph”）才能离开地面。）
Two corrections, a clarification, and two updates related to distribution trees appear in the subsections below, along with an alternative, stronger RPF (Reverse Path Forwarding) check. See also Section 2.2.
下面的小节中显示了两个更正、一个澄清和两个与分发树相关的更新，以及另一个更强的RPF（反向路径转发）检查。另见第2.2节。
In [RFC6325], Section 4.5.2, page 56, point 2, fourth paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)".
在[RFC6325]第56页第2点第四段第4.5.2节中，插入语“（最多{j，k}）”不正确[Err3052]。其读数应为“（如果j为零，则最大值为k；如果j为非零，则最小值为（j，k）”。
When a link-state database change causes a change in the distribution tree(s), several possible types of change can occur. If a tree root remains a tree root but the tree changes, then local forwarding and RPFC entries for that tree should be updated as soon as practical. Similarly, if a new nickname becomes a tree root, forwarding and RPFC entries for the new tree should be installed as soon as practical. However, if a nickname ceases to be a tree root and there is sufficient room in local tables, the forwarding and RPFC entries for the former tree MAY be retained so that any multi-destination TRILL Data packets already in flight on that tree have a higher probability of being delivered.
当链接状态数据库更改导致分发树中的更改时，可能会发生几种类型的更改。如果树根仍然是树根，但树发生了更改，则应尽快更新该树的本地转发和RPFC条目。类似地，如果新昵称成为树根，则应尽快安装新树的转发和RPFC条目。然而，如果昵称不再是树根并且在本地表中有足够的空间，则可以保留前一棵树的转发和RPFC条目，以便已经在该树上飞行的任何多目的地TRILL数据分组具有更高的被递送的概率。
The TRILL base protocol specification [RFC6325] provides for, and recommends the pruning of, multi-destination packet distribution trees based on the location of IP multicast routers and listeners; however, multicast listening is identified by derived MAC addresses as communicated in the Group MAC Address sub-TLV [RFC7176].
TRILL基本协议规范[RFC6325]根据IP多播路由器和侦听器的位置，提供并建议修剪多目的地分组分发树；然而，多播侦听通过在组MAC地址子TLV[RFC7176]中通信的派生MAC地址来识别。
TRILL switches MAY communicate multicast listeners and prune distribution trees based on the actual IPv4 or IPv6 multicast addresses involved. Additional Group Address sub-TLVs are provided in [RFC7176] to carry this information. A TRILL switch that is only capable of pruning based on derived MAC addresses SHOULD calculate and use such derived MAC addresses from the multicast listener IPv4 or IPv6 address information it receives.
TRILL交换机可以与多播侦听器通信，并根据实际涉及的IPv4或IPv6多播地址修剪分发树。[RFC7176]中提供了附加的组地址子TLV以承载此信息。只能基于派生MAC地址进行修剪的TRILL交换机应根据其接收的多播侦听器IPv4或IPv6地址信息计算并使用此类派生MAC地址。
Section 4.5.1 of [RFC6325] specifies that, when building distribution tree number j, node (RBridge) N that has multiple possible parents in the tree is attached to possible parent number j mod p. Trees are numbered starting with 1, but possible parents are numbered starting with 0. As a result, if there are two trees and two possible parents, then in tree 1 parent 1 will be selected, and in tree 2 parent 0 will be selected.
[RFC6325]的第4.5.1节规定，在构建编号为j的分发树时，树中具有多个可能父节点的节点（RBridge）N连接到可能的父节点编号j mod p。树从1开始编号，但可能的父树从0开始编号。因此，如果有两棵树和两个可能的父级，则将选择树1中的父级1，并选择树2中的父级0。
This is changed so that the selected parent MUST be (j-1) mod p. As a result, in the case above, tree 1 will select parent 0, and tree 2 will select parent 1. This change is not backward compatible with [RFC6325]. If all RBridges in a campus do not determine distribution trees in the same way, then for most topologies, the RPFC will drop many multi-destination packets before they have been properly delivered.
此项已更改，因此所选父项必须为（j-1）mod p。因此，在上述情况下，树1将选择父级0，树2将选择父级1。此更改与[RFC6325]不向后兼容。如果校园中的所有RBFC不以相同的方式确定分发树，那么对于大多数拓扑，RPFC将在多个目的地数据包正确交付之前丢弃这些数据包。
Distribution tree construction, like other least-cost aspects of TRILL, works even if link costs are asymmetric, so the cost of the hop from RB1 to RB2 is different from the cost of the hop from RB2 to RB1. However, it is essential that all RBridges calculate the same distribution trees, and thus all must use either the cost away from the tree root or the cost towards the tree root. The text in Section 4.5.1 of [RFC6325] is incorrect, as documented in [Err3508]. The text says:
与TRILL的其他最低成本方面一样，分布树构造即使在链路成本不对称的情况下也能工作，因此从RB1到RB2的跳的成本不同于从RB2到RB1的跳的成本。然而，至关重要的是，所有RBridge计算相同的分布树，因此所有RBridge都必须使用远离树根的成本或朝向树根的成本。[RFC6325]第4.5.1节中的文本不正确，如[Err3508]中所述。案文说：
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from N to R and ...
换言之，对于根在R的树，N的潜在父代集合由那些提供从N到R的最小成本路径和。。。
but the text should say "from R to N":
但是文本应该是“从R到N”：
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from R to N and ...
换句话说，对于根植于R的树，N的潜在双亲集由那些给出从R到N的最小代价路径的双亲集和。。。
[RFC6325] mandates a Reverse Path Forwarding (RPF) check on multi-destination TRILL Data packets to avoid possible multiplication and/or looping of multi-destination traffic during TRILL campus topology transients. This check is logically performed at each TRILL switch input port and determines whether it is arriving on the expected port based on where the packet started (the ingress nickname) and the tree on which it is being distributed. If not, the packet is silently discarded. This check is fine for point-to-point links; however, there are rare circumstances involving multi-access ("broadcast") links where a packet can be duplicated despite this RPF check and other checks performed by TRILL.
[RFC6325]强制要求对多目标TRILL数据包进行反向路径转发（RPF）检查，以避免TRILL校园拓扑过渡期间多目标流量的可能倍增和/或循环。该检查逻辑上在每个TRILL交换机输入端口执行，并根据数据包的起始位置（入口昵称）和分发数据包的树来确定数据包是否到达预期端口。如果不是，则数据包将被静默丢弃。此检查适用于点到点链接；然而，很少有涉及多址（“广播”）链路的情况，其中尽管有此RPF检查和TRILL执行的其他检查，数据包仍然可以复制。
Section 3.6.1 gives an example of the potential problem, and Section 3.6.2 specifies a solution. This solution is an alternative, stronger RPF check that TRILL switches can implement in place of the RPF check discussed in [RFC6325].
第3.6.1节给出了潜在问题的示例，第3.6.2节规定了解决方案。此解决方案是一种可选的、更强的RPF检查，TRILL交换机可以实现该检查，以代替[RFC6325]中讨论的RPF检查。
Consider this network:
考虑这个网络：
F--A--B--C--o--D | E
F--A--B--C--o--D | E
All the links except the link between C, D, and E are point-to-point links. C, D, and E are connected over a broadcast link represented by the pseudonode "o". For example, they could be connected by a bridged LAN. (Bridged LANs are transparent to TRILL.)
除C、D和E之间的链接外，所有链接都是点对点链接。C、 D、D和E通过伪节点“o”表示的广播链路连接。例如，它们可以通过桥接LAN连接。（桥接LAN对TRILL是透明的。）
Although the choice of root is unimportant here, assume that D or F is chosen as the root of a distribution tree so that it is obvious that the tree looks just like the diagram above.
虽然根的选择在这里并不重要，但假设选择D或F作为分布树的根，因此很明显，该树看起来与上图一样。
Now assume that a link comes up from A to the same bridged LAN. The network then looks like this:
现在假设有一条链路从a连接到同一个桥接LAN。然后，网络看起来如下所示：
+--------+
| |
F--A--B--C--o--D
|
E
+--------+
| |
F--A--B--C--o--D
|
E
Let's say the resulting tree in steady state includes all links except the B-C link. After the network has converged, a packet that starts from F will go F->A. Then A will send one copy on the A-B link and another copy into the bridged LAN from which it will be received by C and D.
假设生成的稳态树包括除B-C链接之外的所有链接。网络聚合后，从F开始的数据包将转到F->a。然后a将在a-B链路上发送一个副本，另一个副本发送到桥接LAN，C和D将从中接收该副本。
Now consider a transition stage where A and D have acted on the new LSPs and programmed their forwarding plane, while B and C have not yet done so. This means that B and C both consider the link between them to still be part of the tree. In this case, a packet that starts out from F and reaches A will be copied by A into the A-B link and to the bridged LAN. D's RPF check says to accept packets on this tree coming from F over its port on the bridged LAN, so it gets accepted. D is also adjacent to A on the tree, so the tree adjacency check, a separate check mandated by [RFC6325], also passes.
现在考虑一个过渡阶段，其中A和D已经对新的LSP起作用并编程它们的转发平面，而B和C还没有这样做。这意味着B和C都认为它们之间的联系仍然是树的一部分。在这种情况下，从F开始到达a的数据包将被a复制到a-B链路和桥接LAN。D的RPF检查表示通过桥接LAN上的端口接受来自F的该树上的数据包，因此它被接受。D也与树上的A相邻，因此[RFC6325]强制执行的树邻接检查也会通过。
However, the packet that gets to B gets sent out by B to C. C's RPF check still has the old state, and it thinks the packet is OK. C sends the packet along the old tree, which sends the packet into the bridged LAN. D receives one more packet, but the tree adjacency check passes at D because C is adjacent to D in the new tree as well. The RPF check also passes at D because D's port on the bridged LAN is OK for receiving packets from F.
然而，到达B的数据包被B发送到C。C的RPF检查仍然保持旧状态，并且它认为数据包是正常的。C沿着老树发送数据包，老树将数据包发送到桥接LAN。D再接收一个数据包，但树邻接检查在D处通过，因为C在新树中也与D相邻。RPF检查也在D通过，因为桥接LAN上的D端口可以从F接收数据包。
So, during this transient state, D gets duplicates of every multi-destination packet ingressed at F (unless the packet gets pruned) until B and C act on the new LSPs and program their forwarding tables.
因此，在这个瞬态期间，D在F处获得每个进入的多目的地数据包的副本（除非该数据包被删减），直到B和C作用于新的LSP并编程它们的转发表。
The problem stems from the RPF check described in [RFC6325] depending only on the port at which a TRILL Data packet is received, the ingress nickname, and the tree being used, that is, a check if {ingress nickname, tree, input port} is a valid combination according to the receiving TRILL switch's view of the campus topology. A multi-access link actually has multiple adjacencies overlaid on one physical link, and to avoid the problem shown in Section 3.6.1, a stronger check is needed that includes the Layer 2 source address of
问题源于[RFC6325]中描述的RPF检查，该检查仅取决于接收TRILL数据包的端口、入口昵称和使用的树，即，根据接收TRILL交换机的校园拓扑视图，检查{ingress昵称、树、输入端口}是否为有效组合。一个多址链路实际上在一个物理链路上覆盖了多个邻接，为了避免第3.6.1节所示的问题，需要进行更严格的检查，包括
the TRILL Data packet being received. (TRILL is a Layer 3 protocol, and TRILL switches are true routers that logically strip the Layer 2 header from any arriving TRILL Data packets and add the appropriate new Layer 2 header to any outgoing TRILL Data packet to get it to the next TRILL switch, so the Layer 2 source address in a TRILL Data packet identifies the immediately previous TRILL switch that forwarded the packet.)
正在接收的颤音数据包。（TRILL是第3层协议，TRILL交换机是真正的路由器，从逻辑上从任何到达的TRILL数据包中剥离第2层报头，并将适当的新的第2层报头添加到任何传出的TRILL数据包中，以将其发送到下一个TRILL交换机，因此TRILL数据包中的第2层源地址标识上一个TRILL转发数据包的交换机。）
What is needed, instead of checking the validity of the triplet {ingress nickname, tree, input port}, is to check that the quadruplet {ingress nickname, source SNPA, tree, input port} is valid (where "source SNPA" (Subnetwork Point of Attachment) is the Outer.MacSA for an Ethernet link). Although it is true that [RFC6325] also requires a check to ensure that a multi-destination TRILL Data packet is from a TRILL switch that is adjacent in the distribution tree being used, this check is separate from the RPF check, and these two independent checks are not as powerful as the single unified check for a valid quadruplet.
需要的不是检查三元组{ingress昵称，tree，input port}的有效性，而是检查四元组{ingress昵称，source SNPA，tree，input port}是否有效（其中“source SNPA”（子网连接点）是以太网链路的Outer.MacSA）。虽然[RFC6325]确实也需要进行检查，以确保多目标TRILL数据包来自所使用的分发树中相邻的TRILL交换机，但该检查与RPF检查是分开的，并且这两个独立的检查不如有效的四重组的单一统一检查强大。
_______
/ \
RB1 ------ o ----- RB2
\_______/
_______
/ \
RB1 ------ o ----- RB2
\_______/
However, this stronger RPF check is not without cost. In the simple case of a multi-access link where each TRILL switch has only one port on the link, it merely increases the size of validity entries by adding the source SNPA (Outer.MacSA). However, assume that some TRILL switch RB1 has multiple ports attached to a multi-access link. In the figure above, RB1 is shown with three ports on the multi-access link. RB1 is permitted to load split multi-destination traffic it is sending into the multi-access link across those ports (Section 4.4.4 of [RFC6325]). Assume that RB2 is another TRILL switch on the link and RB2 is adjacent to RB1 in the distribution tree. The number of validity quadruplets at RB2 for ingress nicknames whose multi-destination traffic would arrive through RB1 is multiplied by the number of ports RB1 has on the access link, because RB2 has to accept such traffic from any such ports. Although such instances seem to be very rare in practice, the number of ports an RBridge has on a link could in principle be tens or even a hundred or more ports, vastly increasing the RPF check state at RB2 when this stronger RPF check is used.
然而，这种更强的RPF检查并非没有成本。在多址链路的简单情况下，每个TRILL交换机在链路上只有一个端口，它只是通过添加源SNPA（Outer.MacSA）来增加有效性条目的大小。但是，假设某个TRILL交换机RB1有多个端口连接到多址链路。在上图中，RB1在多址链路上显示了三个端口。允许RB1通过这些端口（RFC6325第4.4.4节）将其发送到多址链路的拆分多目的地流量加载。假设RB2是链路上的另一个颤音开关，并且RB2与分发树中的RB1相邻。由于RB2必须接受来自任何此类端口的此类流量，因此其多目的地流量将通过RB1到达的入口昵称在RB2处的有效四字节数乘以RB1在接入链路上的端口数。尽管这种情况在实践中似乎非常罕见，但RBridge在链路上拥有的端口数原则上可能是几十个甚至一百个或更多个端口，当使用这种更强的RPF检查时，RB2上的RPF检查状态会大大增加。
Another potential cost of the stronger RPF check is increased transient loss of multi-destination TRILL Data packets during a topology change. For TRILL switch D, the new stronger RPF check is (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1), while the old one was (tree->A, Outer.MacSA=C, ingress=A, arrival port=if1).
增强RPF检查的另一个潜在成本是在拓扑更改期间多目标TRILL数据包的瞬时丢失增加。对于TRILL交换机D，新的更强RPF检查是（树->A，外部.MacSA=A，入口=A，到达端口=if1），而旧的检查是（树->A，外部.MacSA=C，入口=A，到达端口=if1）。
Suppose that both A and B have switched to the new tree for multicast forwarding but D has not updated its RPF check yet; the multicast packet will then be dropped at D's input port, because D still expects a packet from "Outer.MacSA=C". But we do not have this packet loss issue if the weaker triplet check (tree->A, ingress=A, arrival port=if1) is used. Thus, the stronger check can increase the RPF check discard of multi-destination packets during topology transients.
假设A和B都已切换到新树进行多播转发，但D尚未更新其RPF检查；然后，多播数据包将在D的输入端口丢弃，因为D仍然需要来自“Outer.MacSA=C”的数据包。但是如果使用较弱的三元组检查（树->A，入口=A，到达端口=if1），则不会出现此数据包丢失问题。因此，更强的检查可以在拓扑瞬态期间增加多目的地分组的RPF检查丢弃。
Because of these potential costs, implementation of this stronger RPF check is optional. The TRILL base protocol is updated to provide that TRILL switches MUST, for multi-destination packets, either implement the RPF and other checks as described in [RFC6325] or implement this stronger RPF check as a substitute for the [RFC6325] RPF and tree adjacency checks. There is no problem with a campus having a mixture of TRILL switches, some of which implement one of these RPF checks and some of which implement the other.
由于这些潜在的成本，这种更强的RPF检查的实现是可选的。TRILL基本协议已更新，以规定TRILL交换机对于多目标数据包必须执行[RFC6325]中所述的RPF和其他检查，或者执行此更强的RPF检查，以替代[RFC6325]RPF和树邻接检查。校园混合使用TRILL交换机是没有问题的，其中一些交换机实现这些RPF检查中的一个，而另一些交换机实现另一个。
Nickname selection is covered by Section 3.7.3 of [RFC6325]. However, the following should be noted:
[RFC6325]第3.7.3节介绍了昵称选择。但是，应注意以下几点：
1. The second sentence in the second bullet item in Section 3.7.3 of [RFC6325] on page 25 is erroneous [Err3002] and is corrected as follows:
1. 第25页[RFC6325]第3.7.3节第二个项目符号中的第二句错误[Err3002]，更正如下：
o The occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
o “IS-IS ID（LAN ID）”的出现被替换为“优先级”。
o The occurrence of "IS-IS System ID" is replaced with "7-byte IS-IS ID (LAN ID)".
o 出现的“IS-IS系统ID”替换为“7字节IS-IS ID（LAN ID）”。
The resulting corrected sentence in [RFC6325] reads as follows:
[RFC6325]中更正后的句子如下：
If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher priority keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher 7-byte IS-IS ID (LAN ID) keeps the nickname, and the other RBridge MUST select a new nickname.
如果RB1选择昵称x，并且RB1在以后任何时候通过接收RB2的LSP发现RB2也选择了x，则具有较高优先级的RBridge或伪节点保留昵称，或者如果优先级相同，则具有较高7字节is-is ID（LAN ID）的RBridge保留昵称，另一个RBridge必须选择一个新的昵称。
2. In examining the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL switches MUST be ignored, but nicknames held by IS-IS reachable TRILL switches MUST NOT be ignored even if they are data unreachable.
2. 在检查链路状态数据库中的昵称冲突时，必须忽略IS-IS不可访问TRILL开关持有的昵称，但IS-IS可访问TRILL开关持有的昵称不得忽略，即使它们是数据不可访问的。
3. An RBridge may need to select a new nickname, either initially because it has none or because of a conflict. When doing so, the RBridge MUST consider as available all nicknames that do not appear in its link-state database or that appear to be held by IS-IS unreachable TRILL switches; however, it SHOULD give preference to selecting new nicknames that do not appear to be held by any TRILL switch in the campus, reachable or unreachable, so as to minimize conflicts if IS-IS unreachable TRILL switches later become reachable.
3. RBridge可能需要选择一个新的昵称，最初可能是因为它没有昵称，也可能是因为冲突。当这样做时，R桥必须考虑可用的所有昵称，这些昵称没有出现在其链路状态数据库中，或者看来是由IS-IS不可到达的Trip交换机所持有；但是，它应该优先选择新的昵称，这些昵称似乎不由校园中的任何TRILL交换机持有，可访问或不可访问，以便在IS-IS不可访问TRILL交换机以后变得可访问时将冲突降至最低。
4. An RBridge, even after it has acquired a nickname for which there appears to be no conflicting claimant, MUST continue to monitor for conflicts with the nickname or nicknames it holds. It does so by monitoring any received LSPs that should update its link-state database for any occurrence of any of its nicknames held with higher priority by some other TRILL switch that is IS-IS reachable from it. If it finds such a conflict, it MUST select a new nickname, even when in overloaded state. (It is possible to receive an LSP that should update the link-state database but does not do so due to overload.)
4. RBridge即使在获得了一个似乎没有冲突索赔人的昵称之后，也必须继续监控与它所拥有的一个或多个昵称的冲突。它通过监视任何接收到的LSP来实现这一点，LSP应该更新其链路状态数据库，以防其昵称被其他某个TRILL开关（可从其访问）以更高的优先级持有。如果它发现这样的冲突，它必须选择一个新的昵称，即使在重载状态下也是如此。（可以接收应更新链路状态数据库的LSP，但由于过载而无法更新。）
5. In the very unlikely case that an RBridge is unable to obtain a nickname because all valid RBridge nicknames (0x0001 through 0xFFBF inclusive) are in use with higher priority by IS-IS reachable TRILL switches, it will be unable to act as an ingress, egress, or tree root but will still be able to function as a transit TRILL switch. Although it cannot be a tree root, such an RBridge is included in distribution trees computed for the campus unless all its neighbors are overloaded. It would not be possible to send a unicast RBridge Channel message specifically to such a TRILL switch [RFC7178]; however, it will receive unicast RBridge Channel messages sent by a neighbor to the Any-RBridge egress nickname and will receive appropriate multi-destination RBridge Channel messages.
5. 在极不可能的情况下，由于is-is可达颤音开关以更高的优先级使用所有有效的RBridge昵称（0x0001到0xFFBF），RBridge无法获得昵称，它将无法充当入口、出口或树根，但仍能充当传输颤音开关。尽管不能是树根，但除非其所有邻居都过载，否则此类RBridge将包含在为校园计算的分布树中。不可能专门向这种颤音交换机发送单播RBridge信道消息[RFC7178]；然而，它将接收邻居发送到任意RBridge出口昵称的单播RBridge信道消息，并将接收适当的多目的地RBridge信道消息。
MTU values in TRILL are derived from the originatingL1LSPBufferSize value communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is the minimum value of originatingL1LSPBufferSize for the RBridges in a campus, but not less than 1470. The MTU testing mechanism and limiting LSPs to Sz assure that the LSPs can be flooded by IS-IS and thus that IS-IS can operate properly.
以颤音表示的MTU值源自IS-IS-IS-IS-ORIGININGLSPBUFFERSIZE TLV[IS-IS]中传达的原始L1LSPBUFFERSIZE值。如[RFC6325]第4.3.1节所述，校园范围内的值Sz是校园内RBridge的初始L1LSPBufferSize的最小值，但不小于1470。MTU测试机制和限制LSP至Sz可确保LSP可被IS-IS淹没，从而IS-IS可正常运行。
If an RBridge knows nothing about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, the originatingL1LSPBufferSize for that RBridge should default to the minimum of the LSP size that its TRILL IS-IS software can handle and the minimum MTU of the ports that it might use to receive or transmit LSPs. If an RBridge does have knowledge of link MTUs or other RBridge originatingL1LSPBufferSize, then, to avoid the necessity of regenerating the local LSPs using a different maximum size, the RBridge's originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) the smallest value that other RBridges are, or will be, announcing as their originatingL1LSPBufferSize and (2) a value small enough that the campus will not partition due to a significant number of links with limited MTUs. However, as specified in [RFC6325], in no case can originatingL1LSPBufferSize be less than 1470. In a well-configured campus, to minimize any LSP regeneration due to resizing, all RBridges will be configured with the same originatingL1LSPBufferSize.
如果RBridge不知道链路的MTU或校园中其他RBridge的起始L1LSPBufferSize，则该RBridge的起始L1LSPBufferSize应默认为其TRILL IS-IS软件可以处理的LSP大小的最小值，以及它可能用于接收或传输LSP的端口的最小MTU。如果RBridge确实知道链路MTU或其他RBridge发端L1lspBufferSize，则为了避免使用不同的最大大小重新生成本地LSP的必要性，RBridge的发端L1lspBufferSize应配置为其他RBridge是或将是的最小值（1），宣布其初始值为l1spBufferSize和（2）一个足够小的值，该值足以使校园不会因大量链接和有限的MTU而分区。但是，如[RFC6325]中所述，在任何情况下，发起L1LSPBufferSize都不能小于1470。在配置良好的校园中，为了最大限度地减少因调整大小而导致的任何LSP重新生成，所有RBridge都将配置为相同的原始L1LSPBufferSize。
Section 5.1 below corrects errata in [RFC6325], and Section 5.2 clarifies the meaning of various MTU limits for TRILL Ethernet links.
下面第5.1节更正了[RFC6325]中的勘误表，第5.2节澄清了TRILL以太网链路的各种MTU限制的含义。
Three MTU-related errata in [RFC6325] are corrected in the subsections below.
[RFC6325]中的三个MTU相关勘误表在以下小节中进行了更正。
Section 4.3.2 of [RFC6325] incorrectly states that multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links with the All-RBridges multicast address as the Outer.MacDA [Err3004]. As TRILL IS-IS PDUs, when multicast on an Ethernet link, these multi-destination MTU-probe and MTU-ack PDUs MUST be sent to the All-IS-IS-RBridges multicast address.
[RFC6325]第4.3.2节错误地指出，多目标MTU探测器和MTU ack TRILL IS-IS PDU通过以太网链路发送，所有RBridges多播地址作为Outer.MacDA[Err3004]。作为TRILL IS-IS PDU，当在以太网链路上进行多播时，必须将这些多目标MTU探测和MTU确认PDU发送到All IS RBridges多播地址。
As discussed in [RFC6325] and (in more detail) [RFC7177], MTU-probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of [RFC6325] erroneously does not allow for this possibility [Err3003]. It is corrected by replacing Item 1 in Section 4.6.2 of [RFC6325] with the following text, to which TRILL switches MUST conform:
如[RFC6325]和（更详细地）[RFC7177]中所述，MTU探测和MTU ack PDU可以是单播的；然而，[RFC6325]第4.6节错误地不允许这种可能性[Err3003]。通过将[RFC6325]第4.6.2节中的第1项替换为以下文本进行纠正，颤音开关必须符合以下文本：
1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All-IS-IS-RBridges or the unicast MAC address of the receiving RBridge port, the frame is handled as described in Section 4.6.2.1.
1. 如果Ethertype为L2-is-is，且Outer.MacDA为All is RBridges或接收RBridge端口的单播MAC地址，则按照第4.6.2.1节所述处理帧。
The reference to "Section 4.6.2.1" in the above text is to that section in [RFC6325].
上文中提及的“第4.6.2.1节”指的是[RFC6325]中的该节。
The last two sentences of Section 4.3.2 of [RFC6325] contain errors [Err3053]. They currently read as follows:
[RFC6325]第4.3.2节的最后两句包含错误[Err3053]。目前案文如下：
If X is not greater than Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
如果X不大于Sz，则RB1在RB1的Hello中为RB2设置“最小MTU测试失败”标志。如果大小X成功，且X>Sz，则RB1在该链接上发送的颤音Hellos中为每个邻接播发最大的测试X，并且RB1可以在RB1的LSP中将X作为链接的属性播发给RB2。
They should read as follows:
其内容如下：
If X is not greater than or equal to Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X >= Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
如果X不大于或等于Sz，则RB1在RB1的Hello中为RB2设置“最小MTU测试失败”标志。如果大小X成功，且X>=Sz，则RB1在该链接上发送的颤音Hellos中为每个邻接播发最大的测试X，并且RB1可以在RB1的LSP中将X作为链接的属性播发给RB2。
originatingL1LSPBufferSize is the maximum permitted size of LSPs starting with and including the IS-IS 0x83 "Intradomain Routeing Protocol Discriminator" byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 bytes. (This is because, in its previous life as DECnet Phase V, IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol Service Access Point) [RFC7042] format, which takes 8 bytes of overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) encoding, this default could have been increased by a few bytes but was not.)
originatingL1LSPBufferSize是LSP允许的最大大小，从is-is 0x83“域内路由协议鉴别器”字节开始，包括该字节。在第3层IS-IS中，原始L1LSPBufferSize默认为1492字节。（这是因为，在其之前的DECnet阶段V中，is-is是使用SNAP SAP（子网访问协议服务访问点）[RFC7042]格式编码的，该格式需要8字节的开销和1492+8=1500，这是典型的以太网最大值。当ISO/IEC[is-is]标准化时，使用逻辑链路控制（LLC）编码时，此默认值可以增加几个字节，但没有。）
In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This allows 27 bytes of headroom or safety margin to accommodate legacy devices with the classic Ethernet maximum MTU, despite headers such as an Outer.VLAN.
在TRILL中，originatingL1LSPBufferSize默认为1470字节。这允许27字节的净空或安全裕度，以容纳具有经典以太网最大MTU的传统设备，尽管存在诸如Outer.VLAN之类的标头。
Assuming that the campus-wide minimum link MTU is Sz, RBridges on Ethernet links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of the PDU starting just after the L2-IS-IS Ethertype and ending just before the Ethernet Frame Check Sequence (FCS)) does not exceed Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded by an amount that depends on the size being tested (which may exceed Sz).
假设校园范围内的最小链路MTU为Sz，以太网链路上的RBridge必须限制大多数TRILL is-is PDU，以便PDUz（PDU的长度在L2-is-is以太类型之后开始，在以太网帧检查序列（FCS）之前结束）不超过Sz。PDU例外情况包括TRILL Hello PDU，其不得超过1470字节，以及MTU probe和MTU ack PDU，其填充量取决于测试的大小（可能超过Sz）。
Sz does not limit TRILL Data packets. They are only limited by the MTU of the devices and links that they actually pass through; however, links that can accommodate IS-IS PDUs up to Sz would accommodate, with a generous safety margin, TRILL Data packet payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS.
Sz不限制TRILL数据包。它们仅受实际通过的设备和链路的MTU限制；然而，能够容纳IS-IS PDU至Sz的链路将能够容纳（Sz-24）字节的TRILL数据包有效负载，该负载从Inner.VLAN之后开始，在FCS之前结束。
Most modern Ethernet equipment has ample headroom for frames with extensive headers and is sometimes engineered to accommodate 9 KB jumbo frames.
大多数现代以太网设备都有足够的净空空间来容纳具有大量报头的帧，并且有时设计为可容纳9KB的巨型帧。
Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports but may not be completely clear on the effects of all combinations of bits in terms of allowed frame types.
[RFC6325]第4.9.1节规定了RBridge端口的四种模式位，但可能不完全清楚允许的帧类型对所有位组合的影响。
The table below explicitly indicates the effects of all possible combinations of the TRILL port mode bits. "*" in one of the first four columns indicates that the bit can be either zero or one. The remaining columns indicate allowed frame types. The "disable bit" normally disables all frames; however, as an implementation choice, some or all low-level Layer 2 control messages can still be sent or received. Examples of Layer 2 control messages are those control frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP link negotiation messages [RFC6361].
下表明确指出了TRILL端口模式位的所有可能组合的影响。前四列中的一列中的“*”表示该位可以是零或一。其余列表示允许的框架类型。“禁用位”通常禁用所有帧；然而，作为一种实现选择，仍然可以发送或接收部分或全部低级第2层控制消息。第2层控制消息的示例为[RFC6325]第1.4节中确定的以太网控制帧或PPP链路协商消息[RFC6361]。
+-+-+-+-+--------+-------+-------+-------+-------+
|D| | | | | | | | |
|i| |A| | | | TRILL | | |
|s| |c|T| |Native | Data | | |
|a| |c|r| |Ingress| | | |
|b|P|e|u| | | LSP | | |
|l|2|s|n|Layer 2 |Native | SNP | TRILL | P2P |
|e|P|s|k|Control |Egress | MTU | Hello | Hello |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-------+-------+-------+
+-+-+-+-+--------+-------+-------+-------+-------+
|D| | | | | | | | |
|i| |A| | | | TRILL | | |
|s| |c|T| |Native | Data | | |
|a| |c|r| |Ingress| | | |
|b|P|e|u| | | LSP | | |
|l|2|s|n|Layer 2 |Native | SNP | TRILL | P2P |
|e|P|s|k|Control |Egress | MTU | Hello | Hello |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-------+-------+-------+
The formal name of the "access bit" above is the "TRILL traffic disable bit". The formal name of the "trunk bit" is the "end-station service disable bit" [RFC6325].
上面“访问位”的正式名称是“TRILL流量禁用位”。“中继位”的正式名称为“终端站服务禁用位”[RFC6325]。
In May 2011, the IEEE promulgated IEEE Std 802.1Q-2011, which changed the meaning of the bit between the priority and VLAN ID bits in the payload of C-VLAN tags. Previously, this bit was called the CFI (Canonical Format Indicator) bit [802] and had a special meaning in connection with IEEE 802.5 (Token Ring) frames. After 802.1Q-2011 and in subsequent versions of 802.1Q -- the most current of which is
2011年5月，IEEE颁布了IEEE标准802.1Q-2011，该标准改变了C-VLAN标签有效载荷中优先级和VLAN ID位之间的位的含义。在此之前，该位被称为CFI（规范格式指示符）位[802]，在IEEE 802.5（令牌环）帧中具有特殊意义。在802.1Q-2011之后以及802.1Q的后续版本中——最新版本是
[802.1Q-2014] -- this bit is now the DEI (Drop Eligibility Indicator) bit. (The corresponding bit in S-VLAN/B-VLAN tags has always been a DEI bit.)
[802.1Q-2014]--此位现在是DEI（丢弃合格性指示器）位。（S-VLAN/B-VLAN标记中的对应位始终是DEI位。）
The TRILL base protocol specification [RFC6325] assumed, in effect, that the link by which end stations are connected to TRILL switches and the restricted virtual link provided by the TRILL Data packet are IEEE 802.3 Ethernet links on which the CFI bit is always zero. Should an end station be attached by some other type of link, such as a Token Ring link, [RFC6325] implicitly assumed that such frames would be canonicalized to 802.3 frames before being ingressed, and similarly, on egress, such frames would be converted from 802.3 to the appropriate frame type for the link. Thus, [RFC6325] required that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in Section 4.1.1 of [RFC6325], always be zero.
TRILL基本协议规范[RFC6325]实际上假设，终端站连接到TRILL交换机的链路和TRILL数据包提供的受限虚拟链路是CFI位始终为零的IEEE 802.3以太网链路。如果终端站通过某种其他类型的链路（例如令牌环链路）连接，则[RFC6325]隐含地假设，在进入之前，这些帧将被规范化为802.3帧，并且类似地，在出口时，这些帧将从802.3转换为链路的适当帧类型。因此，[RFC6325]要求internal.VLAN中的CFI位（在[RFC6325]第4.1.1节中显示为“C”位）始终为零。
However, for TRILL switches with ports conforming to the change incorporated in the IEEE 802.1Q-2011 standard, the bit in the Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by the port interface on ingressing a native frame. Similarly, this bit MUST be provided to the port when transiting or egressing a TRILL Data packet. As with the 3-bit Priority field, the DEI bit to use in forwarding a transit packet MUST be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI and priority bits, and whether or not an Outer.VLAN appears at all on the wire for output frames, may depend on output port configuration.
但是，对于端口符合IEEE 802.1Q-2011标准中包含的更改的TRILL交换机，Inner.VLAN中的位（现在是DEI位）必须设置为端口接口在进入本机帧时提供的DEI值。类似地，在传输或导出TRILL数据包时，必须向端口提供该位。与3位优先级字段一样，转发传输数据包时使用的DEI位必须取自Inner.VLAN。对Outer.VLAN DEI和优先级位的确切影响，以及Outer.VLAN是否出现在输出帧的线路上，可能取决于输出端口配置。
TRILL campuses with a mixture of ports, some compliant with versions of 802.1Q from IEEE Std 802.1Q-2011 onward and some compliant with pre-802.1Q-2011 standards, especially if they have actual Token Ring links, may operate incorrectly and may corrupt data, just as a bridged LAN with such mixed ports and links would.
TRILL校园混合使用端口，一些符合IEEE Std 802.1Q-2011之后的802.1Q版本，一些符合802.1Q-2011之前的标准，特别是如果它们具有实际的令牌环链路，可能会运行不正确，并可能损坏数据，就像具有此类混合端口和链路的桥接LAN一样。
This section covers Extended Level 1 Flooding Scope (E-L1FS) support, control packet priorities, unknown PDUs, the Nickname Flags APPsub-TLV, graceful restart, and the Purge Originator Identification TLV.
本节涵盖扩展的1级泛洪范围（E-L1FS）支持、控制数据包优先级、未知PDU、昵称标志APPsub TLV、正常重启和清除发起人标识TLV。
TRILL switches MUST support E-L1FS PDUs [RFC7356] and MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send indicating support for this scope and any other FS-LSP scopes that they support. This support increases the number of fragments available for link-state information by over two orders of magnitude. (See Section 9 for further information on support of the Scope Flooding Support TLV.)
TRILL交换机必须支持E-L1FS PDU[RFC7356]，并且必须在其发送的所有TRILL Hello中包含作用域泛洪支持TLV[RFC7356]，表明对该作用域及其支持的任何其他FS-LSP作用域的支持。这种支持将链接状态信息可用的片段数量增加了两个数量级以上。（有关支持范围泛洪支持TLV的更多信息，请参见第9节。）
In addition, TRILL switches MUST advertise their support of E-L1FS flooding in a TRILL-VER sub-TLV Capability Flag (see [RFC7176] and Section 12.2). This flag is used by a TRILL switch, say RB1, to determine support for E-L1FS by some remote RBx. The alternative of simply looking for an E-L1FS FS-LSP originated by RBx fails because (1) RBx might support E-L1FS flooding but is not originating any E-L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs there might, due to legacy TRILL switches in the campus, be no path between RBx and RB1 through TRILL switches supporting E-L1FS flooding. If that were the case, no E-L1FS FS-LSP originated by RBx could get to RB1.
此外，TRILL交换机必须在TRILL-VER子TLV能力标志中宣传其对E-L1FS泛洪的支持（见[RFC7176]和第12.2节）。TRILL开关（如RB1）使用此标志来确定某个远程RBx对E-L1FS的支持。简单地寻找由RBx发起的E-L1FS-LSP的替代方案失败，因为（1）RBx可能支持E-L1FS泛洪，但不会发起任何E-L1FS LSP；（2）即使RBx发起E-L1FS LSP，由于校园中的传统TRILL交换机，也可能会，通过支持E-L1FS泛洪的TRILL交换机，RBx和RB1之间没有路径。如果是这种情况，则RBx发起的E-L1FS FS-LSP无法到达RB1。
E-L1FS will commonly be used to flood TRILL GENINFO TLVs and enclosed TRILL APPsub-TLVs [RFC7357]. For robustness, E-L1FS fragment zero MUST NOT exceed 1470 bytes in length; however, if such a fragment is received that is larger, it is processed normally. It is anticipated that in the future some particularly important TRILL APPsub-TLVs will be specified as being flooded in E-L1FS fragment zero. TRILL GENINFO TLVs MUST NOT be sent in LSPs; however, if one is received in an LSP, it is processed normally.
E-L1FS通常用于淹没TRILL GENINFO TLV和封闭TRILL APPsub TLV[RFC7357]。为保证健壮性，E-L1FS片段零的长度不得超过1470字节；但是，如果接收到较大的片段，则会正常处理该片段。预计未来一些特别重要的颤音APPsub TLV将被指定为淹没在E-L1FS碎片零中。TRILL GENINFO TLV不得在LSP中发送；但是，如果在LSP中接收到一个，则会正常处理。
A TRILL campus might contain TRILL switches supporting E-L1FS flooding and legacy TRILL switches that do not support E-L1FS or perhaps do not support any [RFC7356] scopes.
TRILL园区可能包含支持E-L1FS泛洪的TRILL交换机和不支持E-L1FS或可能不支持任何[RFC7356]作用域的传统TRILL交换机。
A TRILL switch conformant to this document can always tell which adjacent TRILL switches support E-L1FS flooding from the adjacency table entries on its ports (see Section 9). In addition, such a TRILL switch can tell which remote TRILL switches in a campus support E-L1FS by the presence of a TRILL version sub-TLV in that TRILL switch's LSP with the E-L1FS support bit set in the Capabilities field; this capability bit is ignored for adjacent TRILL switches for which only the adjacency table entry is consulted to determine E-L1FS support.
符合本文档要求的TRILL交换机始终可以从其端口上的邻接表条目判断哪些相邻TRILL交换机支持E-L1FS泛洪（请参见第9节）。此外，这样的TRILL交换机可以通过在该TRILL交换机的LSP中存在TRILL版本子TLV以及在“能力”字段中设置的E-L1FS支持位来判断校园中的哪些远程TRILL交换机支持E-L1FS；对于相邻TRILL交换机，此功能位被忽略，仅参考邻接表条目来确定E-L1FS支持。
TRILL specifications making use of E-L1FS MUST specify how situations involving a mixed TRILL campus of TRILL switches will be handled.
使用E-L1FS的TRILL规范必须规定如何处理涉及TRILL交换机混合TRILL园区的情况。
In a campus where all TRILL switches support E-L1FS, all TRILL sub-TLVs listed in Section 2.3 of [RFC7176], except the TRILL version sub-TLV, MAY be advertised by inclusion in Router Capability or MT-Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL version sub-TLV still MUST appear in an LSP fragment zero.)
在所有TRILL交换机都支持E-L1FS的园区内，[RFC7176]第2.3节中列出的所有TRILL子TLV（TRILL版本子TLV除外）可通过在E-L1FS LSP[RFC7356]中包含路由器功能或MT功能TLV来进行宣传。（颤音版本子TLV仍然必须出现在LSP片段零中。）
In a mixed campus where some TRILL switches support E-L1FS and some do not, then only the following four sub-TLVs of those listed in Section 2.3 of [RFC7176] can appear in E-L1FS, and then only under the conditions discussed below. In the following list, each sub-TLV is preceded by an abbreviated acronym used only in this section of this document:
在一些TRILL交换机支持E-L1FS而有些不支持的混合校园中，则只有[RFC7176]第2.3节中列出的以下四个子TLV可以出现在E-L1FS中，并且只有在下面讨论的条件下。在以下列表中，每个子TLV前面都有一个仅在本文件本节中使用的缩写首字母缩写词：
IV: Interested VLANs and Spanning Tree Roots sub-TLV VG: VLAN Group sub-TLV IL: Interested Labels and Spanning Tree Roots sub-TLV LG: Label Group sub-TLV
IV：感兴趣的VLAN和生成树根子TLV VG：VLAN组子TLV IL：感兴趣的标签和生成树根子TLV LG：标签组子TLV
An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an E-L1FS FS-LSP (and should instead be advertised in an LSP) unless the following conditions are met:
IV或VG子TLV不得通过E-L1FS FS-LSP中的颤音开关RB1播发（而应在LSP中播发），除非满足以下条件：
- E-L1FS is supported by all of the TRILL switches that are data reachable from RB1 and are interested in the VLANs mentioned in the IV or VG sub-TLV, and
- E-L1FS由所有TRILL交换机支持，这些交换机可以从RB1访问数据，并且对IV或VG子TLV中提到的VLAN感兴趣，以及
- there is E-L1FS connectivity between all such TRILL switches in the campus interested in the VLANs mentioned in the IV or VG sub-TLV (connectivity involving only intermediate TRILL switches that also support E-L1FS).
- 校园内对IV或VG子TLV中提到的VLAN感兴趣的所有此类TRILL交换机之间存在E-L1FS连接（连接仅涉及也支持E-L1FS的中间TRILL交换机）。
Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS LSPs by any TRILL switch that has enough room in its LSPs.
任何IV和VG子TLV仍然可以通过核心TRILL IS-IS LSP由任何在其LSP中有足够空间的TRILL交换机进行广告。
The conditions for using E-L1FS for the IL and LG sub-TLVs are the same as for IV and VG, but with Fine-Grained Labels [RFC7172] substituted for VLANs.
IL和LG子TLV使用E-L1F的条件与IV和VG相同，但用细粒度标签[RFC7172]代替VLAN。
Note, for example, that the above would permit a contiguous subset of the campus that supported Fine-Grained Labels and E-L1FS to use E-L1FS to advertise IL and LG sub-TLVs, even if the remainder of the campus did not support Fine-Grained Labels or E-L1FS.
例如，请注意，上述情况将允许支持细粒度标签和E-L1F的校园的相邻子集使用E-L1F来公布IL和LG子TLV，即使校园的其余部分不支持细粒度标签或E-L1F。
When deciding what packet to send out a port, control packets used to establish and maintain adjacency between TRILL switches SHOULD be treated as being in the highest-priority category. This includes TRILL IS-IS Hello and MTU PDUs, and possibly other adjacency [RFC7177] or link-technology-specific packets. Other control and data packets SHOULD be given lower priority so that a flood of such other packets cannot lead to loss of, or inability to establish, adjacency. Loss of adjacency causes a topology transient that can result in reduced throughput; reordering; increased probability of loss of data; and, in the worst case, network partition if the adjacency is a cut point.
在决定发送端口的数据包时，用于建立和维护TRILL交换机之间邻接的控制数据包应被视为具有最高优先级的数据包。这包括TRILL IS-IS Hello和MTU PDU，以及可能的其他邻接[RFC7177]或特定于链路技术的数据包。其他控制和数据包应被赋予较低的优先级，以便此类其他包的泛滥不会导致丢失或无法建立相邻关系。邻接丢失会导致拓扑瞬态，从而导致吞吐量降低；重新排序；数据丢失的概率增加；在最坏的情况下，如果邻接是一个切点，则进行网络划分。
Other important control packets should be given second-highest priority. Lower priorities should be given to data or less important control packets.
其他重要的控制数据包应具有第二高的优先级。对于数据或不太重要的控制数据包，应给予较低的优先级。
Based on the above, control packets can be ordered into priority categories as shown below, based on the relative criticality of these types of messages, where the most critical control packets relate to the core routing between TRILL switches and the less critical control packets are closer to "application" information. (There may be additional control packets, not specifically listed in any category below, that SHOULD be handled as being in the most nearly analogous category.) Although few implementations will actually treat these four categories with different priority, an implementation MAY choose to prioritize more critical messages over less critical. However, an implementation SHOULD NOT send control packets in a lower-priority category with a priority above those in a higher-priority category because, under sufficiently congested conditions, this could block control packets in a higher-priority category, resulting in network disruption.
基于上述情况，可以根据这些消息类型的相对重要性，将控制数据包按如下所示的优先级分类，其中最关键的控制数据包与TRILL交换机之间的核心路由相关，而不太关键的控制数据包更接近“应用”信息。（可能有其他控制数据包，未在下面任何类别中明确列出，应作为最接近类似的类别进行处理。）尽管很少有实现会以不同的优先级处理这四个类别，但实现可能会选择将更关键的消息优先于不太关键的消息。然而，实现不应发送优先级高于高优先级类别的低优先级类别中的控制分组，因为在充分拥挤的条件下，这可能阻塞高优先级类别中的控制分组，从而导致网络中断。
Priority
Category Description
-------- --------------
Priority
Category Description
-------- --------------
4. Hello, MTU-probe, MTU-ack, and other packets critical to establishing and maintaining adjacency. (Normally sent with highest priority, which is priority 7.)
4. 您好，MTU探测、MTU确认和其他对建立和维护邻接关系至关重要的数据包。（通常以最高优先级发送，即优先级7。）
3. LSPs, CSNPs/PSNPs, and other important control packets.
3. LSP、CSNPs/PSNPs和其他重要控制数据包。
2. Circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.
2. 电路范围的FS LSP、FS CSNPs和FS PSNPs。
1. Non-circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.
1. 非电路范围的FS LSP、FS CSNPs和FS PSNPs。
TRILL switches MUST silently discard [IS-IS] PDUs they receive with PDU numbers they do not understand, just as they ignore TLVs and sub-TLVs they receive that have unknown Types and sub-Types; however, they SHOULD maintain a counter of how many such PDUs have been received, on a per-PDU-number basis. (This is not burdensome, as the PDU number is only a 5-bit field.)
TRILL交换机必须无声地丢弃接收到的[IS-IS]PDU及其不理解的PDU编号，就像它们忽略接收到的具有未知类型和子类型的TLV和子TLV一样；但是，他们应在每个PDU编号的基础上保留一个计数器，记录已收到的此类PDU数量。（这并不麻烦，因为PDU编号只是一个5位字段。）
Note: The set of valid [IS-IS] PDUs was stable for so long that some IS-IS implementations may treat PDUs with unknown PDU numbers as a serious error and, for example, an indication that other valid PDUs from the sender are not to be trusted or that they should drop adjacency to the sender if it was adjacent. However, the MTU-probe and MTU-ack PDUs were added by [RFC7176], and now [RFC7356] has added three more new PDUs. Although the authors of this document are not aware of any Internet-Drafts calling for further PDUs, the eventual addition of further new PDUs should not be surprising.
注意：有效的[IS-IS]PDU集稳定了很长时间，因此一些IS-IS实现可能会将具有未知PDU编号的PDU视为严重错误，例如，指示来自发送方的其他有效PDU不受信任，或者如果发送方相邻，则应删除其相邻关系。然而，[RFC7176]添加了MTU探测和MTU确认PDU，现在[RFC7356]又添加了三个新PDU。尽管本文件的作者不知道有任何互联网草案要求进一步的PDU，但最终增加更多的新PDU并不令人惊讶。
An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV [RFC7357] is specified below.
下面指定了TRILL GENINFO TLV[RFC7357]中的可选昵称标志APPsub TLV。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NickFlags (6) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4*K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD K (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NickFlags (6) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4*K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD K (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each NICKFLAG RECORD has the following format:
其中每个NICKFLAG记录具有以下格式：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: NickFlags TRILL APPsub-TLV, set to 6 (NICKFLAGS).
o 类型：NickFlags颤音APPsub TLV，设置为6（NickFlags）。
o Length: 4 times the number of NICKFLAG RECORDS present.
o 长度：存在NICKFLAG记录数的4倍。
o Nickname: A 16-bit TRILL nickname held by the advertising TRILL switch ([RFC6325] and Section 4).
o 昵称：由广告颤音开关（[RFC6325]和第4节）持有的16位颤音昵称。
o IN: Ingress. If this flag is one, it indicates that the advertising TRILL switch may use the nickname in the NICKFLAG RECORD as the Ingress Nickname of TRILL Headers it creates. If the flag is zero, that nickname will not be used for that purpose.
o 在：入口。如果此标志为1，则表示广告颤音开关可以使用NICKFLAG记录中的昵称作为其创建的颤音头的入口昵称。如果标志为零，则该昵称将不会用于该目的。
o RESV: Reserved for additional flags to be specified in the future. MUST be sent as zero and ignored on receipt.
o RESV：保留用于将来指定的其他标志。必须作为零发送，并在收到时忽略。
The entire NickFlags APPsub-TLV is ignored if the Length is not a multiple of 4. A NICKFLAG RECORD is ignored if the nickname it lists is not a nickname owned by the TRILL switch advertising the enclosing NickFlags APPsub-TLV.
如果长度不是4的倍数，则忽略整个NickFlags APPsub TLV。如果NICKFLAG记录列出的昵称不是TRILL开关所拥有的昵称，则会忽略该昵称记录，该开关用于宣传所包含的NickFlags APPsub TLV。
If a TRILL switch intends to use a nickname in the Ingress Nickname field of TRILL Headers it constructs, it can advertise this through E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry with the IN flag set. If it owns only one nickname, there is no reason to do this because, if a TRILL switch advertises no NickFlags APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed that the TRILL switch might use any or all nicknames it owns as the Ingress Nickname in TRILL Headers it constructs. If a TRILL switch advertises any NickFlags APPsub-TLV entries with the IN flag set, then it MUST NOT use any other nickname(s) it owns as the Ingress Nickname in TRILL Headers it constructs.
如果TRILL交换机打算在其构造的TRILL报头的入口昵称字段中使用昵称，它可以使用带有in标志集的NickFlags APPsub TLV条目，通过E-L1FS LSP（参见第8.1节）进行通告。如果TRILL交换机只拥有一个昵称，则没有理由这样做，因为如果TRILL交换机在为其拥有的昵称设置IN标志的情况下没有播发NickFlags APPsub TLV，则假定TRILL交换机可以使用其拥有的任何或所有昵称作为其构建的TRILL头中的入口昵称。如果TRILL交换机使用IN标志集播发任何NickFlags APPsub TLV条目，则它不得使用其拥有的任何其他昵称作为其构造的TRILL标头中的入口昵称。
Every reasonable effort should be made to be sure that Nickname sub-TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync. If all TRILL switches in a campus support E-L1FS, so that Nickname sub-TLVs can be advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any NickFlags APPsub-TLVs for any particular nickname SHOULD be advertised in the same fragment. If they are not in the same fragment, then, to the extent practical, all fragments involving those sub-TLVs for the same nickname should be propagated as an atomic action. If a TRILL switch sees multiple NickFlags APPsub-TLV entries for the same nickname, it assumes that that nickname might be used as the ingress in a TRILL Header if any of the NickFlags APPsub-TLV entries have the IN bit set.
应尽一切合理努力确保昵称子TLV[RFC7176]和NickFlags APPsub TLV保持同步。如果校园中的所有TRILL交换机都支持E-L1FS，因此可以在E-L1FS LSP中公布昵称子TLV，则任何特定昵称的昵称子TLV和任何NickFlags APPsub TLV应在同一片段中公布。如果它们不在同一个片段中，那么，在实际可行的范围内，涉及相同昵称的子TLV的所有片段都应该作为原子动作进行传播。如果TRILL开关看到同一昵称的多个NickFlags APPsub TLV条目，则它假设如果任何NickFlags APPsub TLV条目具有in位集，则该昵称可以用作TRILL头中的入口。
It is possible that a NickFlags APPsub-TLV would not be propagated throughout the TRILL campus due to legacy TRILL switches not supporting E-L1FS. In that case, Nickname sub-TLVs MUST be advertised in LSPs, and TRILL switches not receiving NickFlags APPsub-TLVs having entries with the IN flag set will simply assume that the source TRILL switch might use any of its nicknames as the ingress in constructing TRILL Headers. Thus, the use of this optional APPsub-TLV is backward compatible with legacy lack of E-L1FS support.
由于传统TRILL交换机不支持E-L1FS，NickFlags APPsub TLV可能不会在TRILL园区内传播。在这种情况下，昵称子TLV必须在LSP中公布，并且不接收具有In标志集的条目的NickFlags APPsub TLV的TRILL交换机将简单地假设源TRILL交换机可以使用其任何昵称作为构建TRILL报头的入口。因此，此可选APPsub TLV的使用与缺少E-L1FS支持的遗留问题向后兼容。
(Additional flags are assigned from those labeled RESV above and specified in [TRILL-L3-GW] and [Centralized-Replication].)
（附加标志由上面标记为RESV的标志指定，并在[TRILL-L3-GW]和[Centralized Replication]中指定。）
TRILL switches SHOULD support the features specified in [RFC5306], which describes a mechanism for a restarting IS-IS router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating link-state database synchronization. If this feature is not supported, it may increase the number of topology transients caused by a TRILL switch rebooting due to errors or maintenance.
TRILL交换机应支持[RFC5306]中规定的功能，该功能描述了一种重新启动IS-IS路由器的机制，以向其邻居发出重新启动的信号，使其能够在不通过关闭状态循环的情况下重新建立其邻接，同时仍能正确启动链路状态数据库同步。如果不支持此功能，它可能会增加由于错误或维护导致TRILL开关重新启动而导致的拓扑瞬态数。
To ease debugging of any purge-related problems, TRILL switches SHOULD include the Purge Originator Identification TLV [RFC6232] in all purge PDUs in TRILL IS-IS. This includes Flooding Scope LSPs [RFC7356] and ESADI LSPs [RFC7357].
为便于调试任何与吹扫相关的问题，TRILL开关应在TRILL IS-IS中的所有吹扫PDU中包含吹扫发起人标识TLV[RFC6232]。这包括泛洪范围LSP[RFC7356]和ESADI LSP[RFC7357]。
To support the E-L1FS flooding scope [RFC7356] mandated by Section 8.1 and backward compatibility with legacy RBridges not supporting E-L1FS flooding, this document updates [RFC7177] as follows:
为支持第8.1节规定的E-L1FS泛洪范围[RFC7356]，并与不支持E-L1FS泛洪的传统RBridges向后兼容，本文件对[RFC7177]进行如下更新：
1. The list in the second paragraph of Section 3.1 of [RFC7177] is updated by adding the following item:
1. [RFC7177]第3.1节第二段中的列表通过添加以下项目进行更新：
o The Scope Flooding Support TLV.
o 作用域泛洪支持TLV。
In addition, the sentence immediately after that list is updated by this document to read as follows:
此外，本文件将紧随该清单之后的一句话更新如下：
Of course, (a) the priority, (b) the Desired Designated VLAN, (c) the Scope Flooding Support TLV, and whether or not the (d) PORT-TRILL-VER sub-TLV and/or (e) BFD-Enabled TLV are included, and their value if included, could change on occasion. However, if these change, the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN.
当然，（a）优先级，（b）所需的指定VLAN，（c）作用域泛洪支持TLV，以及是否包括（d）PORT-TRILL-VER子TLV和/或（e）启用BFD的TLV，以及它们的值（如果包括），有时可能会发生变化。但是，如果这些更改，无论VLAN如何，LAN端口上的所有TRILL Hello都必须同样使用新值。
2. This document adds another bullet item to the end of Section 3.2 of [RFC7177], as follows:
2. 本文件在[RFC7177]第3.2节末尾增加了另一个项目符号，如下所示：
o The value from the Scope Flooding Support TLV, or a null string if none was included.
o 作用域泛洪支持TLV的值，如果不包括，则为空字符串。
3. Near the bottom of Section 3.3 of [RFC7177], this document adds the following bullet item:
3. 在[RFC7177]第3.3节底部附近，本文件添加了以下项目符号：
o The variable-length value part of the Scope Flooding Support TLV in the Hello, or a null string if that TLV does not occur in the Hello.
o 作用域泛洪的可变长度值部分支持Hello中的TLV，如果该TLV未出现在Hello中，则为空字符串。
4. At the beginning of Section 4 of [RFC7177], this document adds a bullet item to the list, as follows:
4. 在[RFC7177]第4节开头，本文件在列表中添加了一个项目符号，如下所示：
o The variable-length value part of the Scope Flooding Support TLV used in TRILL Hellos sent on the port.
o 作用域泛洪支持TLV的可变长度值部分，用于在端口上发送的TRILL Hello。
5. This document adds a line to Table 4 ("TRILL Hello Contents") in Section 8.1 of [RFC7177], as follows:
5. 本文件在[RFC7177]第8.1节的表4（“TRILL Hello内容”）中添加了一行，如下所示：
LAN P2P Number Content Item
--- --- ------ ---------------------------
LAN P2P Number Content Item
--- --- ------ ---------------------------
M M 1 Scope Flooding Support TLV
M 1范围泛洪支持TLV
The TRILL Header has been updated from its original specification in [RFC6325] by [RFC7455] and [RFC7179] and is further updated by this document. The TRILL Header is now as shown in the figure below (which is followed by references for all of the fields). Those fields for which the reference is only to [RFC6325] are unchanged from that RFC.
TRILL标头已由[RFC7455]和[RFC7179]从[RFC6325]中的原始规范更新，并由本文件进一步更新。TRILL标题现在如下图所示（后面是所有字段的引用）。仅引用[RFC6325]的字段与该RFC保持不变。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Flags Word :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Flags Word :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In calculating a TRILL Data packet hash as part of equal-cost multipath selection, a TRILL switch MUST ignore the value of the "A" and "C" bits.
在计算TRILL数据包散列作为等成本多路径选择的一部分时，TRILL交换机必须忽略“a”和“C”位的值。
In [RFC6325] and [RFC7179], there is a TRILL Header Extension Length field called "Op-Length", which is hereby changed to consist of the RESV field and "F" bit shown above.
在[RFC6325]和[RFC7179]中，有一个称为“Op Length”的TRILL报头扩展长度字段，在此将其更改为包含上述RESV字段和“F”位。
o V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325].
o V（版本）：2位无符号整数。见[RFC6325]第3.2节。
o A (Alert): 1 bit. See [RFC7455].
o A（警报）：1位。见[RFC7455]。
o C (Color): 1 bit. See Section 10.1.
o C（颜色）：1位。见第10.1节。
o M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325].
o M（多目标）：1位。见[RFC6325]第3.4节。
o RESV: 4 bits. These bits are reserved and MUST be sent as zero. Due to the previous use of these bits as specified in [RFC6325], most TRILL "fast path" hardware implementations trap and do not forward TRILL Data packets with these bits non-zero. A TRILL
o RESV:4位。这些位是保留的，必须作为零发送。由于之前使用了[RFC6325]中指定的这些位，大多数颤音“快速路径”硬件实现会捕获并不会转发这些位为非零的颤音数据包。颤音
switch receiving a TRILL Data packet with any of these bits non-zero MUST discard the packet unless the non-zero bit or bits have some future use specified that the TRILL switch understands.
接收这些位中任何一位为非零的TRILL数据包的交换机必须丢弃该包，除非非零位或多个位具有TRILL交换机能够理解的某些未来用途。
o F: 1 bit. If this field is non-zero, then the optional flags word described in Section 10.2 is present. If it is zero, the flags word is not present.
o F:1位。如果该字段非零，则出现第10.2节中描述的可选标志字。如果为零，则标志字不存在。
o Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 below.
o 跳数：6位。见[RFC6325]第3.6节和下文第10.2.1节。
o Egress Nickname: See Section 3.7.1 of [RFC6325].
o 出口昵称：见[RFC6325]第3.7.1节。
o Ingress Nickname: See Section 3.7.2 of [RFC6325].
o 入口昵称：见[RFC6325]第3.7.2节。
o Optional Flags Word: See [RFC7179] and Section 10.2.
o 可选标志字：见[RFC7179]和第10.2节。
The Color bit provides an optional way by which ingress TRILL switches MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change this bit. Transit and egress TRILL switches MAY use the Color bit for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis.
颜色位提供了一种可选方式，通过该方式，入口颤音开关可以标记颤音数据包，以实现特定目的。传输颤音开关不得更改此位。过境和出口颤音开关可使用颜色位进行实施相关的交通标记，或进行统计分析或其他类型的交通研究或分析。
When the "F" bit in the TRILL Header is non-zero, the first 32 bits after the Ingress Nickname field provide additional flags. These bits are as specified in [RFC7179], except as changed by the subsections below, in which the Extended Hop Count and Extended Color fields are described. See Section 10.3 for a diagram and summary of these fields.
当TRILL头中的“F”位为非零时，Ingress昵称字段后的前32位提供附加标志。这些位如[RFC7179]中所规定，但以下小节中所述的扩展跃点计数和扩展颜色字段除外。有关这些字段的图表和摘要，请参见第10.3节。
The TRILL base protocol [RFC6325] specifies the Hop Count field in the header, to avoid packets persisting in the network due to looping or the like. However, the Hop Count field size (6 bits) limits the maximum hops a TRILL Data packet can traverse to 64. Optionally, TRILL switches can use a field composed of bits 14 through 16 in the flags word, as specified below, to extend this field to 9 bits. This increases the maximum Hop Count to 512. Except in rare circumstances, reliable use of Hop Counts in excess of 64 requires support of this optional capability at all TRILL switches along the path of a TRILL Data packet.
TRILL-base协议[RFC6325]指定报头中的跳数字段，以避免由于循环等原因而在网络中持续存在数据包。但是，跃点计数字段大小（6位）将TRILL数据包可以穿越的最大跃点限制为64。可选地，TRILL开关可以使用由flags字中的位14到16组成的字段（如下所述），将该字段扩展到9位。这将最大跃点计数增加到512。除非在极少数情况下，可靠地使用超过64跳的跳数需要在沿TRILL数据包路径的所有TRILL交换机上支持此可选功能。
It may be that not all the TRILL switches support the Extended Hop Count mechanism in a TRILL campus and in that campus more than 64 hops are required either for the distribution tree calculated path or for the unicast calculated path plus a reasonable allowance for alternate pathing. As such, it is required that TRILL switches advertise their support by setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header Flags Supported field [RFC7176]; bits 15 and 16 of that field are now specified as Unassigned (see Section 12.2.5).
可能并非所有TRILL交换机都支持TRILL园区中的扩展跃点计数机制，并且在该园区中，分布树计算路径或单播计算路径需要64个以上的跃点加上备用路径的合理余量。因此，要求TRILL交换机通过在TRILL版本子TLV功能和支持的标题标志字段[RFC7176]中设置位14来公布其支持；该字段的位15和16现在指定为未分配（见第12.2.5节）。
If an ingress TRILL switch determines that it should set the Hop Count for a TRILL Data packet to 63 or less, then behavior is as specified in the TRILL base protocol [RFC6325]. If the optional TRILL Header flags word is present, bits 14, 15, and 16 and the critical reserved bit of the critical summary bits are zero.
如果入口TRILL交换机确定应将TRILL数据包的跃点计数设置为63或更少，则行为符合TRILL基本协议[RFC6325]中的规定。如果可选TRILL头标志字存在，则位14、15和16以及关键摘要位的关键保留位为零。
If the Hop Count for a TRILL Data packet should be set to some value greater than 63 but less than 512 and all TRILL switches that the packet is reasonably likely to encounter support Extended Hop Count, then the resulting TRILL Header has the flags word extension present, the high-order 3 bits of the desired Hop Count are stored in the Extended Hop Count field in the flags word, the low-order 5 bits are stored in the Hop Count field in the first word of the TRILL Header, and bit two (the critical reserved bit of the critical summary bits) in the flags word is set to one.
如果TRILL数据包的跃点计数应设置为大于63但小于512的某个值，并且该数据包可能遇到的所有TRILL交换机都支持扩展跃点计数，则生成的TRILL报头具有扩展字标志，所需跃点计数的高阶3位存储在标志字的扩展跃点计数字段中，低阶5位存储在颤音头的第一个字的跃点计数字段中，标志字的位2（关键汇总位的关键保留位）设置为1。
For known unicast traffic (TRILL Header "M" bit zero), an ingress TRILL switch discards the frame if it determines that the least-cost path to the egress is (1) more than 64 hops and not all TRILL switches on that path support the Extended Hop Count feature or (2) more than 512 hops.
对于已知的单播通信量（TRILL报头“M”位零），如果入口TRILL交换机确定到出口的最低成本路径（1）大于64跳，并且该路径上的所有TRILL交换机不支持扩展跳数功能，或者（2）大于512跳，则入口TRILL交换机丢弃帧。
For multi-destination traffic, when a TRILL switch determines that one or more tree paths from the ingress are more than 64 hops and not all TRILL switches in the campus support the Extended Hop Count feature, the encapsulation uses a total Hop Count of 63 to obtain at least partial distribution of the traffic.
对于多目的地业务，当TRILL交换机确定来自入口的一个或多个树路径超过64个跃点并且校园中并非所有TRILL交换机都支持扩展跃点计数功能时，封装使用63的总跃点计数来获得业务的至少部分分布。
A transit TRILL switch supporting Extended Hop Count behaves like a base protocol [RFC6325] TRILL switch in decrementing the Hop Count, except that it considers the Hop Count to be a 9-bit field where the Extended Hop Count field constitutes the high-order 3 bits.
支持扩展跃点计数的传输TRILL交换机在减少跃点计数方面的行为类似于基本协议[RFC6325]TRILL交换机，只是它认为跃点计数是一个9位字段，其中扩展跃点计数字段构成高阶3位。
To be more precise: a TRILL switch supporting Extended Hop Count takes the first of the following actions that is applicable:
更准确地说：支持扩展跃点计数的TRILL交换机执行以下适用操作中的第一个操作：
1. If both the Hop Count and Extended Hop Count fields are zero, the packet is discarded.
1. 如果跃点计数和扩展跃点计数字段均为零，则丢弃数据包。
2. If the Hop Count is non-zero, it is decremented. As long as the Extended Hop Count is non-zero, no special action is taken. If the result of this decrement is zero, the packet is processed normally.
2. 如果跃点计数不为零，则它将递减。只要扩展跃点计数不为零，就不会采取特殊操作。如果减量的结果为零，则数据包将正常处理。
3. If the Hop Count is zero, it is set to the maximum value of 63, and the Extended Hop Count is decremented. If this results in the Extended Hop Count being zero, the critical reserved bit in the critical summary bits is set to zero.
3. 如果跃点计数为零，则将其设置为最大值63，并减小扩展跃点计数。如果这导致扩展跃点计数为零，则关键摘要位中的关键保留位设置为零。
No special behavior is required when egressing a TRILL Data packet that uses the Extended Hop Count. The flags word, if present, is removed along with the rest of the TRILL Header during decapsulation.
当退出使用扩展跃点计数的TRILL数据包时，不需要特殊行为。在解除封装期间，标志字（如果存在）将与颤音标题的其余部分一起移除。
Flags word bits 27 and 28 are specified to be a 2-bit Extended Color field (see Section 10.3). These bits are in the non-critical ingress-to-egress region of the flags word.
标志字位27和28指定为2位扩展颜色字段（见第10.3节）。这些位位于标志字的非关键入口到出口区域。
The Extended Color field provides an optional way by which ingress TRILL switches MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change these bits. Transit and egress TRILL switches MAY use the Extended Color bits for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis.
扩展颜色字段提供了一种可选方式，入口颤音开关可通过该方式标记颤音数据包，以实现特定目的。传输颤音开关不得改变这些位。传输和出口颤音开关可使用扩展的颜色位进行与实现相关的流量标记，或用于统计分析或其他类型的流量研究或分析。
Per Section 2.3.1 of [RFC7176], support for these bits is indicated by the same bits (27 and 28) in the Capabilities and Header Flags Supported field of the TRILL version sub-TLV. If these bits are zero in those capabilities, Extended Color is not supported. A TRILL switch that does not support Extended Color will ignore the corresponding bits in any TRILL Header flags word it receives as part of a TRILL Data packet and will set those bits to zero in any TRILL Header flags word it creates. A TRILL switch that sets or senses the Extended Color field on transmitting or receiving TRILL Data packets MUST set the corresponding 2-bit field in the TRILL version sub-TLV to a non-zero value. Any difference in the meaning of the three possible non-zero values of this 2-bit capability field (0b01, 0b10, or 0b11) is implementation dependent.
根据[RFC7176]第2.3.1节，对这些位的支持由TRILL版本子TLV支持的能力和头标志字段中相同的位（27和28）表示。如果这些功能中的这些位为零，则不支持扩展颜色。不支持扩展颜色的TRILL开关将忽略作为TRILL数据包一部分接收的任何TRILL标头标志字中的相应位，并将其创建的任何TRILL标头标志字中的这些位设置为零。在发送或接收颤音数据包时设置或感测扩展颜色字段的颤音开关必须将颤音版本子TLV中相应的2位字段设置为非零值。此2位功能字段（0b01、0b10或0b11）的三个可能非零值含义的任何差异取决于实现。
With the changes above, the 32-bit flags word extension to the TRILL Header [RFC7179], which is detailed in the "TRILL Extended Header Flags" registry on the "Transparent Interconnection of Lots of Links (TRILL) Parameters" IANA web page, is now as follows:
通过上述更改，TRILL标头[RFC7179]的32位标志字扩展（详见IANA网页“大量链接透明互连（TRILL）参数”上的“TRILL扩展标头标志”注册表）如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
|.....|.........|...........|.....|.......|...........|.........|
|C|C|C| |C|N| | Ext | | |Ext| |
|R|R|R| |R|C| | Hop | | |Clr| |
|H|I|R| |C|C| | Cnt | | | | |
|b|t|s| |A|A| | | | | | |
|H|E|v| |F|F| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
|.....|.........|...........|.....|.......|...........|.........|
|C|C|C| |C|N| | Ext | | |Ext| |
|R|R|R| |R|C| | Hop | | |Clr| |
|H|I|R| |C|C| | Cnt | | | | |
|b|t|s| |A|A| | | | | | |
|H|E|v| |F|F| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 0, 1, and 2 are the critical summary bits, as specified in [RFC7179], consisting of the critical hop-by-hop, critical ingress-to-egress, and critical reserved bits, respectively. The next two fields are specific critical and non-critical hop-by-hop bits -- CHbH and NCHbH, respectively -- containing the Critical and Non-critical Channel Alert flags as specified in [RFC7179]. The next field is the critical reserved bits (CRSV), which are specified herein to be the Extended Hop Count. The non-critical reserved bits (NCRSV) and the critical ingress-to-egress bits (CItE) as specified in [RFC7179] follow. Finally, there is the non-critical ingress-to-egress field, including bits 27 and 28, which are specified herein as the Extended Color field.
位0、1和2是关键汇总位，如[RFC7179]中所述，分别由关键逐跳、关键进出口和关键保留位组成。接下来的两个字段是特定的关键和非关键逐跳位——分别为CHbH和NCHbH——包含[RFC7179]中指定的关键和非关键信道警报标志。下一个字段是关键保留位（CRSV），此处将其指定为扩展跃点计数。[RFC7179]中规定的非关键保留位（NCRSV）和关键入口到出口位（CItE）。最后，存在非关键入口到出口字段，包括比特27和28，其在本文中被指定为扩展颜色字段。
Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on the value of the Appointed Forwarder Status Lost Counter can result in the splitting of Interested VLANs and Spanning Tree Roots sub-TLVs [RFC7176] (or the corresponding Interested Labels and Spanning Tree Roots sub-TLVs where a VLAN is mapped to an FGL) due to differences in this counter value for adjacent VLAN IDs (or 24-bit FGLs). This counter is a mechanism to optimize data-plane learning by trimming the expiration timer for learned addresses on a per-VLAN/FGL basis under some circumstances.
严格遵守[RFC6325]第4.8.3节关于指定转发器状态丢失计数器值的规定可能导致相关VLAN和生成树根子TLV[RFC7176]（或对应的相关标签和生成树根子TLV，其中VLAN映射到FGL）由于相邻VLAN ID（或24位FGL）的计数器值不同。此计数器是一种优化数据平面学习的机制，在某些情况下，可根据每个VLAN/FGL调整学习地址的过期计时器。
The requirement to increment this counter by one whenever a TRILL switch loses Appointed Forwarder status on a port is hereby changed from the mandatory provisions of [RFC6325] to the enumerated provisions below. To the extent that this might cause the Appointed
因此，当TRILL交换机在某个港口失去指定转发器状态时，将该计数器增加1的要求从[RFC6325]的强制性规定更改为以下列举的规定。这可能导致指定的
Forwarder Status Lost Counter to be increased when [RFC6325] indicates that it should not, this will cause data-plane address learning timeouts at remote TRILL switches to be reduced. To the extent that this might cause the Appointed Forwarder Status Lost Counter to remain unchanged when [RFC6325] indicates that it should be increased, this will defeat a reduction in such timeouts that would otherwise occur.
当[RFC6325]指示不应增加转发器状态丢失计数器时，这将导致远程颤音开关处的数据平面地址学习超时减少。如果[RFC6325]指示应增加指定货代状态丢失计数器，则这可能会导致指定货代状态丢失计数器保持不变，否则会导致此类超时的减少。
(1) If any of the following apply, either data-plane address learning is not in use or Appointed Forwarder status is irrelevant. In these cases, the Appointed Forwarder Status Lost Counter MAY be left at zero or set to any convenient value such as the value of the Appointed Forwarder Status Lost Counter for an adjacent VLAN ID or FGL.
(1) 如果以下任何一项适用，则数据平面地址学习未使用或指定的转发器状态无关。在这些情况下，指定转发器状态丢失计数器可以保留为零或设置为任何方便的值，例如相邻VLAN ID或FGL的指定转发器状态丢失计数器的值。
(1a) The TRILL switch port has been configured with the "end-station service disable" bit (also known as the trunk bit) on.
（1a）TRILL交换机端口已配置“终端站服务禁用”位（也称为中继位）。
(1b) The TRILL switch port has been configured in IS-IS as an IS-IS point-to-point link.
（1b）TRILL交换机端口已在IS-IS中配置为IS-IS点到点链路。
(1c) The TRILL switch is relying on ESADI [RFC7357] or Directory Assist [RFC7067] and not using data-plane learning.
（1c）颤音开关依赖于ESADI[RFC7357]或目录辅助[RFC7067]，不使用数据平面学习。
(2) In cases other than those enumerated in point 1 above, the Appointed Forwarder Status Lost Counter SHOULD be incremented as described in [RFC6325]. Such incrementing has the advantage of optimizing data-plane learning. Alternatively, the value of the Appointed Forwarder Status Lost Counter can deviate from that value -- for example, to make it match the value for an adjacent VLAN ID (or FGL), so as to permit greater aggregation of Interested VLANs and Spanning Tree Roots sub-TLVs.
(2) 在上述第1点列举的情况以外的情况下，指定的转发商状态丢失计数器应按照[RFC6325]中的说明递增。这种增量具有优化数据平面学习的优势。或者，指定的转发器状态丢失计数器的值可以偏离该值——例如，使其与相邻VLAN ID（或FGL）的值相匹配，以便允许更大程度地聚合感兴趣的VLAN和生成树根子TLV。
This section lists IANA actions previously completed and new IANA actions.
本节列出了以前完成的IANA操作和新的IANA操作。
The following IANA actions were completed as part of [RFC7180] and are included here for completeness, since this document obsoletes [RFC7180].
以下IANA行动已作为[RFC7180]的一部分完成，并包含在此处以确保完整性，因为本文件已淘汰[RFC7180]。
1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame).
1. [RFC6325]保留的昵称0xFFC1分配用于TRILL报头出口昵称字段中，以指示OOMF（源自过载的多目标帧）。
2. Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service".
2. TRILL neighbor TLV[RFC7176]中每邻居“邻居记录”中七个先前保留（RESV）位中的位1被分配，以指示发送TRILL Hello的RBridge自愿向其SNPA（MAC地址）的TRILL交换机发起的帧提供第2.4.2节中所述的OOMF转发服务出现在该邻居记录中。此位的描述为“提供OOMF服务”。
3. Bit 0 is allocated from the capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in [RFC6439bis]. The description of this bit is "Hello reduction support".
3. 位0是从PORT-TRILL-VER子TLV[RFC7176]中的能力位分配的，以表示支持指定的VLAN子TLV[RFC7176]和[RFC6439bis]中指定的VLAN抑制设置机制。该位的描述是“Hello reduction support”。
The following are new IANA actions for this document.
以下是本文件的新IANA行动。
All references to [RFC7180] in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry have been replaced with references to this document, except that the Reference for bit 0 in the PORT-TRILL-VER Sub-TLV Capability Flags has been changed to [RFC6439bis].
“大量链路透明互连（TRILL）参数”注册表中对[RFC7180]的所有引用均已替换为对本文件的引用，但PORT-TRILL-VER子TLV能力标志中位0的引用已更改为[RFC6439bis]。
There is an existing TRILL version sub-TLV, sub-TLV #13, under both TLV #242 and TLV #144 [RFC7176]. This TRILL version sub-TLV contains a capability bits field for which assignments are documented in the "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters IANA web page. IANA has allocated 4 from the previously reserved
TLV 242和TLV 144下都有一个现有的颤音版本sub-TLV，sub-TLV 13[RFC7176]。此TRILL版本子TLV包含一个能力位字段，其分配记录在TRILL参数IANA网页上的“TRILL-VER子TLV能力标志”注册表中。IANA已从先前保留的资源中分配了4个
bits in this "TRILL-VER Sub-TLV Capability Flags" registry to indicate support of the E-L1FS flooding scope as specified in Section 8.1. This capability bit is referred to as the "E" bit. The following is the addition to the "TRILL-VER Sub-TLV Capability Flags" registry:
“TRILL-VER子TLV能力标志”注册表中的位表示支持第8.1节中规定的E-L1FS泛洪范围。该能力位称为“E”位。以下是对“TRILL-VER子TLV能力标志”注册表的补充：
Bit Description References
---- --------------------- ---------------
4 E-L1FS FS-LSP support [RFC7356], RFC 7780
Bit Description References
---- --------------------- ---------------
4 E-L1FS FS-LSP support [RFC7356], RFC 7780
IANA has assigned an APPsub-TLV number, as follows, under the TRILL GENINFO TLV from the range less than 255.
IANA在TRILL GENINFO TLV下分配了一个APPsub TLV编号，范围小于255，如下所示。
Type Name References
---- --------- -----------
6 NICKFLAGS RFC 7780
Type Name References
---- --------- -----------
6 NICKFLAGS RFC 7780
In addition, IANA has created a registry on its TRILL Parameters web page for NickFlags bit assignments, as follows:
此外，IANA还在TRILL Parameters网页上创建了一个用于NickFlags位分配的注册表，如下所示：
Name: NickFlags Bits Registration Procedure: IETF Review [RFC5226] Reference: RFC 7780
名称：NickFlags位注册程序：IETF审查[RFC5226]参考：RFC 7780
Bit Mnemonic Description Reference
----- -------- ----------- ---------
0 IN Used as ingress RFC 7780
1-15 - Unassigned RFC 7780
Bit Mnemonic Description Reference
----- -------- ----------- ---------
0 IN Used as ingress RFC 7780
1-15 - Unassigned RFC 7780
The "TRILL Extended Header Flags" registry has been updated as follows:
“TRILL扩展标题标志”注册表已更新如下：
Bits Purpose Reference
----- ---------------------------------------- ------------
Bits Purpose Reference
----- ---------------------------------------- ------------
14-16 Extended Hop Count RFC 7780
14-16扩展跃点计数RFC 7780
27-28 Extended Color RFC 7780
27-28扩展彩色RFC 7780
29-31 Available non-critical ingress-to-egress [RFC7179], RFC 7780 flags
29-31可用非关键入口到出口[RFC7179]，RFC 7780标志
The "TRILL-VER Sub-TLV Capability Flags" registry has been updated as follows:
“TRILL-VER子TLV能力标志”注册表已更新如下：
Bit Description Reference
----- -------------------------- ----------------
Bit Description Reference
----- -------------------------- ----------------
14 Extended Hop Count support RFC 7780
14扩展跃点计数支持RFC 7780
15-16 Unassigned RFC 7780
15-16未分配的RFC 7780
27-28 Extended Color support RFC 7780
27-28扩展颜色支持RFC 7780
29-31 Extended header flag support [RFC7179], RFC 7780
29-31扩展标题标志支持[RFC7179]，RFC 7780
As shown in the table below, IANA has assigned a block of eight nicknames for use as examples in documentation. Appendix B shows a use of some of these nicknames. The "TRILL Nicknames" registry has been updated by changing the previous "0xFFC2-0xFFFE Unassigned" line to the following:
如下表所示，IANA分配了八个昵称作为文档中的示例。附录B展示了其中一些昵称的用法。“TRILL昵称”注册表已通过将先前的“0xFFC2-0xFFFE未分配”行更改为以下内容进行更新：
Name Description Reference
------------- -------------- -----------
0xFFC2-0xFFD7 Unassigned
0xFFD8-0xFFDF For use in documentation examples RFC 7780
0xFFE0-0xFFFE Unassigned
Name Description Reference
------------- -------------- -----------
0xFFC2-0xFFD7 Unassigned
0xFFD8-0xFFDF For use in documentation examples RFC 7780
0xFFE0-0xFFFE Unassigned
See [RFC6325] for general TRILL security considerations.
参见[RFC6325]了解一般TRILL安全注意事项。
This memo improves the documentation of the TRILL protocol; corrects six errata in [RFC6325]; updates [RFC6325], [RFC7177], and [RFC7179]; and obsoletes [RFC7180]. It does not change the security considerations of those RFCs, except as follows:
本备忘录改进了TRILL协议的文件编制；修正了[RFC6325]中的六个勘误表；更新[RFC6325]、[RFC7177]和[RFC7179]；和淘汰产品[RFC7180]。它不会改变这些RFC的安全注意事项，以下情况除外：
o E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310], that is, through the inclusion of an IS-IS Authentication TLV in E-L1FS PDUs.
o E-L1FS LSP可以通过IS-IS安全[RFC5310]进行身份验证，也就是说，通过在E-L1FS PDU中包含IS-IS身份验证TLV。
o As discussed in Section 3.6, when using an allowed weaker RPF check under very rare topologies and transient conditions, multi-destination TRILL Data packets can be duplicated; this could have security consequences for some protocols.
o 如第3.6节所述，当在非常罕见的拓扑和瞬态条件下使用允许的较弱RPF检查时，可以复制多目标TRILL数据包；这可能会对某些协议产生安全后果。
[802.1Q-2014] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2014.6991462, IEEE Std 802.1Q-2014.
[802.1Q-2014]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，DOI 10.1109/IEEESTD.2014.6991462，IEEE Std 802.1Q-2014。
[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>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, <http://www.rfc-editor.org/info/rfc5306>.
[RFC5306]Shand，M.和L.Ginsberg，“IS-IS的重启信令”，RFC 5306，DOI 10.17487/RFC5306，2008年10月<http://www.rfc-editor.org/info/rfc5306>.
[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>.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, <http://www.rfc-editor.org/info/rfc6232>.
[RFC6232]Wei，F.，Qin，Y.，Li，Z.，Li，T.，和J.Dong，“IS-IS的清除发起人识别TLV”，RFC 6232，DOI 10.17487/RFC6232，2011年5月<http://www.rfc-editor.org/info/rfc6232>.
[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>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 6361，DOI 10.17487/RFC6361，2011年8月<http://www.rfc-editor.org/info/rfc6361>.
[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>.
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>.
[RFC7179]Eastlake 3rd，D.，Ghanwani，A.，Manral，V.，Li，Y.，和C.Bestler，“大量链接的透明互连（TRILL）：标题扩展”，RFC 7179，DOI 10.17487/RFC7179，2014年5月<http://www.rfc-editor.org/info/rfc7179>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
[RFC7455]Senevirathne，T.，Finn，N.，Salam，S.，Kumar，D.，Eastlake 3rd，D.，Aldrin，S.，和Y.Li，“大量链路的透明互连（TRILL）：故障管理”，RFC 7455，DOI 10.17487/RFC7455，2015年3月<http://www.rfc-editor.org/info/rfc7455>.
[802] IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.
[802]IEEE 802，“局域网和城域网的IEEE标准：概述和体系结构”，DOI 10.1109/IEEESTD.2014.6847097，IEEE Std 802-2014。
[Centralized-Replication] Hao, W., Li, Y., Durrani, M., Gupta, S., Qu, A., and T. Han, "Centralized Replication for BUM traffic in active-active edge connection", Work in Progress, draft-ietf-trill-centralized-replication-03, November 2015.
[集中式复制]Hao，W.，Li，Y.，Durrani，M.，Gupta，S.，Qu，A.，和T.Han，“主动-主动边缘连接中BUM流量的集中式复制”，正在进行的工作，草稿-ietf-trill-Centralized-Replication-032015年11月。
[Err3002] RFC Errata, Erratum ID 3002, RFC 6325.
[Err3002]RFC勘误表，勘误表ID 3002，RFC 6325。
[Err3003] RFC Errata, Erratum ID 3003, RFC 6325.
[Err3003]RFC勘误表，勘误表ID 3003，RFC 6325。
[Err3004] RFC Errata, Erratum ID 3004, RFC 6325.
[Err3004]RFC勘误表，勘误表ID 3004，RFC 6325。
[Err3052] RFC Errata, Erratum ID 3052, RFC 6325.
[Err3052]RFC勘误表，勘误表ID 3052，RFC 6325。
[Err3053] RFC Errata, Erratum ID 3053, RFC 6325.
[Err3053]RFC勘误表，勘误表ID 3053，RFC 6325。
[Err3508] RFC Errata, Erratum ID 3508, RFC 6325.
[Err3508]RFC勘误表，勘误表ID 3508，RFC 6325。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, DOI 10.17487/RFC6327, July 2011, <http://www.rfc-editor.org/info/rfc6327>.
[RFC6327]东湖第三大道、帕尔曼大道、加瓦尼大道、杜特大道和V.曼拉尔大道，“路由桥（RBridges）：邻近”，RFC 6327，DOI 10.17487/RFC6327，2011年7月<http://www.rfc-editor.org/info/rfc6327>.
[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>.
[RFC6439bis] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and H. Fangwei, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-01, January 2016.
[RFC6439bis]Eastlake 3rd，D.，Li，Y.，Umair，M.，Banerjee，A.，和H.Fangwei，“TRILL：指定货运代理”，正在进行的工作，草案-ietf-TRILL-RFC6439bis-01，2016年1月。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<http://www.rfc-editor.org/info/rfc7042>.
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<http://www.rfc-editor.org/info/rfc7067>.
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，DOI 10.17487/RFC7175，2014年5月<http://www.rfc-editor.org/info/rfc7175>.
[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, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<http://www.rfc-editor.org/info/rfc7178>.
[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, DOI 10.17487/RFC7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链接的透明互连（TRILL）：澄清、更正和更新”，RFC 7180，DOI 10.17487/RFC7180，2014年5月<http://www.rfc-editor.org/info/rfc7180>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[TRILL-L3-GW] Hao, W., Li, Y., Qu, A., Durrani, M., Sivamurugan, P., and L. Xia, "TRILL Distributed Layer 3 Gateway", Work in Progress, draft-ietf-trill-irb-10, January 2016.
[TRILL-L3-GW]郝，W.，李，Y.，曲，A.，杜拉尼，M.，西瓦穆鲁甘，P.，和夏立群，“TRILL分布式第3层网关”，正在进行的工作，草案-ietf-TRILL-irb-10，2016年1月。
Appendix A. Life Cycle of a TRILL Switch Port (New)
附录A.TRILL交换机端口的生命周期（新）
Text from <http://www.ietf.org/mail-archive/web/trill/ current/msg06355.html> is paraphrased in this informational appendix.
文本来自<http://www.ietf.org/mail-archive/web/trill/ 本信息性附录对当前/msg06355.html>进行了解释。
Question: Suppose we are developing a TRILL implementation to run on different machines. Then what happens first? Is LSP flooding or ESADI started first? -> Link-state database creation -> Designated RBridge election (How to set priority? Any fixed process that depends on user settings?) -> etc.
问题：假设我们正在开发一个TRILL实现来在不同的机器上运行。那么首先会发生什么？LSP洪泛还是ESADI首先启动？->链接状态数据库创建->指定的RBridge选择（如何设置优先级？取决于用户设置的任何固定进程？->等等。
Answer: The first thing that happens on a port/link is any link setup that is needed. For example, on a PPP link [RFC6361], you need to negotiate that you will be using TRILL. However, if you have Ethernet links [RFC6325], which are probably the most common type, there isn't any link setup needed.
答：在端口/链路上发生的第一件事是任何需要的链路设置。例如，在PPP链接[RFC6361]上，您需要协商您将使用TRILL。但是，如果您有以太网链路[RFC6325]，这可能是最常见的类型，则不需要任何链路设置。
As soon as the port is set up, it can ingress or egress native frames if end-station service is being offered on that port. Offering end-station service is the default. However, if the port trunk bit (end-station service disable) is set or the port is configured as an IS-IS point-to-point link port, then end-station service is not offered; therefore, native frames received are ignored, and native frames are not egressed.
一旦端口设置完毕，如果在该端口上提供终端站服务，它就可以进入或离开本机帧。默认情况下，提供端站服务。但是，如果设置端口中继位（终端站服务禁用）或将端口配置为is-is点到点链路端口，则不提供终端站服务；因此，将忽略接收到的本机帧，并且不会退出本机帧。
TRILL IS-IS Hellos then get sent out the port to be exchanged with any other TRILL switches on the link [RFC7177]. Only the Hellos are required; optionally, you might also exchange MTU-probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test packets.
TRILL IS-IS Hellos然后被发送到端口，以便与链路上的任何其他TRILL交换机交换[RFC7177]。只需要问候；或者，您还可以交换MTU探测/确认PDU[RFC7177]、BFD PDU[RFC7175]或其他链路测试数据包。
TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the port to the link, except for Hellos, until the link gets to the 2-Way or Report state [RFC7177].
TRILL不会将任何TRILL数据或TRILL IS-IS数据包从端口发送到链路（Hellos除外），直到链路进入双向或报告状态[RFC7177]。
If a link is configured as a point-to-point link, there is no Designated RBridge (DRB) election. By default, an Ethernet link is considered a LAN link, and the DRB election occurs when the link is in any state other than Down. You don't have to configure priorities for each TRILL switch (RBridge) to be the DRB. Things will work fine with all the RBridges on a link using default priority. But if the network manager wants to control this, there should be a way for them to configure the priority to be the DRB of the TRILL switch ports on the link.
如果将链路配置为点到点链路，则不存在指定的RBridge（DRB）选择。默认情况下，以太网链路被视为LAN链路，当链路处于除关闭以外的任何状态时，DRB选择发生。您不必为每个颤音开关（RBridge）配置优先级以作为DRB。使用默认优先级，链接上的所有RBridge都可以正常工作。但是，如果网络管理器想要控制这一点，应该有一种方法让他们将优先级配置为链路上TRILL交换机端口的DRB。
(To avoid complexity, this appendix generally describes the life cycle for a link that only has two TRILL switches on it. But TRILL works fine as currently specified on a broadcast link with multiple TRILL switches on it -- actually, multiple TRILL switch ports -- since a TRILL switch can have multiple ports connected to the same link. The most likely way to get such a multi-access link with current technology and the existing TRILL standards is to have more than two TRILL switch Ethernet ports connected to a bridged LAN. The TRILL protocol operates above all bridging; in general, the bridged LAN looks like a transparent broadcast link to TRILL.)
（为了避免复杂性，本附录通常描述了只有两个TRILL交换机的链路的生命周期。但是TRILL可以很好地工作，因为一个TRILL交换机可以有多个端口连接到同一个链路。大多数情况下kely利用当前技术和现有的TRILL标准获得这种多址链路的方法是将两个以上的TRILL交换机以太网端口连接到桥接LAN。TRILL协议的操作首先是桥接；通常，桥接LAN看起来像是到TRILL的透明广播链路。）
When a link gets to the 2-Way or Report state, LSPs, CSNPs, and PSNPs will start to flow on the link (as well as FS-LSPs, FS-CSNPs, and FS-PSNPs for E-L1FS (see Section 8.1)).
当链路进入双向或报告状态时，LSP、CSNPs和PSNPs将开始在链路上流动（以及E-L1FS的FS LSP、FS CSNPs和FS PSNPs（见第8.1节））。
When a link gets to the Report state, there is adjacency. The existence of that adjacency is flooded (reported) to the campus in LSPs. TRILL Data packets can then start to flow on the link as TRILL switches recalculate the least-cost paths and distribution trees to take the new adjacency into account. Until it gets to the Report state, there is no adjacency, and no TRILL Data packets can flow over that link (with the minor corner case exception that an RBridge Channel message can, for its first hop only, be sent on a port where there is no adjacency (Section 2.4 of [RFC7178]). (Although this paragraph seems to be talking about link state, it is actually port state. It is possible for different TRILL switch ports on the same link to temporarily be in different states. The adjacency state machinery runs independently on each port.)
当链接到达报告状态时，存在邻接关系。该邻接的存在被淹没（报告）到LSP中的校园。当TRILL交换机重新计算成本最低的路径和分布树以考虑新的邻接关系时，TRILL数据包可以开始在链路上流动。在到达报告状态之前，没有邻接，也没有颤音数据包可以在该链路上流动（次要的角点情况除外，RBridge信道消息只能在没有邻接的端口上发送，仅用于其第一跳（RFC7178第2.4节））。（虽然本段似乎在讨论链路状态，但实际上是端口状态。同一链路上的不同TRILL交换机端口可能暂时处于不同的状态。相邻状态机制在每个端口上独立运行。）
ESADI [RFC7357] is built on top of the regular TRILL Data routing. Since ESADI PDUs look, to transit TRILL switches, like regular TRILL Data packets, no ESADI PDUs can flow until adjacencies are established and TRILL Data is flowing. Of course, ESADI is optional and is not used unless configured.
ESADI[RFC7357]构建在常规TRILL数据路由之上。由于ESADI PDU看起来像普通TRILL数据包一样，为了传输TRILL交换机，在建立邻接和TRILL数据流动之前，ESADI PDU不能流动。当然，ESADI是可选的，除非配置，否则不会使用。
Question: Does it require TRILL Full Headers at the time TRILL LSPs start being broadcast on a link? Because at that time it's not defined egress and ingress nicknames.
问题：当TRILL LSP开始在链接上广播时，它是否需要TRILL完整标题？因为当时还没有定义出入口和出口的昵称。
Answer: TRILL Headers are only for TRILL Data packets. TRILL IS-IS packets, such as TRILL LSPs, are sent in a different way that does not use a TRILL Header and does not depend on nicknames.
答：TRILL标头仅适用于TRILL数据包。TRILL IS-IS数据包（如TRILL LSP）的发送方式不同，不使用TRILL报头，也不依赖于昵称。
Probably, in most implementations, a TRILL switch will start up using the same nickname it had when it shut down or last got disconnected from a campus. If you want, you can implement TRILL to come up initially not reporting any nickname (by not including a Nickname sub-TLV in its LSPs) until you get the link-state database or most of the link-state database, and then choose a nickname no other TRILL switch in the campus is using. Of course, if a TRILL switch does not have a nickname, then it cannot ingress data, cannot egress known unicast data, and cannot be a tree root.
在大多数实现中，TRILL交换机可能会使用它关闭或上次与校园断开连接时的相同昵称启动。如果您愿意，您可以实现TRILL，在获得链接状态数据库或大部分链接状态数据库之前，最初不报告任何昵称（通过在其LSP中不包括昵称子TLV），然后选择校园中其他TRILL交换机不使用的昵称。当然，如果TRILL开关没有昵称，那么它不能进入数据，不能退出已知的单播数据，也不能是树根。
TRILL IS-IS PDUs such as LSPs, and the link-state database, all work based on the 7-byte IS-IS System ID (sometimes called the LAN ID [IS-IS]). Since topology determination uses System IDs, which are always unique across the campus, it is not affected by the nickname assignment state. The nickname system is built on top of that.
TRILL IS-IS PDU（如LSP）和链路状态数据库，所有工作都基于7字节的IS-IS系统ID（有时称为LAN ID[IS-IS]）。由于拓扑确定使用在整个校园内始终唯一的系统ID，因此不受昵称分配状态的影响。昵称系统就是建立在这个基础之上的。
Appendix B. Example TRILL PDUs (New)
附录B.颤音PDU示例（新）
This appendix shows example TRILL IS-IS PDUs. The primary purpose of these examples is to clarify issues related to bit ordering.
本附录显示了TRILL IS-IS PDU示例。这些示例的主要目的是澄清与位排序相关的问题。
The examples in this appendix concentrate on the format of the packet header and trailer. There are frequently unspecified optional items or data in the packet that would affect header or trailer fields like the packet length or checksum. Thus, an "Xed out" placeholder is used for such fields, where each X represents one hex nibble.
本附录中的示例集中于数据包标头和尾部的格式。数据包中经常存在未指定的可选项或数据，这些项或数据会影响报头或尾部字段，如数据包长度或校验和。因此，一个“Xed out”占位符用于此类字段，其中每个X代表一个十六进制半字节。
A TRILL Hello sent from a TRILL switch (RBridge) with 7-byte System ID 0x30033003300300 holding nickname 0xFFDE over Ethernet from a port with MAC address 0x00005E0053DE on VLAN 1 at priority 7. There is one neighbor that is the DRB. The neighbor's port MAC is 0x00005E0053E3, and the neighbor's System ID is 0x44444444444400.
从VLAN 1上MAC地址为0x00005E0053DE的端口（优先级为7）通过以太网通过7字节系统ID为0x3003300300、昵称为0xFFDE的TRILL交换机（RBridge）发送的TRILL Hello。有一个邻居是DRB。邻居的端口MAC为0x00005E0053E3，邻居的系统ID为0x444400。
Ethernet Header Outer.MacDA, Outer.MacSA 0x0180C2000041 All-IS-IS-RBridges Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0xE001 Priority 7, Outer.VLAN IS-IS 0x22F4 L2-IS-IS Ethertype IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x0F PDU Type (Level 1 LAN Hello) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses Hello PDU Specific Fields 0x01 Circuit Type (Level 1) 0x30033003300300 Source System ID 0x0009 Holding Time 0xXXXX PDU Length 0x40 Priority to be DRB 0x44444444444400 LAN ID TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant)
以太网报头Outer.MacDA，Outer.MacSA 0x0180C2000041全部为RBridges目标MAC地址0x00005E0053DE源MAC地址外部VLAN标签（可选）0x8100 C-VLAN以太类型[802.1Q-2014]0xE001优先级7，Outer.VLAN IS-IS 0x22F4 L2-IS-IS Ethertype IS-IS有效负载公用标头0x83域内路由协议鉴别器0x08标头长度0x01 IS-IS版本号0x06 ID长度6字节PDU类型0x0F（级别1 LAN Hello）0x01版本0x00保留0x01最大区域地址Hello PDU特定字段0x01电路类型（级别1）0x30033003000源系统ID 0x0009保持时间0xXXXX PDU长度0x40优先级为DRB 0x444400 LAN ID TLV（TLV中TLV或子TLV的以下顺序不重要）
Area Addresses TLV 0x01 Area Addresses Type 0x02 Length of Value 0x01 Length of Address 0x00 The fixed TRILL Area Address MT Port Capabilities TLV 0x8F MT Port Capabilities Type 0x0011 Length of Value 0x0000 Topology Special VLANs and Flags Sub-TLV 0x01 Sub-TLV Type 0x08 Length 0x0123 Port ID 0xFFDE Sender Nickname 0x0001 Outer.VLAN 0x0001 Designated VLAN Enabled VLANs Sub-TLV (optional) 0x02 Sub-TLV Type 0x03 Length 0x0001 Start VLAN 1 0x80 VLAN 1 TRILL Neighbor TLV 0x91 Neighbor Type 0x0A Length of Value 0xC0 S Flag = 1, L Flag = 1, SIZE field 0 NEIGHBOR RECORD 0x00 Flags 0x2328 MTU = 9 KB 0x00005E0053E3 Neighbor MAC Address Scope Flooding Support TLV 0xF3 Scope Flooding Support Type 0x01 Length of Value 0x40 E-L1FS Flooding Scope More TLVs (optional) ... Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
区域地址TLV 0x01区域地址类型0x02值的长度0x01地址的长度0x00固定TRILL区域地址MT端口功能TLV 0x8F MT端口功能类型0x0011值的长度0x0000拓扑特殊VLAN和标志子TLV 0x01子TLV类型0x08长度0x0123端口ID 0xFFDE发送方昵称0x0001外部VLAN 0x0001指定的启用VLAN的VLAN子TLV（可选）0x02子TLV类型0x03长度0x0001开始VLAN 1 0x80 VLAN 1 TRILL邻居TLV 0x91邻居类型0x0A长度值0xC0 S标志=1，L标志=1，大小字段0邻居记录0x00标志0x2328 MTU=9 KB 0x00005E0053E3邻居MAC地址作用域泛洪支持TLV 0xF3作用域泛洪支持类型0x01值长度0x40 E-L1FS泛洪作用域更多TLV（可选）。。。以太网帧检查序列（FCS）
Here is an example of a TRILL LSP sent over a PPP link by the same source TRILL switch as the example in Appendix B.1.
以下是由同一源TRILL交换机通过PPP链路发送的TRILL LSP示例，如附录B.1中的示例所示。
PPP Header 0x405D PPP TRILL Link State Protocol IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x12 PDU Type (Level 1 LSP) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses LSP Specific Fields 0xXXXX PDU Length 0x0123 Remaining Lifetime 0x3003300330030009 LSP ID (fragment 9) 0x00001234 Sequence Number 0xXXXX Checksum 0x01 Flags = Level 1 TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant) Router Capability TLV 0xF2 Router Capability Type 0x0F Length of Value 0x00 Flags Nickname Sub-TLV 0x06 Sub-TLV Type 0x05 Length of Value NICKNAME RECORD 0x33 Nickname Priority 0x1234 Tree Root Priority 0xFFDE Nickname TRILL Version Sub-TLV 0x0D Sub-TLV Type 0x05 0x00 Max Version 0x40000000 Flags = FGL Support More TLVs (optional ... PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
PPP标头0x405D PPP TRILL链路状态协议IS-IS有效负载公共标头0x83域内路由协议鉴别器0x08标头长度0x01 IS-IS版本号0x06 ID长度为6字节0x12 PDU类型（级别1 LSP）0x01版本0x00保留0x01最大区域地址LSP特定字段0xXXXX PDU长度0x0123剩余寿命0x300330030009 LSP ID（片段9）0x00001234序列号0xXXXX校验和0x01标志=级别1 TLV（TLV中TLV或子TLV的以下顺序不重要）路由器功能TLV 0xF2路由器功能类型0x0F值长度0x00标志昵称子TLV 0x06子TLV类型0x05值长度昵称记录0x33昵称优先级0x1234树根优先级0xFFDE昵称TRILL版本子TLV 0x0D子TLV类型0x05 0x00最大版本0x40000000标志=FGL支持更多TLV（可选…PPP拖车0xXXXXXX PPP帧检查序列（FCS）
Below is an IPv4 ICMP Echo [RFC792] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 to the neighbor TRILL switch on the link used in Appendix B.1.
下面是一个IPv4 ICMP回显[RFC792]，它以TRILL数据包的形式从TRILL交换机发送，TRILL交换机将附录B.1中的Hello发送到附录B.1中使用的链路上的邻居TRILL交换机。
Ethernet Header Outer.MacDA, Outer.MacSA 0x00005E0053E3 Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0x0001 Priority 0, Outer.VLAN 1 TRILL 0x22F3 TRILL Ethertype TRILL Header 0X000E Flags, Hop Count 14 0xFFDF Egress Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0x00005E005322 Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0800 IPv4 Ethertype IP Header 0x4500 Version 4, Header Length 5, ToS 0 0xXXXX Total Length 0x3579 Identification 0x0000 Flags, Fragment Offset 0x1101 TTL 17, ICMP = Protocol 1 0xXXXX Header Checksum 0xC0000207 Source IP 192.0.2.7 0xC000020D Destination IP 192.0.2.13 0x00000000 Options, Padding ICMP 0x0800 ICMP Echo 0xXXXX Checksum 0x87654321 Identifier, Sequence Number ... Echo Data Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
以太网标头Outer.MacDA，Outer.MacSA 0x00005E0053E3目标MAC地址0x00005E0053DE源MAC地址外部VLAN标记（可选）0x8100 C-VLAN以太类型[802.1Q-2014]0x0001优先级0，Outer.VLAN 1 TRILL 0x22F3 TRILL以太类型TRILL标头0X000E标志，跃点计数14 0xFFDF出口昵称0xFFDC入口昵称内部以太网标头Inner.MacDA，Inner.MacSA 0x00005E005322目标MAC地址0x00005E005344源MAC地址内部VLAN标记0x8100 C-VLAN以太类型0x0022优先级0，Inner.VLAN 34以太类型0x0800 IPv4以太类型IP标头0x4500版本4，标头长度5，ToS 0 0xXXXX总长度0x3579标识0x0000标志，片段偏移量0x1101 TTL 17，ICMP=协议1 0xXXXX头校验和0xC0000207源IP 192.0.2.7 0xC000020D目标IP 192.0.2.13 0x00000000选项，填充ICMP 0x0800 ICMP回显0xXXXX校验和0x87654321标识符，序列号。。。回波数据以太网拖车0xXXXXXXXX以太网帧检查序列（FCS）
Below is an ARP Request [RFC826] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 over a PPP link.
下面是一个ARP请求[RFC826]，它以TRILL数据包的形式从TRILL交换机发送，TRILL交换机通过PPP链路发送附录B.1中的Hello。
PPP Header 0x005D PPP TRILL Network Protocol TRILL Header 0X080D Flags (M = 1), Hop Count 13 0xFFDD Distribution Tree Root Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0xFFFFFFFFFFFF Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0806 ARP Ethertype ARP 0x0001 Hardware Address Space = Ethernet 0x0001 Protocol Address Space = IPv4 0x06 Size of Hardware Address 0x04 Size of Protocol Address 0x0001 OpCode = Request 0x00005E005344 Sender Hardware Address 0xC0000207 Sender Protocol Address 192.0.2.7 0x000000000000 Target Hardware Address 0xC000020D Target Protocol Address 192.0.2.13 PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
PPP报头0x005D PPP TRILL网络协议TRILL报头0X080D标志（M=1），跃点计数13 0xFFDD分发树根昵称0xFFDC入口昵称内部以太网报头Inner.MacDA，Inner.MacSA 0xFFFFFFFFFFFF目标MAC地址0x00005E005344源MAC地址内部VLAN标记0x8100 C-VLAN以太网类型0x0022优先级0，内部.VLAN 34以太网类型0x0806 ARP以太网类型ARP 0x0001硬件地址空间=以太网0x0001协议地址空间=IPv4 0x06硬件地址大小0x04协议地址大小0x0001操作码=请求0x00005E005344发送方硬件地址0xC0000207发送方协议地址192.0.2.7 0x000000000000目标硬件地址0xC000020D目标协议地址192.0.2.13 PPP拖车0xXXXXXX PPP帧检查序列（FCS）
Appendix C. Changes to Previous RFCs (New)
附录C.对先前RFC的变更（新）
This section summarizes the changes, augmentations, and excisions this document specifies for [RFC7180], which it obsoletes and replaces.
本节总结了本文件为[RFC7180]规定的变更、增补和删减，这些变更、增补和删减已被淘汰和取代。
For each section header in this document ending with "(Changed)", this section summarizes the changes that are made by this document:
对于本文档中以“（已更改）”结尾的各节标题，本节总结了本文档所做的更改：
Section 1 ("Introduction"): Numerous changes to reflect the overall changes in contents.
第1节（“导言”）：为反映内容的总体变化而进行的大量变更。
Section 1.1 ("Precedence"): Changed to add mention of [RFC7179].
第1.1节（“优先级”）：更改为增加提及[RFC7179]。
Section 1.3 ("Terminology and Acronyms"): Numerous terms added.
第1.3节（“术语和首字母缩略词”）：增加了许多术语。
Section 3 ("Distribution Trees and RPF Check"): Changed by the addition of the new material in Section 3.6. See Appendix C.1.2, Item 1.
第3节（“分配树和RPF检查”）：因在第3.6节中添加新材料而改变。见附录C.1.2第1项。
Section 8 ("Other IS-IS Considerations"): Changed by the addition of Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.1.2 -- Items 2, 3, 4, and 5, respectively.
第8节（“其他IS-IS考虑因素”）：通过增加第8.1、8.2、8.3和8.4节进行更改。见附录C.1.2——分别为第2、3、4和5项。
Section 9 ("Updates to RFC 7177 (Adjacency)": Changes and additions to [RFC7177] to support E-L1FS. See Appendix C.1.2, Item 2.
第9节（“对RFC 7177（邻接）的更新”）：对[RFC7177]的更改和添加，以支持E-L1FS。见附录C.1.2，第2项。
Section 12 ("IANA Considerations"): Changed by the addition of material in Section 12.2. See Appendix C.1.2, Item 7.
第12节（“IANA注意事项”）：因在第12.2节中添加材料而改变。见附录C.1.2第7项。
Section 13 ("Security Considerations"): Minor changes in the RFCs listed.
第13节（“安全注意事项”）：所列RFC的微小变化。
This document contains the following material not present in [RFC7180]:
本文件包含[RFC7180]中未包含的以下材料：
1. Support for an alternative Reverse Path Forwarding Check (RPFC), along with considerations for deciding between the original [RFC6325] RPFC and this alternative RPFC. This alternative RPFC was originally discussed on the TRILL WG mailing list in <http://www.ietf.org/mail-archive/web/trill/current/ msg01852.html> and subsequent messages (Section 3.6).
1. 支持替代反向路径转发检查（RPFC），以及决定原始[RFC6325]RPFC和此替代RPFC之间的注意事项。这一备选RPFC最初在年的TRILL WG邮件列表中讨论过<http://www.ietf.org/mail-archive/web/trill/current/ msg01852.html>和后续消息（第3.6节）。
2. Mandatory E-L1FS [RFC7356] support (Sections 8.1 and 9).
2. 强制性E-L1FS[RFC7356]支持（第8.1节和第9节）。
3. Recommendations concerning control packet priorities (Section 8.2).
3. 关于控制包优先级的建议（第8.2节）。
4. Implementation requirements concerning unknown IS-IS PDU types (Section 8.3).
4. 关于未知IS-IS PDU类型的实施要求（第8.3节）。
5. Specification of an optional Nickname Flags APPsub-TLV and an ingress flag within that APPsub-TLV (Section 8.4).
5. 指定可选昵称标志APPsub TLV和该APPsub TLV内的入口标志（第8.4节）。
6. Update to the TRILL Header to allocate a Color bit (Section 10.1), and update to the optional TRILL Header Extension flags word to allocate a 2-bit Extended Color field (Section 10.2).
6. 更新TRILL标头以分配颜色位（第10.1节），并更新可选TRILL标头扩展标志字以分配2位扩展颜色字段（第10.2节）。
7. Some new IANA Considerations in Section 12.2, including reservation of nicknames for use as examples in documentation.
7. 第12.2节中的一些新IANA注意事项，包括保留昵称作为文档中的示例。
8. A new "Appointed Forwarder Status Lost Counter" section (Section 11 of this document) that loosens the mandatory update requirements specified in [RFC6325].
8. 新的“指定货代状态丢失柜台”部分（本文件第11节）放松了[RFC6325]中规定的强制性更新要求。
9. Informative Appendix A on the life cycle of a TRILL port.
9. 关于TRILL端口生命周期的资料性附录A。
10. A new Appendix B containing example TRILL PDUs.
10. 包含示例TRILL PDU的新附录B。
11. Recommendation to use the Purge Originator Identification TLV (Section 8.6).
11. 建议使用吹扫发起人标识TLV（第8.6节）。
This document omits the following material that was present in [RFC7180]:
本文件省略了[RFC7180]中的以下材料：
1. All updates to [RFC6327] that occurred in [RFC7180]. These have been rolled into [RFC7177], which obsoletes [RFC6327]. However, new updates to [RFC7177] are included (see Appendix C.3).
1. [RFC7180]中发生的对[RFC6327]的所有更新。这些已被纳入[RFC7177]，淘汰了[RFC6327]。但是，还包括[RFC7177]的新更新（见附录C.3）。
2. All updates to [RFC6439]. These have been rolled into [RFC6439bis], which is intended to obsolete [RFC6439].
2. [RFC6439]的所有更新。这些已被纳入[RFC6439bis]，旨在淘汰[RFC6439]。
This document contains many normative updates to [RFC6325], some of which were also in [RFC7180], which this document replaces. These changes include the following:
本文件包含对[RFC6325]的许多规范性更新，其中一些也包含在本文件取代的[RFC7180]中。这些变化包括：
1. Changing nickname allocation to ignore conflicts with RBridges that are IS-IS unreachable.
1. 更改昵称分配以忽略与无法访问的RBridge的冲突。
2. Fixing errors: [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508].
2. 修复错误：[Err3002]、[Err3003]、[Err3004]、[Err3052]、[Err3053]和[Err3508]。
3. Changing the requirement to use the RPF check described in [RFC6325] for multi-destination TRILL Data packets by providing an alternative stronger RPF check.
3. 通过提供另一种更强的RPF检查，更改了[RFC6325]中描述的对多目标TRILL数据包使用RPF检查的要求。
4. Adoption of the change of the CFI bit, which was required to be zero in the inner frame, to the DEI bit, which is obtained from inner frame ingress or creation.
4. 采用将CFI位（在内部帧中要求为零）更改为DEI位（通过内部帧进入或创建获得）。
5. Requiring that all RBridges support E-L1FS FS-LSP flooding.
5. 要求所有RBridge支持E-L1FS FS-LSP泛洪。
6. Reducing the variable-length TRILL Header extensions area to one optional flags word. The Extension Length field (called "Op-Length" in [RFC6325]) is reduced to 1 bit that indicates whether the flags word is present. The rest of that Length field is now reserved.
6. 将可变长度颤音标题扩展区域减少为一个可选标志字。扩展长度字段（在[RFC6325]中称为“Op Length”）减少为1位，用于指示标志字是否存在。该长度字段的其余部分现在保留。
7. Changing the mandatory Appointed Forwarder Status Lost Counter increment provisions, as specified in Section 11.
7. 根据第11节的规定，更改强制性指定货运代理状态的损失补偿条款。
All of the updates to [RFC7177] herein are in Section 9. Basically, this document requires that a Scope Flooding Support TLV [RFC7356] appear in all Hellos and that TRILL switches retain in their adjacency state the information received in that TLV.
此处[RFC7177]的所有更新见第9节。基本上，本文档要求在所有Hello中都出现作用域泛洪支持TLV[RFC7356]，并且TRILL交换机将在该TLV中接收到的信息保留在其邻接状态。
The updates to [RFC7179] herein are in Sections 10.2 and 10.3.
此处对[RFC7179]的更新见第10.2节和第10.3节。
Acknowledgments
致谢
The contributions of the following individuals to this document are gratefully acknowledged:
感谢以下个人对本文件的贡献：
Santosh Rajagopalan and Gayle Noble
桑托什·拉贾戈帕兰和盖尔·诺布尔
The contributions of the following (listed in alphabetical order) to the preceding version of this document, [RFC7180], are gratefully acknowledged:
感谢以下人员（按字母顺序列出）对本文件先前版本[RFC7180]的贡献：
Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Varun Shah, Mike Shand, and Meral Shirazipour.
索姆纳特·查特吉、魏国豪、拉凯什·库马尔、李益周、拉迪亚·帕尔曼、瓦伦·沙阿、迈克·山德和梅拉尔·西拉齐普尔。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technology 155 Beaver Street Milford, MA 01757 United States
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
Radia Perlman EMC 2010美国华盛顿州贝尔维尤市东北第256大道200号，邮编：98007
Email: radia@alum.mit.edu
Email: radia@alum.mit.edu
Ayan Banerjee Cisco
阿扬·班纳吉·思科
Email: ayabaner@cisco.com
Email: ayabaner@cisco.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States
美国加利福尼亚州圣克拉拉大美洲大道5450号Anoop Ghanwani Dell，邮编95054
Email: anoop@alumni.duke.edu
Email: anoop@alumni.duke.edu
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India
苏杰·古普塔（Sujay Gupta）印度班加罗尔马哈德瓦普拉百周年纪念酒店
Email: sujay.gupta@ipinfusion.com
Email: sujay.gupta@ipinfusion.com