Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8249 X. Zhang
Updates: 6325, 7177, 7780 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
S. Chatterjee
Cisco
September 2017
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8249 X. Zhang
Updates: 6325, 7177, 7780 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
S. Chatterjee
Cisco
September 2017
Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
大量链路的透明互连（TRILL）：MTU协商
Abstract
摘要
The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325, 7177, and 7780.
基本IETF TRILL（大量链路的透明互连）协议具有RFCs 6325和7177中规定的TRILL校园范围MTU功能，该功能确保链路状态更改可以成功地淹没整个校园，同时能够利用校园范围的能力来支持巨型数据包。本文档规定了对MTU功能的建议更新，以针对适当的链路本地数据包，利用超过TRILL校园MTU的链路本地MTU。此外，它还为局部MTU测试指定了一种有效的算法。本文档更新了RFCs 6325、7177和7780。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8249.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8249.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Link-Wide TRILL MTU Size ........................................4
2.1. Operations .................................................5
3. Testing Link MTU Size ...........................................6
4. Refreshing Sz ...................................................8
5. Relationship between Port MTU, Lz, and Sz .......................9
6. LSP Synchronization ............................................10
7. Recommendations for Traffic Link Testing of MTU Size ...........10
8. Backward Compatibility .........................................11
9. Security Considerations ........................................11
10. Additions to Configuration ....................................12
10.1. Per-RBridge Configuration ................................12
10.2. Per-RBridge Port Configuration ...........................12
11. IANA Considerations ...........................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................14
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Link-Wide TRILL MTU Size ........................................4
2.1. Operations .................................................5
3. Testing Link MTU Size ...........................................6
4. Refreshing Sz ...................................................8
5. Relationship between Port MTU, Lz, and Sz .......................9
6. LSP Synchronization ............................................10
7. Recommendations for Traffic Link Testing of MTU Size ...........10
8. Backward Compatibility .........................................11
9. Security Considerations ........................................11
10. Additions to Configuration ....................................12
10.1. Per-RBridge Configuration ................................12
10.2. Per-RBridge Port Configuration ...........................12
11. IANA Considerations ...........................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................14
[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link-state flooding operates properly and all RBridges converge to the same link state. For the proper operation of TRILL (Transparent Interconnection of Lots of Links) IS-IS, all RBridges format their Link State Protocol Data Units (LSPs) to fit in Sz.
[RFC6325]描述了RBridge就校园范围内可接受的最小RBridge间MTU（最大传输单元）大小（称为“Sz”）达成一致的方式，以确保链路状态洪泛正常运行，并且所有RBridge聚合到相同的链路状态。为了使TRILL（大量链路的透明互连）IS-IS正常运行，所有RBridge将其链路状态协议数据单元（LSP）格式化以适合Sz。
[RFC7177] diagrams the state transitions of an adjacency. If MTU testing is enabled, "Link MTU size is successfully tested" is part of an event (event A6) causing the transition from the "2-Way" state [RFC7177] to the "Report" state for an adjacency. This means that the link MTU testing of size x succeeds, and x is greater than or equal to Sz [RFC6325]. If this link cannot support an MTU of Sz, it will not be reported as part of the campus topology.
[RFC7177]绘制了邻接的状态转换。如果启用MTU测试，“链路MTU大小成功测试”是导致邻接从“双向”状态[RFC7177]过渡到“报告”状态的事件（事件A6）的一部分。这意味着尺寸x的链路MTU测试成功，并且x大于或等于Sz[RFC6325]。如果此链接无法支持Sz的MTU，则不会作为校园拓扑的一部分进行报告。
In this document, a new RECOMMENDED link-wide minimum inter-RBridge MTU size, "Lz", is specified. As further discussed in Section 2, by calculating and using Lz as specified herein, link-scoped Protocol Data Units (PDUs) can be formatted greater than Sz, up to the link-wide minimum acceptable inter-RBridge MTU size, potentially improving the efficiency of link utilization and speeding link-state convergence.
在本文件中，指定了一个新的建议链路范围最小RBridge间MTU大小“Lz”。如第2节中进一步讨论的，通过计算和使用本文规定的Lz，链路作用域协议数据单元（pdu）的格式可以大于Sz，达到链路范围内可接受的最小RBridge间MTU大小，从而潜在地提高链路利用率并加速链路状态收敛。
An optional TRILL MTU size-testing algorithm is specified in Section 3 as an efficient method to update the old MTU testing method described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new MTU size-testing method specified in this document is backward compatible with the old one. Multicasting the MTU-probes is recommended when there are multiple RBridges on a link responding to the probing with an MTU-ack [RFC7177]. The testing method and rules of this document are devised in a way that minimizes the number of MTU-probes for testing, therefore reducing the number of multicast packets for MTU testing.
第3节规定了可选的TRILL MTU尺寸测试算法，作为更新[RFC6325]第4.3.2节和[RFC7177]中所述旧MTU测试方法的有效方法。本文件中规定的新MTU尺寸测试方法与旧方法向后兼容。当链路上有多个RBridge用MTU ack响应探测时，建议多播MTU探测[RFC7177]。本文档中的测试方法和规则旨在最大限度地减少用于测试的MTU探测的数量，从而减少用于MTU测试的多播数据包的数量。
This document updates RFCs 6325, 7177, and 7780. The update to [RFC6325] and [RFC7177] is specified in Section 3. The update to [RFC7780] is specified in Section 4.
本文档更新了RFCs 6325、7177和7780。第3节规定了对[RFC6325]和[RFC7177]的更新。第4节规定了对[RFC7780]的更新。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document specifies a new value "Lz" for the minimum acceptable inter-RBridge link MTU size on a local link. Link-wide Lz is the minimum Lz supported and agreed upon amongst all RBridges on a specific link. If the link is usable, Lz will be greater than or equal to Sz.
本文件为本地链路上可接受的最小RBridge间链路MTU大小指定了一个新值“Lz”。链路宽度Lz是特定链路上所有RBridge支持和商定的最小Lz。如果链路可用，Lz将大于或等于Sz。
Some TRILL IS-IS PDUs are exchanged only between neighbors instead of throughout the whole campus. They are confined by the link-wide Lz instead of Sz. Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) are examples of such PDUs. These PDUs are exchanged only on the local link. (While TRILL IS-IS Hellos are also link local, they are always limited to 1470 bytes for robustness.)
一些TRILL IS-IS PDU仅在邻居之间交换，而不是在整个校园内交换。它们受链路范围Lz而非Sz的限制。完整序列号PDU（CSNPs）和部分序列号PDU（PSNPs）是此类PDU的示例。这些PDU仅在本地链路上交换。（虽然TRILL IS-IS Hello也是本地链接，但它们始终被限制为1470字节，以保持健壮性。）
[RFC7356] defines the PDUs that support flooding scopes in addition to area-wide scopes and domain-wide scopes. As specified in [RFC8139], RBridges support the Extended L1 Circuit Scope (E-L1CS) Flooding Scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize for a port is the minimum of the following two quantities but not less than 1470 bytes: (1) the MTU of the port and (2) the maximum LSP size that the TRILL IS-IS implementation can handle. They use that flooding to exchange their maximum supported value of "Lz". The smallest value of the Lz advertised by the RBridges on a link, but not less than Sz, is the link-wide Lz. An RBridge on a local link will be able to tell which other RBridges on that link support E-L1CS FS-LSPs because, as required by [RFC7780], all RBridges include the Scope Flooding Support TLV [RFC7356] in their TRILL Hellos.
[RFC7356]定义了支持泛洪作用域以及区域范围和域范围的PDU。如[RFC8139]所述，RBridges支持扩展L1电路范围（E-L1CS）泛洪范围LSP（FS-LSP）[RFC7780]。端口的originatingSNPBufferSize是以下两个量中的最小值，但不小于1470字节：（1）端口的MTU和（2）TRILL is-is实现可以处理的最大LSP大小。他们使用该泛洪来交换其最大支持值“Lz”。RBridges在链路上公布的Lz的最小值（但不小于Sz）是链路范围的Lz。本地链路上的RBridge将能够告诉该链路上的哪些其他RBridge支持E-L1CS FS LSP，因为按照[RFC7780]的要求，所有RBridge在其颤音hello中都包括作用域泛洪支持TLV[RFC7356]。
The maximum size for a level-1 link-local PDU (such as a PSNP or CSNP) that may be generated by a system is controlled by the value of the management parameter originatingL1SNPBufferSize. This value determines Lz. The TRILL APPsub-TLV shown in Figure 1 SHOULD be included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP fragment zero. If it is missing from an E-L1CS FS-LSP fragment zero or there is no E-L1CS FS-LSP fragment zero, it is assumed that its originating IS is implicitly advertising its originatingSNPBufferSize value as Sz octets.
系统可能生成的1级链路本地PDU（如PSNP或CSNP）的最大大小由发起L1SNPBufferSize的管理参数的值控制。该值确定Lz。图1所示的TRILL APPsub TLV应包含在E-L1CS FS-LSP片段zero中的TRILL GENINFO TLV[RFC7357]中。如果E-L1CS FS-LSP片段零中缺少该值，或者没有E-L1CS FS-LSP片段零，则假定其原始is隐式地将其原始NPBUFFERSIZE值作为Sz八位字节公布。
E-L1CS FS-LSPs are link local and can also be sent up to a size of Lz but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470 bytes.
E-L1CS FS LSP是本地链路，也可以发送到Lz大小，但为了健壮性，E-L1CS FS-LSP片段0不得超过1470字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originatingSNPBufferSize | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originatingSNPBufferSize | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The originatingSNPBufferSize APPsub-TLV
图1：原始NPBufferSize APPsub TLV
Type: Set to the originatingSNPBufferSize APPsub-TLV (TRILL APPsub-TLV type 21). Two bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
类型：设置为原始NPBufferSize APPsub TLV（TRILL APPsub TLV类型21）。两个字节，因为此APPsub TLV显示在扩展TLV[RFC7356]中。
Length: Set to 2.
长度：设置为2。
originatingSNPBufferSize: The local value of originatingL1SNPBufferSize as an unsigned integer, limited to the range from 1470 to 65,535 bytes. (A value less than 1470 will be ignored.)
originatingSNPBufferSize：originatingL1SNPBufferSize的本地值，为无符号整数，限制在1470到65535字节之间。（小于1470的值将被忽略。）
Lz MAY be reported using an originatingSNPBufferSize APPsub-TLV that occurs in fragment zero of the RBridge's E-L1CS FS-LSP. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored. If more than one originatingSNPBufferSize APPsub-TLV occurs in fragment zero, the one advertising the smallest value for originatingSNPBufferSize, but not less than 1470 bytes, is used.
Lz可使用RBridge E-L1CS FS-LSP的零段中出现的原始NPBufferSize APPsub TLV报告。忽略在任何其他片段中出现的原始NPBufferSize APPsub TLV。如果在片段0中出现多个originatingSNPBufferSize APPsub TLV，则使用公布originatingSNPBufferSize最小值但不小于1470字节的一个。
Even if all RBridges on a specific link have reached consensus on the value of link-wide Lz based on advertised originatingSNPBufferSize, it does not mean that these RBridges can safely exchange PDUs between each other. Figure 2 shows such a corner case. RB1, RB2, and RB3 are three RBridges on the same link and their Lz is 1800, so the link-wide Lz of this link is 1800. There is an intermediate bridge (say B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 sends PDUs formatted in chunks of size 1800, those PDUs will be discarded by B1.
即使特定链路上的所有RBridge已根据公布的发端NPBufferSize就链路范围Lz的值达成共识，但这并不意味着这些RBridge可以安全地在彼此之间交换PDU。图2显示了这种情况。RB1、RB2和RB3是同一链路上的三个RBridge，它们的Lz为1800，因此该链路的链路宽度Lz为1800。RB2和RB3之间有一个中间网桥（如B1），其端口MTU大小为1700。如果RB2发送格式化为1800大小块的PDU，则B1将丢弃这些PDU。
Lz:1800 Lz:1800
+---+ | +---+
|RB1|(2000)---|---(2000)|RB2|
+---+ | +---+
|
Lz:1800 |
+---+ +--+
|RB3|(2000)---(1700)|B1|
+---+ +--+
|
Lz:1800 Lz:1800
+---+ | +---+
|RB1|(2000)---|---(2000)|RB2|
+---+ | +---+
|
Lz:1800 |
+---+ +--+
|RB3|(2000)---(1700)|B1|
+---+ +--+
|
Figure 2: Link-Wide Lz = 1800 vs. Tested Link MTU Size = 1700
Figure 2: Link-Wide Lz = 1800 vs. Tested Link MTU Size = 1700
Therefore, the link MTU size SHOULD be tested. After the link MTU size of an adjacency is successfully tested, those link-local PDUs, such as CSNPs, PSNPs, and E-L1CS FS-LSPs, will be formatted no greater than the tested link MTU size and will be safely transmitted on this link.
因此，应测试链路MTU大小。成功测试相邻链路的MTU大小后，这些链路本地PDU（如CSNPs、PSNPs和E-L1CS FS LSP）的格式将不大于测试的链路MTU大小，并将在此链路上安全传输。
As for Sz, RBridges continue to propagate their originatingL1LSPBufferSize across the campus through the advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The smallest value of Sz advertised by any RBridge, but not less than 1470, will be deemed as Sz. Each RBridge formats their "campus-wide" PDUs -- for example, LSPs -- no greater than what they determine as Sz.
至于Sz，RBridges继续通过[RFC6325]第4.3.2节中定义的LSP广告在校园内传播其原始L1LSPBufferSize。任何RBridge公布的Sz最小值（但不小于1470）将被视为Sz。每个RBridge都对其“校园范围”的PDU（例如LSP）进行格式化，但格式不超过它们确定的Sz。
[RFC7177] defines event A6 as indicating that the MTU test was successful if MTU testing is enabled. As described in Section 4.3.2 of [RFC6325], this is a combination of the following event and condition:
[RFC7177]将事件A6定义为，如果启用MTU测试，则表明MTU测试成功。如[RFC6325]第4.3.2节所述，这是以下事件和条件的组合：
o Event: The link MTU size has been tested.
o 事件：链路MTU大小已测试。
o Condition: The link can support Sz.
o 条件：链路可以支持Sz。
This condition can be efficiently tested by the following "binary search algorithm" and rules. This updates [RFC6325] and [RFC7177].
这种情况可以通过以下“二进制搜索算法”和规则进行有效测试。这将更新[RFC6325]和[RFC7177]。
x, lowerBound, and upperBound are local integer variables. The MTU-probe and MTU-ack PDUs are specified in Section 3 of [RFC7176]. It is RECOMMENDED that one Round-Trip Time (RTT) between the two adjacent RBridges be used as the minimum interval between two successive probes. Note that RTT estimation is out of scope for this document. If operators cannot estimate the RTT, the default value of 5 milliseconds should be assumed.
x、 lowerBound和Upper Bound是局部整数变量。[RFC7176]第3节规定了MTU探头和MTU ack PDU。建议将两个相邻RBT桥之间的一个往返时间（RTT）用作两个连续探头之间的最小间隔。请注意，RTT估算超出了本文档的范围。如果操作员无法估计RTT，则应假定默认值为5毫秒。
Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz.
步骤0:RB1发送一个填充到链路宽度Lz大小的MTU探针。
1) If RB1 successfully receives the MTU-ack from RB2 to the probe of the value of link-wide Lz within k tries (where k is a configurable parameter whose default is 3), the link MTU size is set to the size of link-wide Lz. Stop.
1) 如果RB1成功地从RB2接收到MTU ack，并在k次尝试中探测链路范围Lz的值（其中k是一个可配置参数，默认值为3），则链路MTU大小设置为链路范围Lz的大小。停止
2) RB1 tries to send an MTU-probe padded to 1470 bytes.
2) RB1尝试发送填充到1470字节的MTU探测。
a) If RB1 fails to receive an MTU-ack from RB2 after k tries (an MTU-ack should be considered to have failed two RTTs after the probe is sent out), RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. Stop.
a) 如果RB1在k次尝试后未能从RB2接收MTU ack（MTU ack应被视为在发送探测器后两次RTT失败），RB1将在RB1的Hello中为RB2设置“最低MTU测试失败”标志。停止
b) The link MTU size is set to 1470; lowerBound is set to 1470; upperBound is set to the link-wide Lz; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer.
b) 链路MTU大小设置为1470；lowerBound设置为1470；上限设置为链路宽度Lz；x设置为[（下限+上限）/2]，向下舍入为最接近的整数。
Step 1: RB1 tries to send an MTU-probe padded to the size x.
步骤1:RB1尝试发送一个填充到x大小的MTU探针。
1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
1) 如果在k次尝试后RB1未能从RB2接收MTU确认：
upperBound is set to x - 1; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer.
上限设置为x-1；x设置为[（下限+上限）/2]，向下舍入为最接近的整数。
2) If RB1 receives an MTU-ack to a probe of size x from RB2:
2) 如果RB1从RB2接收到尺寸为x的探测器的MTU确认：
The link MTU size is set to x; lowerBound is set to x; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer. If lowerBound equals upperBound - 1, then x is set to upperBound.
链接MTU大小设置为x；lowerBound设置为x；x设置为[（下限+上限）/2]，向下舍入为最接近的整数。如果lowerBound等于上限-1，则x设置为上限。
3) If lowerBound >= upperBound or Step 1 has been repeated n times (where n is a configurable parameter whose default value is 5), stop.
3) 如果lowerBound>=上限或步骤1已重复n次（其中n是默认值为5的可配置参数），则停止。
4) Repeat Step 1.
4) 重复步骤1。
After the testing, the two connected RBridges agree on the value of the link MTU size. MTU testing is only done in the Designated VLAN [RFC7177]. Since the execution of the above algorithm can be resource consuming, it is RECOMMENDED that the Designated RBridge (DRB) [RFC7177] take the responsibility to do the testing. Multicast MTU-probes are used instead of unicast when multiple RBridges are
测试完成后，两个连接的RBridge就链路MTU大小的值达成一致。MTU测试仅在指定的VLAN中进行[RFC7177]。由于上述算法的执行可能会消耗资源，建议指定的RBridge（DRB）[RFC7177]负责进行测试。当需要多个RBU时，使用多播MTU探测代替单播
desired to respond with an MTU-ack on the link. The binary search algorithm given here is a way to minimize the probing attempts; it reduces the number of multicast packets for MTU-probing.
希望通过链路上的MTU确认进行响应。这里给出的二进制搜索算法是一种最小化探测尝试的方法；它减少了用于MTU探测的多播数据包的数量。
The following rules are designed to determine whether the aforementioned "Condition" holds.
以下规则旨在确定上述“条件”是否成立。
RBridges have figured out the upper bound and lower bound of the link MTU size from the execution of the above algorithm. If Sz is smaller than the lower bound or greater than the upper bound, RBridges can directly judge whether the link supports Sz without MTU-probing.
RBridges已通过执行上述算法计算出链路MTU大小的上限和下限。如果Sz小于下限或大于上限，RBridges可以直接判断链路是否支持Sz，而无需MTU探测。
(a) If lowerBound >= Sz, this link can support Sz.
(a) 如果lowerBound>=Sz，此链接可以支持Sz。
(b) Else if upperBound <= Sz, this link cannot support Sz.
(b) 否则，如果上限<=Sz，则此链接不能支持Sz。
Otherwise, RBridges SHOULD test whether the link can support Sz as in item (c) below. If they do not, the only safe assumption will be that the link cannot support Sz. This assumption, without testing, might rule out the use of a link that can, in fact, handle packets up to Sz. In the worst case, this might result in unnecessary network partition.
否则，RBridges应测试链路是否能够支持以下（c）项中的Sz。如果他们不这样做，唯一安全的假设将是链接无法支持Sz。这一假设，在没有测试的情况下，可能会排除使用实际上可以处理高达Sz的数据包的链路。在最坏的情况下，这可能会导致不必要的网络分区。
(c) lowerBound < Sz < upperBound. RBridges probe the link with MTU-probe messages padded to Sz. If an MTU-ack is received within k tries, this link can support Sz. Otherwise, this link cannot support Sz. Through this test, the lower bound and upper bound of the link MTU size can be updated accordingly.
(c) 下限<Sz<上限。RBridges使用填充到Sz的MTU探测消息探测链接。如果在k次尝试中收到MTU确认，则此链接可以支持Sz。否则，此链接无法支持Sz。通过此测试，可以相应地更新链路MTU大小的下限和上限。
RBridges may join or leave the campus; this may change Sz.
RBridges可加入或离开校园；这可能会改变Sz。
1) Joining
1) 连接
a) When a new RBridge joins the campus and its originatingL1LSPBufferSize is smaller than the current Sz, reporting its originatingL1LSPBufferSize in its LSPs will cause other RBridges to decrease their Sz. Then, any LSP greater than the reduced Sz MUST be split, and/or the LSP contents in the campus MUST be otherwise redistributed so that no LSP is greater than the new Sz.
a) 当一个新的RBridge加入校园且其原始L1LSPBufferSize小于当前Sz时，在其LSP中报告其原始L1LSPBufferSize将导致其他RBridge减少其Sz。然后，任何大于缩减Sz的LSP都必须拆分，和/或校园中的LSP内容必须以其他方式重新分配，以便没有LSP大于新Sz。
b) If the joining RBridge's originatingL1LSPBufferSize is greater than or equal to the current Sz, reporting its originatingL1LSPBufferSize will not change Sz.
b) 如果加入RBridge的原始L1LSPBufferSize大于或等于当前Sz，则报告其原始L1LSPBufferSize不会更改Sz。
2) Leaving
2) 离开
a) From the specification of the Joining process, we know that if an RBridge's originatingL1LSPBufferSize is smaller than Sz, this RBridge will not join this campus.
a) 从加入过程的规范中，我们知道如果RBridge的原始L1LSPBufferSize小于Sz，则该RBridge将不会加入该校园。
b) When an RBridge leaves the campus and its originatingL1LSPBufferSize equals Sz, its LSPs are purged from the remainder of the campus after reaching MaxAge [IS-IS]. Sz MAY be recalculated and MAY increase. In other words, while in most cases RB1 ignores link-state information for IS-IS unreachable RBridge RB2 [RFC7780], originatingL1LSPBufferSize is meaningful. Its value, even from IS-IS unreachable RBridges, is used in determining Sz. This updates [RFC7780].
b) 当RBridge离开校园且其原始L1LSPBufferSize等于Sz时，其LSP在达到MaxAge[IS-IS]后从校园的其余部分清除。Sz可能会重新计算并增加。换句话说，虽然在大多数情况下RB1忽略IS-IS不可访问RB2[RFC7780]的链路状态信息，但发起L1LSPBufferSize是有意义的。它的值，即使来自IS-IS不可到达的RBridges，也用于确定Sz。这将更新[RFC7780]。
c) When an RBridge leaves the campus and its originatingL1LSPBufferSize is greater than Sz, Sz will not be updated, since Sz is determined by another RBridge with a smaller originatingL1LSPBufferSize.
c) 当一个RBridge离开校园且其原始L1lspBufferSize大于Sz时，Sz将不会更新，因为Sz由另一个原始L1lspBufferSize较小的RBridge确定。
Frequent LSP "resizing" is harmful to the stability of the TRILL campus, so, to avoid this, upward resizing SHOULD be dampened. When an upward resizing event is noticed by an RBridge, it is RECOMMENDED that a timer be set at that RBridge via a configurable parameter -- LSPresizeTime -- whose default value is 300 seconds. Before this timer expires, all subsequent upward resizing will be dampened (ignored). Of course, in a well-configured campus with all RBridges configured to have the same originatingL1LSPBufferSize, no resizing will be necessary. It does not matter if different RBridges have different dampening timers or if some RBridges resize upward more quickly than others.
频繁的LSP“调整大小”对TRILL校园的稳定性有害，因此，为了避免这种情况，应该抑制向上调整大小。当RBridge注意到向上调整大小的事件时，建议通过可配置参数LSPresizeTime在该RBridge设置计时器，该参数的默认值为300秒。在此计时器过期之前，所有后续的向上调整大小都将被抑制（忽略）。当然，在配置良好的校园中，所有RBridge配置为具有相同的原始L1LSPBufferSize，不需要调整大小。不同的RBridge是否具有不同的阻尼计时器，或者某些RBridge向上调整大小的速度是否比其他RBridge更快，这并不重要。
If the refreshed Sz is smaller than the lower bound or greater than the upper bound of the tested link MTU size, the issue of resource consumption from testing the link MTU size can be avoided according to rule (a) or (b) as specified in Section 3. Otherwise, RBridges test the link MTU size according to rule (c).
如果刷新的Sz小于被测链路MTU大小的下限或大于上限，则可根据第3节中规定的规则（a）或（b）避免测试链路MTU大小的资源消耗问题。否则，RBridges根据规则（c）测试链路MTU大小。
When the port MTU of an RBridge is smaller than the local originatingL1SNPBufferSize of an RBridge (an inconsistent configuration), that port SHOULD be disabled, since, in any case, an adjacency cannot be formed through such a port. On the other hand, when an RBridge receives an LSP or E-L1CS FS-LSP with size greater than the link-wide Lz or Sz but not greater than its port MTU size, this LSP is processed normally. If the size of an LSP is greater
当RBridge的端口MTU小于RBridge的本地发起L1SNPBufferSize（不一致的配置）时，应禁用该端口，因为在任何情况下，都无法通过该端口形成邻接。另一方面，当RBridge接收到大小大于链路宽度Lz或Sz但不大于其端口MTU大小的LSP或E-L1CS FS-LSP时，该LSP被正常处理。如果LSP的大小更大
than the MTU size of a port over which it is to be propagated, this LSP MUST NOT be sent over the port and an LSPTooLargeToPropagate alarm shall be generated [IS-IS].
超过要在其上传播的端口的MTU大小，不得通过端口发送此LSP，并应生成LSPToolarGetOpragate警报[is-is]。
An RBridge participates in LSP synchronization on a link as soon as it has at least one adjacency on that link that has advanced to at least the 2-Way state [RFC7177]. On a LAN link, CSNPs and PSNPs are used for synchronization. On a point-to-point link, only PSNPs are used.
一旦RBridge在链路上至少有一个邻接已升级到至少双向状态，它就参与链路上的LSP同步[RFC7177]。在LAN链路上，CSNPs和PSNPs用于同步。在点到点链路上，仅使用PSNPs。
The CSNPs and PSNPs can be formatted in chunks of size (at most) link-wide Lz but are processed normally if received having a larger size. Since the link MTU size may not have been tested in the 2-Way state, link-wide Lz may be greater than the supported link MTU size. In that case, a CSNP or PSNP may be discarded. After the link MTU size is successfully tested, RBridges will begin to format these PDUs with a size no greater than that MTU; therefore, these PDUs will eventually get through.
CSNPs和PSNPs可以格式化为（最多）链路范围Lz大小的块，但如果接收到的具有较大的大小，则通常会进行处理。由于链路MTU大小可能尚未在双向状态下进行测试，链路宽Lz可能大于支持的链路MTU大小。在这种情况下，可以丢弃CSNP或PSNP。链路MTU大小成功测试后，RBridges将开始格式化这些PDU，其大小不大于该MTU；因此，这些PDU最终会通过。
Note that the link MTU size is frequently greater than Sz. Link-local PDUs are limited in size by the link MTU size rather than Sz, which, when Lz is greater than Sz, promises a reduction in the number of PDUs and a faster LSP synchronization process.
请注意，链接MTU大小通常大于Sz。链路本地PDU的大小受链路MTU大小而不是Sz的限制，当Lz大于Sz时，这将保证减少PDU的数量并加快LSP同步过程。
Sz and link-wide Lz are used to limit the size of most TRILL IS-IS PDUs. They are different from the MTU size restricting the size of TRILL Data packets. The size of a TRILL Data packet is restricted by the physical MTU of the ports and links the packet traverses. It is possible that a TRILL Data packet successfully gets through the campus but its size is greater than Sz or link-wide Lz values.
Sz和链路宽Lz用于限制大多数TRILL IS-IS PDU的大小。它们不同于限制TRILL数据包大小的MTU大小。TRILL数据包的大小受到包所经过的端口和链路的物理MTU的限制。TRILL数据包可能成功通过校园，但其大小大于Sz或链路范围的Lz值。
The algorithm defined for testing the link MTU size can also be used in TRILL traffic MTU size testing; in that case, the link-wide Lz used in that algorithm is replaced by the port MTU of the RBridge sending MTU-probes. The successfully tested size x MAY be advertised as an attribute of this link, using the MTU sub-TLV defined in [RFC7176].
定义用于测试链路MTU大小的算法也可用于TRILL流量MTU大小测试；在这种情况下，该算法中使用的链路范围Lz被RBridge发送MTU探测的端口MTU替换。使用[RFC7176]中定义的MTU子TLV，可以将成功测试的尺寸x作为该链接的属性进行公布。
Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU size from a TRILL campus automatically. An operator may collect these values using network management tools such as TRILL ping or TraceRoute. Then, the path MTU can be set as the smallest tested
与RBridge不同，终端站不参与TRILL IS-IS PDU的交换；因此，他们无法从TRILL校园自动掌握交通链路MTU大小。操作员可以使用网络管理工具（如颤音ping或TraceRoute）收集这些值。然后，可以将路径MTU设置为最小的测试路径
link MTU on this path, and end stations should not generate frames that -- when encapsulated as TRILL Data packets -- exceed this path MTU.
链接此路径上的MTU，并且终端站不应生成帧（封装为TRILL数据包时）超过此路径MTU。
There can be a mixture of Lz-ignorant and Lz-aware RBridges on a link. This configuration will behave properly, although it may not be as efficient as it would be if all RBridges on the link are Lz aware.
链路上可能混合了Lz无知和Lz感知RBridge。此配置将正常运行，尽管其效率可能不如链路上的所有RBridge都具有Lz意识时的效率。
For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted no greater than Sz. Lz-aware RBridges as receivers can handle these PDUs, since they cannot be greater than the link-wide Lz.
对于Lz桥，TRILL IS-IS PDU的格式始终不大于Sz。作为接收器的Lz感知RBRIGE可以处理这些PDU，因为它们不能大于链路范围的Lz。
For an Lz-aware RBridge, in the case that link-wide Lz is greater than Sz, larger link-local TRILL IS-IS PDUs can be sent out to increase efficiency. Lz-ignorant RBridges as receivers will have no problem handling them, since the originatingL1LSPBufferSize value of these RBridges had been tested and the link-wide Lz is not greater than that value.
对于Lz感知的RBridge，在链路宽Lz大于Sz的情况下，可以发送更大的链路本地TRILL is-is PDU以提高效率。Lz作为接收器将不会有任何问题，因为这些RBridge的原始L1LSPBufferSize值已经过测试，链路范围Lz不大于该值。
An Lz-ignorant RBridge might not support the link MTU size-testing algorithm defined in Section 3 but could be using some algorithm just to test for the Sz MTU on the link. In any case, if an RBridge per [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack padded to the same size as the MTU-probe.
Lz桥可能不支持第3节中定义的链路MTU大小测试算法，但可能仅使用某些算法测试链路上的Sz MTU。在任何情况下，如果RBridge per[RFC6325]接收到MTU探针，则它必须使用与MTU探针大小相同的MTU ack进行响应。
This document raises no significant new security issues for TRILL. In TRILL, RBridges are generally considered to be trusted devices. Protection against forged TRILL IS-IS PDUs, including forged Hellos containing originatingSNPBufferSize APPsub-TLVs, can be obtained through IS-IS PDU cryptographic authentication [RFC5310]. The worst that an RBridge can do by reporting an erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable the optimization of being able to use link MTUs that exceed the campus-wide MTU for link-local TRILL IS-IS PDUs.
本文档没有为TRILL提出任何重大的新安全问题。在TRILL中，RBridge通常被认为是可信设备。可通过IS-IS PDU加密身份验证[RFC5310]获得针对伪造TRILL IS-IS PDU的保护，包括包含原始NPBufferSize APPsub TLV的伪造Hello。RBridge通过报告错误的发端NPBufferSize所能做的最坏的事情是将Lz减少到Sz，从而使能够使用超过校园范围MTU的链路本地TRILL is-is PDU的链路MTU的优化不可用。
For general and adjacency-related TRILL security considerations, see [RFC6325] and [RFC7177].
有关一般和邻接相关的颤音安全注意事项，请参阅[RFC6325]和[RFC7177]。
Implementation of the features specified in this document adds two RBridge configuration parameters, as follows:
本文档中规定的功能的实现增加了两个RBridge配置参数，如下所示：
Each RBridge implementing the RECOMMENDED LSP resizing damping strategy specified in Section 4 has an LSPresizeTime parameter that is an integer in the range of 0-65,535 and that defaults to 300. It is the number of seconds for which an RBridge determines that Sz has increased before it will create any LSP or E-L1FS FS-LSP fragments.
实施第4节中规定的建议LSP调整阻尼策略的每个RBridge都有一个LSPresizeTime参数，该参数为0-65535范围内的整数，默认值为300。它是RBridge在创建任何LSP或E-L1FS FS-LSP片段之前确定Sz已增加的秒数。
Each RBridge port on which the calculation and use of Lz are implemented has an originatingL1SNPBufferSize parameter that is an integer in the range of 1470-65,535. This parameter defaults to the minimum of the size that the port can accommodate and the link-local IS-IS PDU size that the TRILL implementation can accommodate.
执行Lz计算和使用的每个RBridge端口都有一个origingL1SNPBufferSize参数，该参数是1470-65535范围内的整数。此参数默认为端口可容纳的最小大小和TRILL实现可容纳的链路本地IS-IS PDU大小。
IANA has assigned a new APPsub-TLV type for the TRILL originatingSNPBufferSize APPsub-TLV defined in Section 2 of this document. This new type has been assigned from the range less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry. The entry is as follows:
IANA已为本文件第2节中定义的TRILL originatingSNPBufferSize APPsub TLV分配了新的APPsub TLV类型。此新类型已从“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中小于256的范围分配。参赛作品如下：
Type Name Reference
---- ------------------------ ---------
21 originatingSNPBufferSize RFC 8249
Type Name Reference
---- ------------------------ ---------
21 originatingSNPBufferSize RFC 8249
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://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月<https://www.rfc-editor.org/info/rfc5310>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://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月<https://www.rfc-editor.org/info/rfc6325>.
[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, <https://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月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc7177>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://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月<https://www.rfc-editor.org/info/rfc7356>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<https://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<https://www.rfc-editor.org/info/rfc7780>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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月。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139]Eastlake 3rd，D.，Li，Y.，Umair，M.，Banerjee，A.，和F.Hu，“大量链接的透明互连（TRILL）：指定的货运代理”，RFC 8139，DOI 10.17487/RFC8139，2017年6月<https://www.rfc-editor.org/info/rfc8139>.
Acknowledgements
致谢
The authors would like to thank Vishwas Manral for his comments and suggestions.
作者感谢Vishwas Manral的评论和建议。
Authors' Addresses
作者地址
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Xudong Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张旭东100095
Email: zhangxudong@huawei.com
Email: zhangxudong@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Dell EMC 505 1st Ave South Seattle, WA 98104 United States of America
美国华盛顿州西雅图南部第一大道505号Radia Perlman Dell EMC，邮编：98104
Email: radia@alum.mit.edu
Email: radia@alum.mit.edu
Somnath Chatterjee Cisco Systems SEZ Unit, Cessna Business Park Outer Ring Road Bangalore 560087 India
印度班加罗尔塞斯纳商业园外环路Somnath Chatterjee Cisco Systems SEZ部门560087
Email: somnath.chatterjee01@gmail.com
Email: somnath.chatterjee01@gmail.com