[要約] RFC 8397は、TRILL（Transparent Interconnection of Lots of Links）マルチレベルを実現するためのUnique Nicknamesの使用に関するものです。このRFCの目的は、TRILLネットワーク内でのユニークなニックネームの使用方法を定義し、ネットワークのスケーラビリティと柔軟性を向上させることです。
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8397 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
H. Zhai
JIT
D. Liu
China Telecom Co., Ltd
May 2018
Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames
多くのリンクの透過的な相互接続（TRILL）固有のニックネームを使用したマルチレベル
Abstract
概要
TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.
IS-ISルーティングのマルチレベル機能を構築することにより、TRILL（多数のリンクの透過的相互接続）ルーティングを拡張して、複数のレベルをサポートできます。ニックネームの管理方法に応じて、TRILLマルチレベルを実現する2つの主要な代替手段があります。RFC8243で説明されているように、一意のニックネームアプローチと集約されたニックネームアプローチです。このドキュメントでは、一意のニックネームアプローチを指定します。このアプローチにより、マルチレベルTRILLキャンパス全体のすべてのTRILLスイッチに一意のニックネームが付けられます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8397.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8397で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Acronyms and Terminology ........................................4
3. Data Routing ....................................................4
3.1. Unicast Routing ............................................4
3.2. Multi-destination Routing ..................................5
3.2.1. Local Distribution Trees ............................6
3.2.2. Global Distribution Trees ...........................6
4. Protocol Basics and Extensions ..................................8
4.1. Multilevel TRILL Basics ....................................8
4.2. Nickname Allocation ........................................9
4.3. Nickname Announcements .....................................9
4.4. Capability Indication .....................................11
5. Mix with Aggregated Nickname Areas .............................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
Contributors ......................................................15
Authors' Addresses ................................................15
The multiple-level feature of [IS-IS] can increase the scalability of TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs some extensions to support the TRILL multilevel feature. The two most significant extensions are how TRILL switch nicknames are managed and how distribution trees are handled [RFC8243].
[ISC-IS]のマルチレベル機能は、[RFC8243]で説明されているように、TRILLのスケーラビリティを向上させることができます。ただし、マルチレベルIS-ISでは、TRILLマルチレベル機能をサポートするためにいくつかの拡張が必要です。最も重要な2つの拡張は、TRILLスイッチのニックネームの管理方法と、配布ツリーの処理方法[RFC8243]です。
There are two primary alternatives to realize TRILL multilevel [RFC8243]. One approach, which is referred to as the "aggregated nickname" approach, involves assigning nicknames to the areas, and allowing nicknames to be reused in different areas by having the border TRILL switches rewrite nickname fields when entering or leaving an area. For more description of the aggregated nickname approach, one can refer to [RFC8243] and [SingleN]. The other approach, which is referred to as the "unique nickname" approach, is specified in this document. The unique nickname approach gives unique nicknames to all the TRILL switches in the multilevel campus by having the TRILL switches at the Level 1 / Level 2 border advertise into the Level 1 area those nicknames are not available for assignment in that area and advertising into the Level 2 area those nicknames that are used by the Level 1 area so that other areas cannot use them anymore. The advertising of Level 1 nicknames informs the rest of the campus how to reach the nicknames residing in that area. In this document, protocol extensions that support such advertisement are specified.
TRILLマルチレベル[RFC8243]を実現するには、主に2つの方法があります。 「集約ニックネーム」アプローチと呼ばれるアプローチの1つは、エリアにニックネームを割り当て、エリアに出入りするときに境界TRILLスイッチでニックネームフィールドを書き換えることで、ニックネームを別のエリアで再利用できるようにすることです。集約されたニックネームアプローチの詳細については、[RFC8243]および[SingleN]を参照できます。 「一意のニックネーム」アプローチと呼ばれるもう1つのアプローチは、このドキュメントで指定されています。ユニークなニックネームアプローチでは、レベル1 /レベル2の境界にあるTRILLスイッチをレベル1のエリアにアドバタイズして、そのエリアでの割り当てやレベルへのアドバタイズに使用できないニックネームを、マルチレベルキャンパスのすべてのTRILLスイッチにユニークなニックネームを付けます。 2レベル1のエリアで使用されているニックネームをエリアにして、他のエリアがそれを使用できないようにします。レベル1のニックネームの広告は、キャンパス内の残りの人に、そのエリアにあるニックネームに到達する方法を知らせます。このドキュメントでは、そのようなアドバタイズをサポートするプロトコル拡張が指定されています。
Each RBridge in a unique nickname area calculates two types of trees: local distribution trees and global distributions trees. For multi-destination traffic that is limited to an area, the packets will be flooded on a local distribution tree. Otherwise, the multi-destination packets will be flooded along a global distribution tree.
固有のニックネーム領域内の各RBridgeは、ローカル分布ツリーとグローバル分布ツリーの2種類のツリーを計算します。エリアに限定された複数の宛先のトラフィックの場合、パケットはローカルの配信ツリーでフラッディングされます。それ以外の場合、マルチ宛先パケットはグローバル配布ツリーに沿ってフラッディングされます。
In the unique nickname approach, nicknames are globally valid so that border RBridges do not rewrite the nickname field of TRILL data packets that transition between Level 1 and Level 2, as border RBridges do in the aggregated nickname approach. If a border RBridge is a transit node on a forwarding path, it does not learn MAC addresses of the TRILL data packets forwarded along this path. Testing and maintenance operations that originate in one area and terminate in a different area are also simplified [RFC8243]. For these reasons, the unique nickname approach might realize simpler border RBridges than the aggregated nickname approach. However, the unique nickname approach is less scalable and may be less well suited for very large campuses.
一意のニックネームアプローチでは、ニックネームはグローバルに有効であるため、ボーダーRBridgeは、集約されたニックネームアプローチでボーダーRBridgeが行うように、レベル1とレベル2の間で遷移するTRILLデータパケットのニックネームフィールドを書き換えません。ボーダーRBridgeが転送パス上のトランジットノードである場合、ボーダーRBridgeは、このパスに沿って転送されるTRILLデータパケットのMACアドレスを学習しません。ある領域で始まり、別の領域で終わるテストおよびメンテナンス操作も簡略化されています[RFC8243]。これらの理由により、独自のニックネームアプローチでは、集約されたニックネームアプローチよりも単純な境界RBridgeを実現できます。ただし、独自のニックネームアプローチは拡張性が低く、非常に大規模なキャンパスにはあまり適していません。
Border RBridge: An RBridge that is located on the border between two or more RBridge areas.
境界RBridge：2つ以上のRBridge領域間の境界にあるRBridge。
Data Label: VLAN or FGL [RFC7172]
データラベル：VLANまたはFGL [RFC7172]
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中間システムから中間システム[IS-IS]
RBridge: A device implementing the TRILL protocol.
RBridge：TRILLプロトコルを実装するデバイス。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325].
TRILL：リンク層の多数のリンクまたはトンネルルーティングの透過的な相互接続[RFC6325]。
TRILL switch: An alternative name for an RBridge.
TRILLスイッチ：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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Area X level 2 Area Y
+-----------------+ +---------------------+ +------------+
| | | | | |
S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D
| 27 | | | | 44 |
| | | | | |
+-----------------+ +---------------------+ +------------+
Figure 1: An Example Topology for TRILL Multilevel
図1：TRILLマルチレベルのトポロジ例
Figure 1 is adapted from the example topology of [RFC8243], where S is Source, and D is Destination.
図1は、[RFC8243]のトポロジーの例を採用したもので、Sは送信元、Dは宛先です。
The routing processes are described in the following two subsections.
ルーティングプロセスについては、次の2つのサブセクションで説明します。
The plain RBridge RB27 has a different view of the topology of the TRILL campus than its border RBridge RB2. For an outward path that reaches an RBridge not in the same area (say, RB44), RB27 calculates the segment of the path in Area X, the border RBridge RB2 calculates the segment in Level 2, while the border RBridge to the destination area, RBridge RB3, calculates the segment from itself to RB44.
プレーンなRBridge RB27は、境界のRBridge RB2とは異なるTRILLキャンパスのトポロジのビューを持っています。同じエリア（RB44など）にないRBridgeに到達する外部パスの場合、RB27はエリアXのパスのセグメントを計算し、境界RBridge RB2はレベル2のセグメントを計算し、宛先エリアへの境界RBridgeはRBridge RB3は、それ自体からRB44までのセグメントを計算します。
Let us say that S transmits a frame to destination D and let us say that D's location is learned by the relevant TRILL switches already. These relevant switches have learned the following:
Sがフレームを宛先Dに送信するとし、Dの位置は関連するTRILLスイッチによってすでに学習されているとしましょう。これらの関連スイッチは、次のことを学習しています。
1) RB27 has learned that D is connected to nickname 44. 2) RB2 has learned that nickname 44 is accessible through RB3.
1）RB27は、Dがニックネーム44に接続されていることを学習しました。2）RB2は、ニックネーム44がRB3を介してアクセス可能であることを学習しました。
The following sequence of events will occur:
次の一連のイベントが発生します。
- S transmits an Ethernet frame with source MAC = S and destination MAC = D.
- Sは、ソースMAC = Sおよび宛先MAC = Dのイーサネットフレームを送信します。
- RB27 encapsulates with a TRILL header with ingress RBridge nickname 27, and egress RBridge nickname 44 producing a TRILL Data packet.
- RB27は、入口RBridgeニックネーム27を持つTRILLヘッダーでカプセル化し、出口RBridgeニックネーム44はTRILLデータパケットを生成します。
- RB2 has announced in the Level 1 IS-IS instance in Area X that it owns all nicknames of other areas, including 44. Therefore, IS-IS routes the packet to RB2.
- RB2は、エリアXのレベル1 IS-ISインスタンスで、44を含む他のエリアのすべてのニックネームを所有していることを発表しました。したがって、IS-ISはパケットをRB2にルーティングします。
- The packet is forwarded through Level 2, from RB2 to RB3, which has advertised, in Level 2, it owns the nickname 44.
- パケットはレベル2を介してRB2からアドバタイズされたRB3に転送され、レベル2ではニックネーム44を所有します。
- RB3, when forwarding into Area Y, does not change the ingress nickname 27 or the egress nickname 44.
- RB3は、エリアYに転送するときに、入力ニックネーム27または出力ニックネーム44を変更しません。
- RB44, when decapsulating, learns that S is attached to nickname 27.
- RB44は、カプセル化を解除するときに、ニックネーム27にSが付加されていることを学習します。
The scope of Multi-destination routing is defined by the tree root nickname. A tree with a Level 2 tree root nickname is global, and a tree with a Level 1 tree root nickname is local. See Section 4.2 for the Level 1 and Level 2 nickname allocation.
複数宛先ルーティングのスコープは、ツリーのルートニックネームによって定義されます。レベル2のツリールートニックネームを持つツリーはグローバルで、レベル1のツリールートニックネームを持つツリーはローカルです。レベル1およびレベル2のニックネームの割り当てについては、セクション4.2を参照してください。
Border RBridges announce the global trees to be calculated only for those Data Labels that span across areas. APPsub-TLVs as specified in Section 3.2 of [RFC7968] will be advertised for this purpose. Based on the Data Label, an ingress RBridge can determine whether a global tree or a local tree is to be used for a TRILL multi-destination Data packet.
ボーダーRBridgeは、エリア全体にわたるデータラベルに対してのみ計算されるグローバルツリーをアナウンスします。 [RFC7968]のセクション3.2で指定されているAPPsub-TLVは、この目的のためにアドバタイズされます。データラベルに基づいて、入力RBridgeは、TRILLマルチ宛先データパケットにグローバルツリーとローカルツリーのどちらを使用するかを決定できます。
If there are legacy TRILL switches that do not understand the APPsub-TLVs for tree selection, configuration MUST guarantee that Data Labels [RFC7172] being used globally in Level 2 are disabled on these legacy TRILL switches. (Otherwise, the legacy TRILL switches might use local trees for multi-destination traffic with a global scope.) These legacy TRILL switches may use global trees to flood multi-destination packets with a scope of the local area. Those global trees MUST be pruned at the border TRILL switches based on Data Labels.
ツリー選択のAPPsub-TLVを理解しないレガシーTRILLスイッチがある場合、構成は、レベル2でグローバルに使用されているデータラベル[RFC7172]がこれらのレガシーTRILLスイッチで無効になっていることを保証する必要があります。 （そうでない場合、レガシーTRILLスイッチは、グローバルスコープのマルチ宛先トラフィックにローカルツリーを使用する場合があります。）これらのレガシーTRILLスイッチは、グローバルツリーを使用して、ローカルエリアのスコープを持つマルチ宛先パケットをフラッディングする場合があります。これらのグローバルツリーは、データラベルに基づいて境界TRILLスイッチで剪定する必要があります。
The root RBridge RB1 of a local distribution tree resides in the area. RBridges in this area calculate this local tree based on the link state information of this area, using RB1's nickname as the root. Protocol behaviors for local distribution trees have been specified in Section 4.5 of [RFC6325]. The sole difference is that the local distribution tree spans this area only. A multi-destination packet with an egress nickname of the root RBridge of a local tree MUST NOT be leaked into Level 2 at the border RBridge.
ローカル配布ツリーのルートRBridge RB1は、エリアに存在します。このエリアのRBridgeは、RB1のニックネームをルートとして使用して、このエリアのリンク状態情報に基づいてこのローカルツリーを計算します。ローカル配布ツリーのプロトコル動作は、[RFC6325]のセクション4.5で指定されています。唯一の違いは、ローカル配布ツリーがこの領域のみにまたがることです。ローカルツリーのルートRBridgeの出力ニックネームを持つマルチ宛先パケットは、境界RBridgeでレベル2に漏洩してはなりません（MUST NOT）。
Within Level 2, the RBridge with the highest tree root priority advertises the set of global trees by providing a list of Level 2 RBridge nicknames as defined in Section 4.5 of [RFC6325].
レベル2内では、ツリールートプライオリティが最も高いRBridgeが、[RFC6325]のセクション4.5で定義されているレベル2 RBridgeニックネームのリストを提供することにより、グローバルツリーのセットをアドバタイズします。
According to [RFC6325], the RBridge with the highest root priority advertises the tree roots for a Level 1 area. There has to be a border RBridge with the highest root tree priority in each area so that it can advertise the global tree root nicknames into the area. Also, this border RBridge MUST advertise the set of local distribution trees by providing another set of nicknames. Since nicknames of global tree roots and local tree roots indicate different flooding scopes, these two sets MUST NOT overlap. If a border RBridge has been assigned both as a global tree root and a local tree root, it MUST acquire both global tree root nickname(s) and local tree root nickname(s). However, non-border RBridges in an area do not differentiate between a global tree root nickname and a local tree root nickname.
[RFC6325]によると、最高のルートプライオリティを持つRBridgeは、レベル1エリアのツリールートをアドバタイズします。グローバルツリーのルートニックネームをエリアにアドバタイズできるように、各エリアにはルートツリーの優先順位が最も高いボーダーRBridgeが必要です。また、このボーダーRBridgeは、別のニックネームのセットを提供することにより、ローカル配布ツリーのセットを通知する必要があります。グローバルツリールートとローカルツリールートのニックネームは異なるフラッディングスコープを示すため、これら2つのセットは重複してはなりません（MUST NOT）。ボーダーRBridgeがグローバルツリールートとローカルツリールートの両方として割り当てられている場合、グローバルツリールートニックネームとローカルツリールートニックネームの両方を取得する必要があります。ただし、エリア内の非境界RBridgeは、グローバルツリールートニックネームとローカルツリールートニックネームを区別しません。
Suppose RB3 is the RBridge with the highest tree root priority within Level 2, and RB2 is the highest tree root priority in Area X. RB2 advertises in Area X that nickname RB3 is the root of a distribution tree. Figures 2 through 5 illustrate how different RBridges view the global distribution tree.
RB3がレベル2内でツリールートの優先順位が最も高いRBridgeであり、RB2がエリアXのツリールートの優先順位が最も高いとします。RB2はエリアXで、ニックネームRB3が配布ツリーのルートであることをアドバタイズします。図2〜5は、さまざまなRBridgeがグローバル分散ツリーをどのように表示するかを示しています。
RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
o
/
Rz o
/
Rx o
/
RB27 o
Figure 2: RB27's View of the Global Distribution Tree
図2：グローバル配布ツリーのRB27のビュー
RB3,Rk,RB44
o
/
Re o
/
Rd o
/
Rc o
/
Rb o
/
RB2 o
/
Rz o
/
Rx o
/
RB27 o
Figure 3: RB2's View of the Global Distribution Tree
図3：RB2のグローバル配布ツリーのビュー
RB3
o
/ \
Re o o Rk
/ \
Rd o o RB44
/
Rc o
/
Rb o
/
R27,Rx,Rz,RB2 o
Figure 4: RB3's View of the Global Distribution Tree
図4：グローバル配布ツリーのRB3のビュー
RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re o \ o Rk \ o RB44
ＲＢ３、ＲＢ２７、ＲＢｘ、ＲＢ‥ＲＢ２、Ｒｂ、Ｒｃ、Ｒｄ、れ お ￥ お Ｒｋ ￥ お ＲＢ４４
Figure 5: RB44's View of the Global Distribution Tree
図5：グローバル配布ツリーのRB44のビュー
The following sequence of events will occur when a multi-destination TRILL Data packet is forwarded using the global distribution tree:
複数の宛先のTRILLデータパケットがグローバル配布ツリーを使用して転送されると、次の一連のイベントが発生します。
- RB27 produces a multi-destination (M bit is one) TRILL Data packet with ingress RBridge nickname 27 and egress RBridge nickname 3. RB27 floods this packet using the segment of the global distribution tree that resides in Area X.
- RB27は、マルチ宛先（Mビットは1）のTRILLデータパケットを生成します。入力RBridgeニックネーム27と出力RBridgeニックネーム3が含まれます。RB27は、エリアXにあるグローバル配布ツリーのセグメントを使用してこのパケットをフラッディングします。
- RB2, when flooding the packet in Level 2, uses the segment of the global distribution tree that resides in Level 2.
- RB2は、レベル2でパケットをフラッディングするときに、レベル2にあるグローバル配布ツリーのセグメントを使用します。
- RB3, when flooding the packet into Area Y, uses the segment of the global distribution tree that resides in Area Y.
- RB3は、パケットをエリアYにフラッディングするときに、エリアYにあるグローバル配布ツリーのセグメントを使用します。
- The multicast listener RB44, when decapsulating the received packet, learns that S is attached to nickname 27.
- マルチキャストリスナーRB44は、受信したパケットのカプセル化を解除すると、ニックネーム27にSが付加されていることを学習します。
Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border RBridges are in both a Level 1 area and in Level 2. They establish adjacency with Level 1 RBridges as specified in [RFC7177] and [RFC6325]. They establish adjacency with Level 2 RBridges in exactly the same way except that (1) for a LAN link, the IS-IS Hellos used are Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link, the Level is configured and indicated in flags in the point-to-point Hello. The state machines for Level 1 and Level 2 adjacency are independent, and two RBridges on the same LAN link can have any adjacency state for Level 1 and, separately, any adjacency state for Level 2. Level 1 and Level 2 link state flooding are independent using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP, CSNP, PSNP, FS-LSP, FS-CSNP, and FS-PSNP [RFC7356] [RFC7780]). Thus, Level 1 link state information stays within a Level 1 area and Level 2 link state information stays in Level 2 unless there are specific provisions for leaking (copying) information between levels. This is why multilevel can address the TRILL scalability issues as specified in Section 2 of [RFC8243].
マルチレベルTRILLは、[IS-IS]のマルチレベル機能に基づいています。ボーダーRBridgeは、レベル1エリアとレベル2の両方にあります。これらは、[RFC7177]および[RFC6325]で指定されているように、レベル1 RBridgeとの隣接を確立します。それらは、（1）LANリンクの場合、使用されるIS-IS Helloがレベル2 Hello PDU [IS-IS]であり、（2）ポイントツーポイントリンクの場合を除いて、まったく同じ方法でレベル2 RBridgeとの隣接関係を確立します。 、レベルは設定され、ポイントツーポイントのHelloのフラグに示されます。レベル1とレベル2の隣接関係の状態マシンは独立しており、同じLANリンク上の2つのRBridgeは、レベル1の任意の隣接関係状態と、レベル2の隣接関係状態を個別に持つことができます。レベル1とレベル2のリンク状態フラッディングは独立しています。関連するIS-IS PDUのレベル1およびレベル2バージョンを使用する（LSP、CSNP、PSNP、FS-LSP、FS-CSNP、およびFS-PSNP [RFC7356] [RFC7780]）。したがって、レベル間で情報を漏らす（コピーする）ための特別な規定がない限り、レベル1のリンク状態情報はレベル1領域内にあり、レベル2のリンク状態情報はレベル2にあります。これが、[RFC8243]のセクション2で指定されているように、マルチレベルがTRILLのスケーラビリティの問題に対処できる理由です。
The former "campus wide" minimum acceptable link size Sz is calculated as before: by Level 1 RBridges (including border RBridges) using the originatingLSPBufferSize advertised in the Level 1 LSP so it is area local in multilevel TRILL. A minimum acceptable link size in Level 2, called Sz2, is calculated by the RBridges participating in Level 2 in the same way as Sz is calculated but using the originatingLSPBufferSize distributed in Level 2 LSPs.
以前の「キャンパス全体の」最小許容リンクサイズSzは、以前のように計算されます。レベル1 LSPでアドバタイズされたoriginatingLSPBufferSizeを使用してレベル1 RBridge（境界RBridgeを含む）によって、マルチレベルTRILLでローカルなエリアになります。 Sz2と呼ばれるレベル2の最小許容リンクサイズは、Szの計算と同じ方法でレベル2に参加しているRBridgeによって計算されますが、レベル2 LSPに分散されたoriginatingLSPBufferSizeを使用します。
Level 2 RBridges contend for nicknames in the range from 0xF000 through 0xFFBF the same way as specified in [RFC6325]: using Level 2 LSPs. The highest-priority border router for a Level 1 area should contend with others in Level 2 for blocks of nicknames for the range from 0x0001 to 0xEFFF. Blocks of 64 aligned on boundaries of multiples of 64 are RECOMMENDED in this document.
レベル2 RBridgeは、[RFC6325]で指定されているのと同じ方法で、レベル2 LSPを使用して、0xF000から0xFFBFの範囲のニックネームを求めて競合します。レベル1エリアの最も優先度の高い境界ルーターは、0x0001から0xEFFFの範囲のニックネームのブロックについて、レベル2の他のルーターと競合する必要があります。このドキュメントでは、64の倍数の境界に配置された64のブロックを推奨します。
The nickname contention in Level 2 will determine which blocks of nicknames are available for an area and which blocks of nicknames are used elsewhere. The NickBlockFlags APPsub-TLV as specified in Section 4.3 will be used by the border RBridge(s) to announce the nickname availability.
レベル2のニックネームの競合により、エリアで使用可能なニックネームのブロックと、他の場所で使用されるニックネームのブロックが決まります。セクション4.3で指定されたNickBlockFlags APPsub-TLVは、ボーダーRBridgeによって使用され、ニックネームが使用可能であることを通知します。
Border RBridges need to exchange nickname information between Level 1 and Level 2; otherwise, forwarding paths inward or outward will not be calculated. For this purpose, border RBridges need to fabricate nickname announcements. Sub-TLVs used for such announcements are specified as follows.
ボーダーRBridgeは、レベル1とレベル2の間でニックネーム情報を交換する必要があります。そうでない場合、内部または外部への転送パスは計算されません。この目的のために、ボーダーRBridgesはニックネームのアナウンスを作成する必要があります。そのようなアナウンスに使用されるサブTLVは次のように指定されます。
Besides its own nickname(s), a border RBridge MUST announce, in its area, the ownership of all external nicknames that are reachable from this border RBridge. These external nicknames include nicknames used in other unique nickname areas and nicknames in Level 2. Non-border RBridge nicknames within aggregated nickname areas are excluded. Also, a border RBridge MUST announce, in Level 2, the ownership of all nicknames within its area. From listening to these Level 2 announcements, border RBridges can figure out the nicknames used by other areas.
ボーダーRBridgeは、独自のニックネームに加えて、このボーダーRBridgeから到達可能なすべての外部ニックネームの所有権をその領域で通知しなければなりません（MUST）。これらの外部ニックネームには、他の固有のニックネーム領域で使用されるニックネームとレベル2のニックネームが含まれます。集約されたニックネーム領域内の非境界RBridgeニックネームは除外されます。また、境界RBridgeは、レベル2で、そのエリア内のすべてのニックネームの所有権を通知する必要があります。これらのレベル2のアナウンスを聞いて、ボーダーRBridgesは他のエリアで使用されているニックネームを理解できます。
RBridges in the TRILL base protocol use the Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] to announce the ownership of nicknames. However, it becomes uneconomic to use this Sub-TLV to announce a mass of internal/external nicknames. To address this issue, border RBridges SHOULD make use of the NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive range of nicknames that are or are not available for self allocation by the Level 1 RBridges in that area. Its structure is as follows:
TRILL基本プロトコルのRBridgeは、[RFC7176]のセクション2.3.2で指定されているニックネームサブTLVを使用して、ニックネームの所有権を発表します。ただし、このSub-TLVを使用して大量の内部/外部ニックネームを発表することは不経済になります。この問題に対処するために、境界RBridgeは、NickBlockFlags APPsub-TLVを使用して、そのエリアのレベル1 RBridgeによる自己割り当てに使用できる、または使用できないニックネームの包括的な範囲をレベル1エリアにアドバタイズする必要があります（SHOULD）。その構造は次のとおりです。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 24 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|OK| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block K |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: 24 (TRILL NickBlockFlags)
o タイプ：24（TRILL NickBlockFlags）
o Length: 2 + 4*K, where K is the number of nickname blocks.
o 長さ：2 + 4 * K、Kはニックネームブロックの数。
o OK:
o OK：
- When this bit is set to 1, the blocks of nicknames in this APPsub-TLV are associated to the border RBridge's attached Level 1 area. The APPsub-TLV will be advertised in both Level 1 and Level 2. For nicknames that fall in the ranges of the nickname blocks, RBridges of Level 2 always route to the originating border RBridge, just as if this border RBridge owns these nicknames.
- このビットが1に設定されている場合、このAPPsub-TLV内のニックネームのブロックは、境界RBridgeに接続されているレベル1領域に関連付けられています。 APPsub-TLVは、レベル1とレベル2の両方でアドバタイズされます。ニックネームブロックの範囲内にあるニックネームの場合、レベル2のRBridgeは、このボーダーRBridgeがこれらのニックネームを所有しているかのように、常に元のボーダーRBridgeにルーティングされます。
- When this bit is set to 0, it indicates that the nicknames covered by the nickname blocks are being used in Level 2 or other areas so that they are not available for use in the border RBridge's attached Level 1 area. The APPsub-TLV will be advertised into Level 1 only. For nicknames that fall in the ranges of the nickname blocks, RBridges of the area always route to the originating border RBridge, just as if this border RBridge owns these nicknames. For nicknames in these ranges, other RBridges will deem that they are owned by the originating border RBridge. The paths to nicknames that fall in these ranges will be calculated to reach the originating border RBridge. TRILL Data packets with egress nicknames that are neither in these ranges nor announced by any RBridge in the area MUST be discarded.
- このビットが0に設定されている場合、ニックネームブロックでカバーされているニックネームがレベル2またはその他のエリアで使用されているため、ボーダーRBridgeに接続されているレベル1エリアでは使用できません。 APPsub-TLVはレベル1にのみアドバタイズされます。ニックネームブロックの範囲内にあるニックネームの場合、エリアのRBridgeは、このボーダーRBridgeがこれらのニックネームを所有しているかのように、常に元のボーダーRBridgeにルーティングされます。これらの範囲のニックネームの場合、他のRBridgeは、それらが元のボーダーRBridgeによって所有されていると見なします。これらの範囲に該当するニックネームへのパスは、元の境界RBridgeに到達するように計算されます。これらの範囲内になく、エリア内のRBridgeによってアナウンスされない出力ニックネームを持つTRILLデータパケットは、破棄する必要があります。
o RESV: reserved for future flag allocation. MUST be sent as zero and ignored on receipt.
o RESV：将来のフラグ割り当てのために予約されています。ゼロとして送信し、受信時に無視する必要があります。
o Nickname Block: a starting and ending nickname as follows:
o ニックネームブロック：次の開始ニックネームと終了ニックネーム：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| starting nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ending nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] is still allowed to be used, given the above NickBlockFlags APPsub-TLV is being used.
上記のNickBlockFlags APPsub-TLVが使用されている場合、[RFC7176]のセクション2.3.2で指定されているニックネームSub-TLVを引き続き使用できます。
There might be multiple border RBridges connected to the same area. Each border RBridge may advertise a subset of the entire internal/external nickname space in order to realize load balance. However, optimization of such load balance is an implementation issue and is outside the scope of this document.
同じエリアに複数の境界RBridgeが接続されている可能性があります。各ボーダーRBridgeは、ロードバランスを実現するために、内部/外部ニックネームスペース全体のサブセットをアドバタイズします。ただし、このようなロードバランスの最適化は実装の問題であり、このドキュメントの範囲外です。
As specified in Section 4.2.6 of [RFC6325], multiple border RBridges may claim the same nicknames outwardly and/or inwardly. Other RBridges add those nicknames as if they are attached to all of those border RBridges.
[RFC6325]のセクション4.2.6で指定されているように、複数の境界RBridgesは、同じニックネームを外側および/または内側に要求する場合があります。他のRBridgeは、それらのニックネームをそれらの境界RBridgeのすべてに接続されているかのように追加します。
All border RBridges MUST understand the NickBlockFlags APPsub-TLV. Non-border RBridges in an area should understand the NickBlockFlags APPsub-TLV. If an RBridge within an area understands the NickBlockFlags APPsub-TLV, it MUST indicate this capability by announcing it in its TRILL-VER Sub-TLV. (See Section 7.)
すべての境界RBridgeは、NickBlockFlags APPsub-TLVを理解する必要があります。エリア内の非境界RBridgeは、NickBlockFlags APPsub-TLVを理解する必要があります。エリア内のRBridgeがNickBlockFlags APPsub-TLVを理解している場合は、TRILL-VER Sub-TLVで通知することにより、この機能を示す必要があります。 （セクション7を参照。）
If there are RBridges that do not understand the NickBlockFlags APPsub-TLV, border RBridges of the area MUST also use the traditional Nickname Sub-TLV [RFC7176] to announce into the area those nicknames covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK is 0. The available range of nicknames for this area should be configured on these traditional RBridges.
NickBlockFlags APPsub-TLVを理解しないRBridgeがある場合、エリアの境界RBridgesは、従来のNickname Sub-TLV [RFC7176]を使用して、そのNickBlockFlags APPsub-TLVのニックネームブロックによってカバーされるニックネームをエリアに通知する必要があります。 OKは0です。このエリアで使用可能なニックネームの範囲は、これらの従来のRBridgeで構成する必要があります。
The design of TRILL multilevel allows a mixture of unique nickname areas and aggregated nickname areas (see Section 1.2 of [RFC8243]). Usage of nickname space MUST be planned so that nicknames used in any one unique nickname area and Level 2 are never used in any other areas, including unique nickname areas as well as aggregated nickname areas. In other words, nickname reusage is merely allowed among aggregated nickname areas.
TRILLマルチレベルの設計では、一意のニックネームエリアと集約されたニックネームエリアを混在させることができます（[RFC8243]のセクション1.2を参照）。ニックネームスペースの使用は、ユニークニックネームエリアとレベル2で使用されるニックネームが、ユニークニックネームエリアや集約されたニックネームエリアを含む他のエリアで使用されないように計画する必要があります。つまり、ニックネームの再利用は、集約されたニックネーム領域間でのみ許可されます。
Border RBridges of an aggregated area MUST announce nicknames heard from Level 2 into their area like just like a unique nickname border RBridge. However, these RBridges do not announce nicknames of their area into Level 2.
集約されたエリアのボーダーRBridgeは、レベル2から聞いたニックネームを、ユニークなニックネームボーダーRBridgeのように、そのエリアにアナウンスする必要があります。ただし、これらのRBridgesは、エリアのニックネームをレベル2にアナウンスしません。
Each border RBridge of the aggregated areas will appear on the global tree, as specified in Section 4.1, as a single node. The global trees for unique nickname areas span unique nickname areas and Level 2 but never reach the inside of aggregated areas.
集約された領域の各境界RBridgeは、セクション4.1で指定されているように、単一ノードとしてグローバルツリーに表示されます。一意のニックネーム領域のグローバルツリーは、一意のニックネーム領域とレベル2にまたがっていますが、集約された領域の内部には到達しません。
Since TRILL multilevel uses the existing IS-IS multilevel facilities [IS-IS], flooding of control traffic for link-state information is automatically confined to a Level 1 area or to Level 2 (except for limited types of information that can be specifically flagged for wider flooding). This addresses the TRILL scalability issues as specified in Section 2 of [RFC8243], and also, except for the wider flooding case, this confines the scope of the effects of malicious events that could be communicated through the link state. However, due to the fact that unique nickname areas share a common nickname space, border RBridges still have to leak nickname information between levels. Such leaking means that nickname-related events in one area can affect other areas.
TRILLマルチレベルは既存のIS-ISマルチレベルファシリティ[IS-IS]を使用するため、リンク状態情報の制御トラフィックのフラッディングは自動的にレベル1エリアまたはレベル2に制限されます（特にフラグを設定できる限られたタイプの情報を除く）より広い洪水のために）。これは、[RFC8243]のセクション2で指定されているTRILLのスケーラビリティの問題に対処します。また、より広いフラッディングの場合を除いて、これにより、リンク状態を介して通信される可能性のある悪意のあるイベントの影響の範囲が限定されます。ただし、一意のニックネーム領域が共通のニックネームスペースを共有しているため、境界RBridgeは、レベル間でニックネーム情報をリークする必要があります。このような漏洩は、ある領域でのニックネーム関連のイベントが他の領域に影響を与える可能性があることを意味します。
For this purpose, border RBridges need to fabricate the nickname announcements as specified in Section 4.3. Malicious devices may also fake the NickBlockFlags APPsub-TLV to announce a range of nicknames. By doing this, the attacker can attract TRILL data packets that were originally sent to a bunch of other RBridges. For this reason, RBridges SHOULD be configured to use the IS-IS Authentication TLV (10) in the IS-IS PDUs, particularly those containing the NickBlockFlags APPsub-TLV, so that IS-IS security [RFC5310] can be used to authenticate those PDUs and discard them if they are forged.
この目的のために、ボーダーRBridgesは、セクション4.3で指定されているニックネームアナウンスを作成する必要があります。悪意のあるデバイスがNickBlockFlags APPsub-TLVを偽装して、さまざまなニックネームを発表する可能性もあります。これを行うことにより、攻撃者は元々他のRBridgeの束に送信されたTRILLデータパケットを引き付けることができます。このため、IS-IS PDU、特にNickBlockFlags APPsub-TLVを含むものでIS-IS認証TLV（10）を使用するようにRBridgesを構成する必要があります。これにより、IS-ISセキュリティ[RFC5310]を使用してそれらを認証できます。 PDUであり、偽造されている場合は破棄します。
If border RBridges do not prune multi-destination distribution tree traffic in Data Labels that are configured to be area local, then traffic that should have been contained within an area might be wrongly delivered to end stations in that Data Label in other areas. That is, the Data Label would no longer be area local. This would generally violate security constraints that require traffic to be delivered only to end stations in that Data Label in a single area.
ボーダーRBridgeがエリアローカルに設定されているデータラベルのマルチ宛先配布ツリートラフィックをプルーニングしない場合、エリア内に含まれるはずだったトラフィックが、他のエリアのそのデータラベルのエンドステーションに誤って配信される可能性があります。つまり、データラベルはエリアローカルではなくなります。これは、一般に、1つのエリアのそのデータラベルのエンドステーションにのみトラフィックを配信する必要があるというセキュリティ制約に違反します。
For general TRILL Security Considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
IANA has registered a new flag bit under the "TRILL-VER Sub-TLV Capability Flags" registry.
IANAは、「TRILL-VER Sub-TLV Capability Flags」レジストリの下に新しいフラグビットを登録しました。
Bit Description Reference
--- ----------- ---------
5 Able to handle the RFC 8397
NickBlockFlags
APPsub-TLV
IANA has assigned a new type for the NickBlockFlags APPsub-TLV from the range available below 256 and add the following entry to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows:
IANAは、NickBlockFlags APPsub-TLVに256未満で使用可能な範囲から新しいタイプを割り当て、次のエントリを「IS-IS TLV 251アプリケーション識別子1のTRILL APPsub-TLVタイプ」レジストリに次のように追加します。
Type Name Reference
---- ------ ---------
24 NickBlockFlags RFC 8397
[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>。
[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、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<https://www.rfc-editor.org/info/rfc6325>。
[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, <https://www.rfc-editor.org/info/rfc7172>.
[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、2014年5月、<https://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, <https://www.rfc-editor.org/info/rfc7176>.
[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、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.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<https://www.rfc-editor.org/info/rfc7177>。
[RFC7968] Li, Y., Eastlake 3rd, D., Hao, W., Chen, H., and S. Chatterjee, "Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data", RFC 7968, DOI 10.17487/RFC7968, August 2016, <https://www.rfc-editor.org/info/rfc7968>.
[RFC7968] Li、Y.、Eastlake 3rd、D.、Hao、W.、Chen、H。、およびS. Chatterjee、「多数のリンクの透過的な相互接続（TRILL）：複数の宛先のツリー選択にデータラベルを使用する」データ」、RFC 7968、DOI 10.17487 / RFC7968、2016年8月、<https://www.rfc-editor.org/info/rfc7968>。
[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、Second Edition、2002年11月。
[SingleN] Zhang, M., Eastlake, D., et al, "Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel", draft-ietf-trill-multilevel-single-nickname-05, Work in Progress, January 2018.
[SingleN] Zhang、M.、Eastlake、D。、他、「多数のリンクの透過的な相互接続（TRILL）単一エリア境界RBridgeニックネーム（マルチレベル）」、draft-ietf-trill-multilevel-single-nickname-05、Work進行中、2018年1月。
[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 Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[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 Flooding Scope Link State PDU（LSPs）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<https：// www。 rfc-editor.org/info/rfc7356>。
[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.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<https://www.rfc-editor.org/info/rfc7780>。
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and H. Zhai, "Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 10.17487/RFC8243, September 2017, <https://www.rfc-editor.org/info/rfc8243>.
[RFC8243] Perlman、R.、Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、and H. Zhai、 "Alternatives for Multilevel Transparent Interconnection of Lots of Links（TRILL）"、RFC 8243、DOI 10.17487 / RFC8243、2017年9月、<https://www.rfc-editor.org/info/rfc8243>。
Contributors
貢献者
Margaret Cullen Painless Security 14 Summer St. Suite 202 Malden, MA 02148 United States of America
マーガレットカレン痛みのないセキュリティ14サマーセントスイート202モールデン、MA 02148アメリカ合衆国
Email: margaret@painless-security.com
Authors' Addresses
著者のアドレス
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
min鬼Zhang hu Aはテクノロジーno。156 be iqing RD。、Hショートポイント地区北京100095中国
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
Radia Perlman Dell EMC 176 South Street Hopkinton、MA 01748アメリカ合衆国
Email: radia@alum.mit.edu Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China
email：Let Adai @阿鲁哥。蜜桃。金額hongjun Zもjinに技術研究所99 hongjing avenue、Jiangning District NaNjing、Jiangsu 211169 Chinaを注文した
Email: honjun.zhai@tom.com
Dongxin Liu China Telecom Co., Ltd 109 West Zhongshan Ave, Tianhe District Guangzhou 510630 China
dongxinl IU China telecom co。、Ltd 109西Z爆撃身廊、TIは広州510630中国地区と一致
Email: liudx@gsta.com