[要約] RFC 7782は、TRILL（Transparent Interconnection of Lots of Links）アクティブ-アクティブエッジを実現するための複数のMACアタッチメントの使用に関するものです。このRFCの目的は、TRILLネットワークでの冗長性と負荷分散を向上させるために、複数のMACアタッチメントを使用する方法を提案することです。
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7782 Huawei
Category: Standards Track R. Perlman
ISSN: 2070-1721 EMC
H. Zhai
Astute Technology
M. Durrani
Cisco Systems
S. Gupta
IP Infusion
February 2016
Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
複数のMACアタッチメントを使用した多数のリンクの透過的な相互接続（TRILL）アクティブ-アクティブエッジ
Abstract
概要
TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.
RFC 7379に記載されているように、TRILL（多数のリンクの透過的相互接続）アクティブ-アクティブサービスは、エンドステーションにフローレベルのロードバランスとTRILLキャンパスのエッジでのリンク障害に対する回復力を提供します。
This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.
このドキュメントでは、アクティブ-アクティブエッジRBridgeグループのメンバーRBridge（ルーティングブリッジまたはTRILLスイッチとも呼ばれます）が独自のニックネームを入力RBridgeニックネームとして使用して、接続されたエンドシステムからのフレームをカプセル化する方法を指定します。したがって、リモートエッジRBridge（グループに含まれていない）には、グループ内の複数のRBridgeに関連付けられている1つのホストメディアアクセス制御（MAC）アドレスが表示されます。このようなリモートエッジRBridgeは、これらすべてのアソシエーション（つまり、MACアタッチメント）を維持し、それらの間でフリップフロップしない（この仕様の実装前に発生する）必要があります。この仕様の設計目標については、ここで説明します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7782.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7782で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Acronyms and Terminology ........................................4
3. Overview ........................................................5
4. Incremental Deployable Options ..................................6
4.1. Details of Option B ........................................7
4.1.1. Advertising Data Labels for Active-Active Edge ......7
4.1.2. Discovery of Active-Active Edge Members .............8
4.1.3. Advertising Learned MAC Addresses ...................9
4.2. Extended RBridge Capability Flags APPsub-TLV ..............11
5. Meeting the Design Goals .......................................12
5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) ......12
5.2. Regular Unicast/Multicast Ingress .........................12
5.3. Correct Multicast Egress ..................................12
5.3.1. No Duplication (Single Exit Point) .................12
5.3.2. No Echo (Split Horizon) ............................13
5.4. No Black-Hole or Triangular Forwarding ....................14
5.5. Load Balance towards the AAE ..............................14
5.6. Scalability ...............................................14
6. E-L1FS Backward Compatibility ..................................15
7. Security Considerations ........................................15
8. IANA Considerations ............................................16
8.1. TRILL APPsub-TLVs .........................................16
8.2. Extended RBridge Capabilities Registry ....................16
8.3. Active-Active Flags .......................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................19
Appendix A. Scenarios for Split Horizon ...........................20
Acknowledgments ...................................................21
Authors' Addresses ................................................22
As discussed in [RFC7379], in a TRILL (Transparent Interconnection of Lots of Links) Active-Active Edge (AAE) topology, a Local Active-Active Link Protocol (LAALP) -- for example, a Multi-Chassis Link Aggregation (MC-LAG) bundle -- is used to connect multiple RBridges (Routing Bridges or TRILL switches) to multi-port Customer Equipment (CE), such as a switch, virtual switch (vSwitch), or multi-port end station. A set of end nodes is attached in the case of a switch or vSwitch. It is required that data traffic within a specific VLAN from this end node set (including the multi-port end-station case) can be ingressed and egressed by any of these RBridges simultaneously. End systems in the set can spread their traffic among these edge RBridges at the flow level. When a link fails, end systems keep using the remaining links in the LAALP without waiting for the convergence of TRILL, which provides resilience to link failures.
[RFC7379]で説明されているように、TRILL（リンクの透過的相互接続）アクティブ-アクティブエッジ（AAE）トポロジでは、ローカルアクティブ-アクティブリンクプロトコル（LAALP）-たとえば、マルチシャーシリンク集約（MC -LAG）バンドル-複数のRBridge（ルーティングブリッジまたはTRILLスイッチ）を、スイッチ、仮想スイッチ（vSwitch）、マルチポートエンドステーションなどのマルチポートカスタマー機器（CE）に接続するために使用されます。スイッチまたはvSwitchの場合、一連のエンドノードが接続されます。このエンドノードセットからの特定のVLAN内のデータトラフィック（マルチポートエンドステーションのケースを含む）は、これらのRBridgeのいずれかによって同時に入力および出力できる必要があります。セット内のエンドシステムは、フローレベルでこれらのエッジRBridge間でトラフィックを分散できます。リンクに障害が発生すると、エンドシステムは、TRILLの収束を待たずにLAALPの残りのリンクを使用し続けるため、リンク障害に対する回復力が提供されます。
Since a frame from each end node can be ingressed by any RBridge in the local AAE group, a remote edge RBridge may observe multiple attachment points (i.e., egress RBridges) for this end node. This issue is known as "MAC address flip-flopping"; see [RFC7379] for a discussion.
各エンドノードからのフレームは、ローカルAAEグループ内の任意のRBridgeから侵入できるため、リモートエッジRBridgeは、このエンドノードの複数の接続ポイント（つまり、出力RBridge）を監視する場合があります。この問題は「MACアドレスフリップフロップ」として知られています。議論については[RFC7379]を見てください。
Per this document, AAE member RBridges use their own nicknames to ingress frames into the TRILL campus. Remote edge RBridges are required to keep multiple points of attachment per MAC address and Data Label (VLAN or Fine-Grained Label [RFC7172]) attached to the AAE. This addresses the MAC flip-flopping issue. Using this solution, as specified in this document, in an AAE group does not prohibit the use of other solutions in other AAE groups in the same TRILL campus. For example, the specification in this document and the specification in [RFC7781] could be simultaneously deployed for different AAE groups in the same campus.
このドキュメントによれば、AAEメンバーのRBridgesは独自のニックネームを使用して、フレームをTRILLキャンパスに入力します。 MACアドレスごとの複数の接続ポイントと、AAEに接続されたデータラベル（VLANまたは細粒度ラベル[RFC7172]）を維持するには、リモートエッジRBridgeが必要です。これは、MACフリップフロップの問題に対処します。このドキュメントで指定されているように、このソリューションをAAEグループで使用しても、同じTRILLキャンパス内の他のAAEグループでの他のソリューションの使用が禁止されるわけではありません。たとえば、このドキュメントの仕様と[RFC7781]の仕様は、同じキャンパス内の異なるAAEグループに同時に展開できます。
The main body of this document is organized as follows: Section 2 lists acronyms and terms. Section 3 describes the overview model. Section 4 provides options for incremental deployment. Section 5 describes how this approach meets the design goals. Section 6 discusses backward compatibility. Section 7 covers security considerations. Section 8 covers IANA considerations.
このドキュメントの本文は次のように構成されています。セクション2には、頭字語と用語がリストされています。セクション3では、概要モデルについて説明します。セクション4では、増分展開のオプションについて説明します。セクション5では、このアプローチが設計目標をどのように満たすかについて説明します。セクション6では、下位互換性について説明します。セクション7では、セキュリティに関する考慮事項について説明します。セクション8では、IANAの考慮事項について説明します。
AAE: Active-Active Edge
AAE：アクティブ-アクティブエッジ
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スイッチ、リンク、および場合によっては端末とIPルーターで囲まれたブリッジで構成されるTRILLネットワーク。 TRILLの場合、「キャンパス」という名前には「学問的」な意味合いはありません。
CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment.
CE：カスタマー機器（エンドステーションまたはブリッジ）。デバイスは、物理装置または仮想装置のいずれかです。
Data Label: VLAN or Fine-Grained Label (FGL)
データラベル：VLANまたはファイングレインラベル（FGL）
DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges.
DRNI：Distributed Resilient Network Interconnect。 [a）1つ、2つ、または3つのCEと（b）2つまたは3つのRBridge間でLAALPを提供できる、[802.1AX]で指定されたリンク集約。
E-L1FS: Extended Level 1 Flooding Scope
E-L1FS：拡張レベル1フラッディングスコープ
Edge RBridge: An RBridge providing end-station service on one or more of its ports.
エッジRBridge：1つまたは複数のポートで端末サービスを提供するRBridge。
ESADI: End Station Address Distribution Information [RFC7357]
ESADI：端末のアドレス配布情報[RFC7357]
FGL: Fine-Grained Label [RFC7172]
FGL：きめの細かいラベル[RFC7172]
FS-LSP: Flooding Scope Link State Protocol Data Unit
FS-LSP：フラッディングスコープのリンク状態プロトコルデータユニット
IS: Intermediate System [IS-IS]
IS：中間システム[IS-IS]
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中間システムから中間システム[IS-IS]
LAALP: Local Active-Active Link Protocol [RFC7379]. Any protocol similar to MC-LAG (or DRNI) that runs in a distributed fashion on a CE, on the links from that CE to a set of edge group RBridges, and on those RBridges.
LAALP：ローカルアクティブ-アクティブリンクプロトコル[RFC7379]。 MC-LAG（またはDRNI）と同様のプロトコルで、CE、そのCEからエッジグループRBridgeのセットへのリンク、およびそれらのRBridgeで分散方式で実行されます。
LSP: Link State PDU
LSP：リンク状態PDU
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of link aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
MC-LAG：マルチシャーシリンク集約。 1つのCEと2つ以上のRBridge間でLAALPを提供できるリンク集約[802.1AX]の独自の拡張。
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
RBridge: A device implementing the TRILL protocol.
RBridge：TRILLプロトコルを実装するデバイス。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7177].
TRILL：多くのリンクの透過的な相互接続またはリンク層のトンネルルーティング[RFC6325] [RFC7177]。
TRILL switch: An alternative name for an RBridge.
TRILLスイッチ：RBridgeの別名。
vSwitch: A virtual switch, such as a hypervisor, that also simulates a bridge.
vSwitch：ブリッジをシミュレートするハイパーバイザーなどの仮想スイッチ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Familiarity with [RFC6325], [RFC6439], and [RFC7177] is assumed in this document.
このドキュメントでは、[RFC6325]、[RFC6439]、および[RFC7177]に精通していることを前提としています。
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||LAALP1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10
Figure 1: An Example Topology for TRILL Active-Active Edge
図1：TRILLアクティブ-アクティブエッジのトポロジ例
Figure 1 shows an example network for TRILL AAE (see also Figure 1 in [RFC7379]). In this figure, end nodes (H1, H2, H3, and H4) are attached to a bridge (B) that communicates with multiple RBridges (RB1, RB2, and RB3) via the LAALP. Suppose that RB4 is a "remote" RBridge not in the AAE group in the TRILL campus. This connection model is also applicable to the virtualized environment where the physical bridge can be replaced with a vSwitch while those bare metal hosts are replaced with virtual machines (VMs).
図1はTRILL AAEのネットワークの例を示しています（[RFC7379]の図1も参照）。この図では、エンドノード（H1、H2、H3、およびH4）が、LAALPを介して複数のRBridge（RB1、RB2、およびRB3）と通信するブリッジ（B）に接続されています。 RB4がTRILLキャンパスのAAEグループに含まれない「リモート」RBridgeであると想定します。この接続モデルは、物理ブリッジをvSwitchで置き換えることができ、それらのベアメタルホストが仮想マシン（VM）で置き換えられる仮想化環境にも適用できます。
For a frame received from its attached end node sets, a member RBridge of the AAE group conforming to this document always encapsulates that frame using its own nickname as the ingress nickname, regardless of whether it is unicast or multicast.
接続されたエンドノードセットから受信したフレームの場合、このドキュメントに準拠するAAEグループのメンバーRBridgeは、ユニキャストかマルチキャストかに関係なく、常に独自のニックネームを入力ニックネームとして使用してそのフレームをカプセル化します。
With the two options specified below, even though remote RBridge RB4 will see multiple attachments for each MAC address from one of the end nodes, MAC address flip-flopping will not cause any problems.
以下に指定する2つのオプションを使用すると、リモートRBridge RB4は、エンドノードの1つからの各MACアドレスに対して複数のアタッチメントを認識しますが、MACアドレスのフリップフロップは問題を引き起こしません。
This section specifies two options. Option A requires new hardware support. Option B can be incrementally implemented throughout a TRILL campus with common existing TRILL "fast path" hardware. Further details on Option B are given in Section 4.1.
このセクションでは、2つのオプションを指定します。オプションAには新しいハードウェアサポートが必要です。オプションBは、既存の一般的なTRILL「高速パス」ハードウェアを使用して、TRILLキャンパス全体に段階的に実装できます。オプションBの詳細については、セクション4.1を参照してください。
Option A: A new capability announcement would appear in LSPs: "I can cope with data-plane learning of multiple attachments for an end node." This mode of operation is generally not supported by existing TRILL fast path hardware. Only if all edge RBridges to which the group has data connectivity -- and that are interested in any of the Data Labels in which the AAE is interested -- announce this capability can the AAE group safely use this approach. If all such RBridges do not announce this "Option A" capability, then a fallback would be needed, such as reverting from active-active to active-standby operation or isolating the RBridges that would need to support this capability but do not support it. Further details for Option A are beyond the scope of this document, except that, as described in Section 4.2, a bit is reserved to indicate support for Option A, because a remote RBridge supporting Option A is compatible with an AAE group using Option B.
オプションA：LSPに新機能のお知らせが表示されます。「エンドノードの複数のアタッチメントのデータプレーン学習に対応できます。」この操作モードは、通常、既存のTRILL高速パスハードウェアではサポートされていません。グループがデータ接続を持っているすべてのエッジRBridgeが、AAEが関心のあるデータラベルのいずれかに関心がある場合にのみ、この機能を通知する場合にのみ、AAEグループはこのアプローチを安全に使用できます。このようなすべてのRBridgesがこの「オプションA」機能を通知しない場合、アクティブ-アクティブ操作からアクティブ-スタンバイ操作に戻す、またはこの機能をサポートする必要があるがサポートしないRBridgesを分離するなどのフォールバックが必要になります。セクションAでサポートされているリモートRBridgeはオプションBを使用するAAEグループと互換性があるため、セクションAのサポートを示すためにビットが予約されていることを除いて、オプションAの詳細はこのドキュメントの範囲外です。
Option B: As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357], one MAC address may be persistently claimed to be attached to multiple RBridges within the same Data Label in the TRILL ESADI-LSPs. For Option B, AAE member RBridges make use of the TRILL ESADI protocol to distribute multiple attachments of a MAC address. Remote RBridges SHOULD disable data-plane MAC learning for such multi-attached MAC addresses from TRILL Data packet decapsulation, unless they also support Option A. The ability to configure an RBridge to disable data-plane learning is provided by the base TRILL protocol [RFC6325].
オプションB：[RFC6325]のセクション4.2.6および[RFC7357]のセクション5.3で指摘されているように、1つのMACアドレスがTRILL ESADI-LSPの同じデータラベル内の複数のRBridgeに接続されていると主張されている場合があります。オプションBの場合、AAEメンバーのRBridgesはTRILL ESADIプロトコルを使用して、MACアドレスの複数の添付ファイルを配布します。リモートRBridgeは、オプションAもサポートしない限り、そのようなマルチアタッチMACアドレスのデータプレーンMAC学習をTRILLデータパケットのカプセル化解除から無効にする必要があります。データプレーン学習を無効にするようにRBridgeを構成する機能は、基本TRILLプロトコル[RFC6325 ]。
With Option B, the receiving edge RBridges MUST avoid flip-flop errors for MAC addresses learned from the TRILL Data packet decapsulation for the originating RBridge within these Data Labels. It is RECOMMENDED that the receiving edge RBridge disable data-plane MAC learning from TRILL Data packet decapsulation within those advertised Data Labels for the originating RBridge, unless the receiving RBridge also supports Option A. Alternative implementations that produce the same expected behavior, i.e., the receiving edge RBridge does not flip-flop among multiple MAC attachments, are acceptable. For example, the confidence-level mechanism as specified in [RFC6325] can be used. Let the receiving edge RBridge give a prevailing confidence value (e.g., 0x21) to the first MAC attachment learned from the data plane over others from the TRILL Data packet decapsulation. The receiving edge RBridge will stick to this MAC attachment until it is overridden by one learned from the ESADI protocol [RFC7357]. The MAC attachment learned from ESADI is set to have a higher confidence value (e.g., 0x80) to override any alternative learning from the decapsulation of received TRILL Data packets [RFC6325].
オプションBでは、受信エッジRBridgeは、これらのデータラベル内の元のRBridgeのTRILLデータパケットのカプセル化解除から学習したMACアドレスのフリップフロップエラーを回避する必要があります。受信側RBridgeがオプションAもサポートしている場合を除き、受信側RBridgeが、発信RBridgeのアドバタイズされたデータラベル内のTRILLデータパケットのカプセル化解除からのデータプレーンMAC学習を無効にすることをお勧めします。受信エッジRBridgeは、複数のMACアタッチメント間でフリップフロップしません。これは許容されます。たとえば、[RFC6325]で指定されている信頼レベルのメカニズムを使用できます。受信エッジRBridgeが、TRILLデータパケットのカプセル化解除から他のデータプレーンを介してデータプレーンから学習した最初のMACアタッチメントに、一般的な信頼値（0x21など）を与えるようにします。受信エッジRBridgeは、ESADIプロトコル[RFC7357]から学習したものによって上書きされるまで、このMACアタッチメントに固執します。 ESADIから学習したMACアタッチメントは、より高い信頼値（0x80など）に設定され、受信したTRILLデータパケットのカプセル化解除からの代替学習を上書きします[RFC6325]。
An RBridge in an AAE group MUST participate in ESADI in Data Labels enabled for its attached LAALPs. This document further registers two data flags, which are used to advertise that the originating RBridge supports and participates in an AAE. These two flags are allocated from the Interested VLANs Flag Bits that appear in the Interested VLANs and Spanning Tree Roots sub-TLV and the Interested Labels Flag Bits that appear in the Interested Labels and Spanning Tree Roots sub-TLV [RFC7176] (see Section 8.3). When these flags are set to 1, the originating RBridge is advertising Data Labels for LAALPs rather than plain LAN links.
AAEグループのRBridgeは、接続されているLAALPに対して有効になっているデータラベルのESADIに参加する必要があります。このドキュメントはさらに、2つのデータフラグを登録します。これらのフラグは、発信元のRBridgeがAAEをサポートし、それに参加していることを宣伝するために使用されます。これらの2つのフラグは、対象VLANおよびスパニングツリールートサブTLVに表示される対象VLANフラグビットと、対象ラベルおよびスパニングツリールートサブTLV [RFC7176]に表示される対象ラベルフラグビットから割り当てられます（セクション8.3を参照） ）。これらのフラグが1に設定されている場合、元のRBridgeは、プレーンLANリンクではなくLAALPのデータラベルをアドバタイズしています。
Remote edge RBridges need to discover RBridges in an AAE. This is achieved by listening to the following "AA LAALP Group RBridges" TRILL APPsub-TLV included in the TRILL GENINFO TLV in FS-LSPs [RFC7780]:
リモートエッジRBridgeは、AAE内のRBridgeを検出する必要があります。これは、FS-LSP [RFC7780]のTRILL GENINFO TLVに含まれる次の「AA LAALPグループRBridges」のTRILL APPsub-TLVを聞くことによって実現されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: AA LAALP Group RBridges (TRILL APPsub-TLV type 252)
o タイプ：AA LAALPグループRBridges（TRILL APPsub-TLVタイプ252）
o Length: 3 + k
o 長さ：3 + k
o Sender Nickname: The nickname the originating RBridge will use as the ingress nickname. This field is useful because the originating RBridge might own multiple nicknames.
o Sender Nickname：発信元のRBridgeが入力ニックネームとして使用するニックネーム。元のRBridgeが複数のニックネームを所有している可能性があるため、このフィールドは役立ちます。
o LAALP ID Size: The length, k, of the LAALP ID in bytes.
o LAALP IDサイズ：バイト単位のLAALP IDの長さk。
o LAALP ID: The ID of the LAALP, which is k bytes long. If the LAALP is an MC-LAG or DRNI, it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
o LAALP ID：LAALPのIDで、長さはkバイトです。 LAALPがMC-LAGまたはDRNIの場合、[802.1AX]の6.3.2項で指定されている8バイトのIDです。
This APPsub-TLV is expected to rarely change, as it only does so in cases of the creation or elimination of an AAE group, or of link failure or restoration to the CE in such a group.
このAPPsub-TLVは、AAEグループの作成または削除の場合、またはそのようなグループのリンク障害またはCEへの復元の場合にのみ変更されるため、めったに変更されないと予想されます。
Whenever MAC addresses from the LAALP of this AAE are learned through ingress or configuration, the originating RBridge MUST advertise these MAC addresses using the MAC-Reachability TLV [RFC6165] via the ESADI protocol [RFC7357]. The MAC-Reachability TLVs are composed in a way that each TLV only contains MAC addresses of end nodes attached to a single LAALP. Each such TLV is enclosed in a TRILL APPsub-TLV, defined as follows:
このAAEのLAALPからのMACアドレスが入力または構成を通じて学習されるときは常に、発信元のRBridgeは、ESADIプロトコル[RFC7357]を介してMAC到達可能性TLV [RFC6165]を使用してこれらのMACアドレスを通知しなければなりません（MUST）。 MAC到達可能性TLVは、各TLVに単一のLAALPに接続されたエンドノードのMACアドレスのみが含まれるように構成されています。このような各TLVは、次のように定義されたTRILL APPsub-TLVに含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-MAC | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MAC-Reachability TLV (7 + 6*n bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: AA LAALP Group MAC (TRILL APPsub-TLV type 253)
o タイプ：AA LAALPグループMAC（TRILL APPsub-TLVタイプ253）
o Length: The MAC-Reachability TLV [RFC6165] is contained in the value field as a sub-TLV. The total number of bytes contained in the value field is given by k + 8 + 6*n.
o 長さ：MAC到達可能性TLV [RFC6165]は、サブTLVとして値フィールドに含まれています。値フィールドに含まれるバイトの総数は、k + 8 + 6 * nで与えられます。
o LAALP ID Size: The length, k, of the LAALP ID in bytes.
o LAALP IDサイズ：バイト単位のLAALP IDの長さk。
o LAALP ID: The ID of the LAALP, which is k bytes long. Here, it also serves as the identifier of the AAE. If the LAALP is an MC-LAG (or DRNI), it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
o LAALP ID：LAALPのIDで、長さはkバイトです。ここでは、AAEの識別子としても機能します。 LAALPがMC-LAG（またはDRNI）の場合は、[802.1AX]の6.3.2項で指定されている8バイトのIDです。
o MAC-Reachability sub-TLV: The AA-LAALP-GROUP-MAC APPsub-TLV value contains the MAC-Reachability TLV as a sub-TLV (see [RFC6165]; n is the number of MAC addresses present). As specified in Section 2.2 of [RFC7356], the Type and Length fields of the MAC-Reachability TLV are encoded as unsigned 16-bit integers. The 1-byte unsigned confidence value, along with these TLVs, SHOULD be set to prevail over those MAC addresses learned from TRILL Data decapsulation by remote edge RBridges.
o MAC到達可能性サブTLV：AA-LAALP-GROUP-MAC APPサブTLV値には、MAC到達可能性TLVがサブTLVとして含まれます（[RFC6165]を参照。nは、存在するMACアドレスの数です）。 [RFC7356]のセクション2.2で指定されているように、MAC-Reachability TLVのTypeおよびLengthフィールドは、符号なし16ビット整数としてエンコードされます。 1バイトの符号なし信頼値は、これらのTLVとともに、リモートエッジRBridgeによってTRILLデータのカプセル化解除から学習したMACアドレスより優先されるように設定する必要があります（SHOULD）。
This AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL GENINFO TLV [RFC7357] in the ESADI-LSP. There may be more than one occurrence of such TRILL APPsub-TLVs in one ESADI-LSP fragment.
このAA-LAALP-GROUP-MAC APPsub-TLVは、ESADI-LSPのTRILL GENINFO TLV [RFC7357]に含まれている必要があります。 1つのESADI-LSPフラグメントに、このようなTRILL APPsub-TLVが複数存在する場合があります。
For those MAC addresses contained in an AA-LAALP-GROUP-MAC APPsub-TLV, this document applies. Otherwise, [RFC7357] applies. For example, an AAE member RBridge continues to enclose MAC addresses learned from TRILL Data packet decapsulation in MAC-Reachability TLVs as per [RFC6165] and advertise them using the ESADI protocol.
AA-LAALP-GROUP-MAC APPsub-TLVに含まれるMACアドレスについては、このドキュメントが適用されます。それ以外の場合は、[RFC7357]が適用されます。たとえば、AAEメンバーのRBridgeは、[RFC6165]のようにMAC-Reachability TLVでTRILLデータパケットのカプセル化解除から学習したMACアドレスを引き続き囲み、ESADIプロトコルを使用してアドバタイズします。
When the remote RBridge learns MAC addresses contained in the AA-LAALP-GROUP-MAC APPsub-TLV via the ESADI protocol [RFC7357], it sends the packets destined to these MAC addresses to the closest one (the one to which the remote RBridge has the least-cost forwarding path) of those RBridges in the AAE identified by the LAALP ID in the AA-LAALP-GROUP-MAC APPsub-TLV. If there are multiple equal least-cost member RBridges, the ingress RBridge is required to select one of them in a pseudorandom way, as specified in Section 5.3 of [RFC7357].
リモートRBridgeがESADIプロトコル[RFC7357]を介してAA-LAALP-GROUP-MAC APPsub-TLVに含まれるMACアドレスを学習すると、これらのMACアドレス宛てのパケットを最も近いアドレス（リモートRBridgeが持っているMACアドレス）に送信します。 AA-LAALP-GROUP-MAC APPsub-TLVのLAALP IDで識別されるAAEのRBridgeの最小コストの転送パス）。 [RFC7357]のセクション5.3で指定されているように、複数の等しい最小コストのメンバーRBridgesがある場合、それらの1つを擬似ランダムに選択するために、入力RBridgeが必要です。
When another RBridge in the same AAE group receives an ESADI-LSP with the AA-LAALP-GROUP-MAC APPsub-TLV, it also learns MAC addresses of those end nodes served by the corresponding LAALP. These MAC addresses SHOULD be learned as if those end nodes are locally attached to this RBridge itself.
同じAAEグループ内の別のRBridgeがAA-LAALP-GROUP-MAC APPsub-TLVでESADI-LSPを受信すると、対応するLAALPがサービスを提供するエンドノードのMACアドレスも学習します。これらのMACアドレスは、これらのエンドノードがこのRBridge自体にローカルに接続されているかのように学習する必要があります。
An AAE member RBridge MUST use the AA-LAALP-GROUP-MAC APPsub-TLV to advertise in ESADI the MAC addresses learned from a plain local link (a non-LAALP link) with Data Labels that happen to be covered by the Data Labels of any attached LAALP. The reason is that MAC learning from TRILL Data packet decapsulation within these Data Labels at the remote edge RBridge has normally been disabled for this RBridge.
AAEメンバーRBridgeは、AA-LAALP-GROUP-MAC APPsub-TLVを使用して、ESADIで、たまたまデータラベルでカバーされているデータラベルを持つプレーンローカルリンク（非LAALPリンク）から学習したMACアドレスをアドバタイズする必要があります接続されているLAALP。その理由は、リモートエッジRBridgeでこれらのデータラベル内のTRILLデータパケットのカプセル化解除からMAC学習が通常、このRBridgeでは無効になっているためです。
This APPsub-TLV changes whenever the MAC reachability situation for the LAALP changes.
このAPPsub-TLVは、LAALPのMAC到達可能性の状況が変化するたびに変化します。
The following Extended RBridge Capability Flags APPsub-TLV will be included in E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO TLV:
次の拡張RBridge機能フラグAPPsub-TLVは、TRILL GENINFO TLVのAPPsub-TLVとしてE-L1FS FS-LSPフラグメントゼロ[RFC7780]に含まれます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDED-RBRIDGE-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended RBridge Capability (TRILL APPsub-TLV type 254)
o タイプ：拡張RBridge機能（TRILL APPsub-TLVタイプ254）
o Length: Set to 10.
o 長さ：10に設定します。
o Topology: Indicates the topology to which the capabilities apply. When this field is set to zero, either topologies are not in use or the capabilities apply to all topologies [TRILL-MT].
o トポロジ：機能が適用されるトポロジを示します。このフィールドがゼロに設定されている場合、トポロジは使用されていないか、機能がすべてのトポロジに適用されます[TRILL-MT]。
o E: Bit 0 of the capability bits. When this bit is set, it indicates that the originating RBridge acts as specified in Option B above.
o E：機能ビットのビット0。このビットが設定されている場合、元のRBridgeが上記のオプションBで指定されたとおりに機能することを示します。
o H: Bit 1 of the capability bits. When this bit is set, it indicates that the originating RBridge keeps multiple MAC attachments learned from TRILL Data packet decapsulation with fast path hardware; that is, it acts as specified in Option A above.
o H：機能ビットのビット1。このビットが設定されている場合、元のRBridgeが、高速パスハードウェアでTRILLデータパケットのカプセル化解除から学習した複数のMACアタッチメントを保持していることを示します。つまり、上記のオプションAで指定されたとおりに機能します。
o Reserved: Flags extending from bit 2 through bit 63 of the capability bits. Reserved for future use. These MUST be sent as zero and ignored on receipt.
o 予約済み：機能ビットのビット2からビット63までのフラグ。将来の使用のために予約されています。これらはゼロとして送信され、受信時に無視される必要があります。
The Extended RBridge Capability Flags TRILL APPsub-TLV is used to notify other RBridges as to whether the originating RBridge supports the capability indicated by the E and H bits. For example, if the E bit is set, it indicates that the originating RBridge will act as defined in Option B. That is, it will disable the MAC learning from TRILL Data packet decapsulation within Data Labels advertised by AAE RBridges while waiting for the TRILL ESADI-LSPs to distribute the {MAC, Nickname, Data Label} association. Meanwhile, this RBridge is able to act as an AAE RBridge. It is required that MAC addresses learned from local LAALPs be advertised in TRILL ESADI-LSPs, using the AA-LAALP-GROUP-MAC APPsub-TLV, which is defined in Section 4.1.3. If an RBridge in an AAE group, as specified herein, observes a remote RBridge interested in one or more of that AAE group's Data Labels and the remote RBridge does not support, as indicated by its extended capabilities, either Option A or Option B, then the AAE group MUST fall back to active-standby mode.
拡張RBridge機能フラグTRILL APPsub-TLVは、元のRBridgeがEおよびHビットで示される機能をサポートしているかどうかを他のRBridgeに通知するために使用されます。たとえば、Eビットが設定されている場合、元のRBridgeがオプションBで定義されているとおりに動作することを示します。つまり、TRILLを待機している間、AAE RBridgeによってアドバタイズされるデータラベル内のTRILLデータパケットのカプセル化解除からMAC学習を無効にします。 {MAC、ニックネーム、データラベル}の関連付けを配布するESADI-LSP。一方、このRBridgeは、AAE RBridgeとして機能できます。ローカルLAALPから学習したMACアドレスは、セクション4.1.3で定義されているAA-LAALP-GROUP-MAC APPsub-TLVを使用して、TRILL ESADI-LSPでアドバタイズされる必要があります。ここで指定されているように、AAEグループのRBridgeが、そのAAEグループの1つ以上のデータラベルに関心のあるリモートRBridgeを監視し、リモートRBridgeがサポートしていない場合は、オプションAまたはオプションBのいずれかの拡張機能で示されます。 AAEグループはアクティブ-スタンバイモードにフォールバックする必要があります。
This APPsub-TLV is expected to rarely change, as it only needs to be updated when RBridge capabilities change, e.g., due to an upgrade or reconfiguration.
このAPPsub-TLVは、RBridge機能がアップグレードや再構成などによって変更された場合にのみ更新する必要があるため、めったに変更されないと予想されます。
This section explores how this specification meets the major design goals of AAE.
このセクションでは、この仕様がAAEの主要な設計目標をどのように満たすかについて説明します。
Since all RBridges talking with the AAE RBridges in the campus are able to see multiple attachments for one MAC address in ESADI [RFC7357], a MAC address learned from one AAE member will not be overwritten by the same MAC address learned from another AAE member. Although multiple entries for this MAC address will be created, for return traffic the remote RBridge is required to consistently use one of the attachments for each MAC address rather than flip-flopping among them (see Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357]).
キャンパス内のAAE RBridgeと通信するすべてのRBridgeは、ESADI [RFC7357]で1つのMACアドレスの複数のアタッチメントを確認できるため、あるAAEメンバーから学習したMACアドレスは、別のAAEメンバーから学習した同じMACアドレスによって上書きされません。このMACアドレスの複数のエントリが作成されますが、リターントラフィックの場合、リモートRBridgeは、それらの間でフリップフロップするのではなく、各MACアドレスのアタッチメントの1つを一貫して使用する必要があります（[RFC6325]のセクション4.2.6およびセクション5.3を参照）。 [RFC7357]の）。
LAALP guarantees that each frame will be sent to the AAE via exactly one uplink. RBridges in the AAE simply follow the process per [RFC6325] to ingress the frame. For example, each RBridge uses its own nickname as the ingress nickname to encapsulate the frame. In such a scenario, each RBridge takes for granted that it is the Appointed Forwarder for the VLANs enabled on the uplink of the LAALP.
LAALPは、各フレームが正確に1つのアップリンクを介してAAEに送信されることを保証します。 AAEのRBridgeは、[RFC6325]のプロセスに従ってフレームに進入します。たとえば、各RBridgeは独自のニックネームを入力ニックネームとして使用して、フレームをカプセル化します。このようなシナリオでは、各RBridgeは、それがLAALPのアップリンクで有効になっているVLANのAppointed Forwarderであることを当然と見なします。
A fundamental design goal of AAE is that there must be no duplication or forwarding loop.
AAEの基本的な設計目標は、複製または転送ループがあってはならないことです。
When multi-destination TRILL Data packets for a specific Data Label are received from the campus, it is important that exactly one RBridge out of the AAE group let through each multi-destination packet so that no duplication will happen. The LAALP will have defined its selection function (using hashing or an election algorithm) to designate a forwarder for a multi-destination frame. Since AAE member RBridges support the LAALP, they are able to utilize that selection function to determine the single exit point. If the output of the selection function points to the port attached to the receiving RBridge itself (i.e., the packet should be egressed out of this node), the receiving RBridge MUST egress this packet for that AAE group. Otherwise, the packet MUST NOT be egressed for that AAE group. (For ports that lead to non-AAE links, the receiving RBridge determines whether to egress the packet or not, according to [RFC6325], which is updated by [RFC7172].)
特定のデータラベルの複数宛先TRILLデータパケットがキャンパスから受信される場合、重複が発生しないように、AAEグループから1つだけのRBridgeが各複数宛先パケットを通過させることが重要です。 LAALPは、（ハッシュまたは選択アルゴリズムを使用して）その選択関数を定義して、複数の宛先フレームのフォワーダーを指定します。 AAEメンバーのRBridgesはLAALPをサポートしているため、その選択機能を利用して単一の出口点を決定できます。選択機能の出力が受信RBridge自体に接続されたポートを指している場合（つまり、パケットはこのノードから出力される必要があります）、受信RBridgeはそのAAEグループに対してこのパケットを出力する必要があります（MUST）。それ以外の場合、パケットはそのAAEグループに対して出力されてはなりません（MUST NOT）。 （非AAEリンクにつながるポートの場合、[RFC7172]によって更新される[RFC6325]に従って、受信RBridgeがパケットを出力するかどうかを決定します。）
When a multi-destination frame originated from an LAALP is ingressed by an RBridge of an AAE group, distributed to the TRILL network, and then received by another RBridge in the same AAE group, it is important that this receiving RBridge does not egress this frame back to this LAALP. Otherwise, it will cause a forwarding loop (echo). The well-known "split horizon" technique (as discussed in Section 2.2.1 of [RFC1058]) is used to eliminate the echo issue.
LAALPから発信されたマルチ宛先フレームが、AAEグループのRBridgeによって入力され、TRILLネットワークに配信され、同じAAEグループ内の別のRBridgeによって受信された場合、この受信RBridgeがこのフレームを出力しないことが重要です。このLAALPに戻ります。それ以外の場合は、転送ループ（エコー）が発生します。よく知られている「スプリットホライズン」手法（[RFC1058]のセクション2.2.1で説明）は、エコーの問題を解消するために使用されます。
RBridges in the AAE group need to perform split horizon based on the ingress RBridge nickname plus the VLAN of the TRILL Data packet. They need to set up per-port filtering lists consisting of the tuple of <ingress nickname, VLAN>. Packets with information matching any entry in the filtering list MUST NOT be egressed out of that port. The information for such filters is obtained by listening to the AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVs, as defined in Section 4.1.2. Note that all enabled VLANs MUST be consistent on all ports connected to an LAALP. So, the enabled VLANs need not be included in these TRILL APPsub-TLVs. They can be locally obtained from the port attached to that LAALP. By parsing these APPsub-TLVs, the receiving RBridge discovers all other RBridges connected to the same LAALP. The Sender Nickname of the originating RBridge will be added to the filtering list of the port attached to the LAALP. For example, RB3 in Figure 1 will set up a filtering list that looks like {<RB1, VLAN 10>, <RB2, VLAN 10>} on its port attached to LAALP1. According to split horizon, TRILL Data packets within VLAN 10 ingressed by RB1 or RB2 will not be egressed out of this port.
AAEグループのRBridgeは、入力RBridgeニックネームとTRILLデータパケットのVLANに基づいてスプリットホライズンを実行する必要があります。 <ingress nickname、VLAN>のタプルで構成されるポートごとのフィルタリングリストを設定する必要があります。フィルタリングリストのエントリに一致する情報を持つパケットは、そのポートから出力してはなりません。このようなフィルターの情報は、セクション4.1.2で定義されているように、AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVをリッスンすることによって取得されます。すべての有効なVLANは、LAALPに接続されているすべてのポートで一貫している必要があることに注意してください。したがって、有効なVLANをこれらのTRILL APPsub-TLVに含める必要はありません。それらは、そのLAALPに接続されたポートからローカルに取得できます。これらのAPPsub-TLVを解析することにより、受信RBridgeは、同じLAALPに接続されている他のすべてのRBridgeを検出します。発信元のRBridgeの送信者ニックネームは、LAALPに接続されているポートのフィルタリングリストに追加されます。たとえば、図1のRB3は、LAALP1に接続されたポートに{<RB1、VLAN 10>、<RB2、VLAN 10>}のようなフィルタリングリストをセットアップします。スプリットホライズンによれば、RB1またはRB2によって入力されたVLAN 10内のTRILLデータパケットは、このポートから出力されません。
When there are multiple LAALPs connected to the same RBridge, these LAALPs may have VLANs that overlap. Here, a VLAN overlap means that this VLAN ID is enabled by multiple LAALPs. A customer may require that hosts within these overlapped VLANs communicate with each other.
同じRBridgeに複数のLAALPが接続されている場合、これらのLAALPに重複するVLANがある場合があります。ここで、VLANの重複とは、このVLAN IDが複数のLAALPによって有効にされることを意味します。お客様は、これらの重複したVLAN内のホストが互いに通信することを要求する場合があります。
Appendix A provides several scenarios to explain how hosts communicate within the overlapped VLANs and how split horizon happens.
付録Aでは、ホストがオーバーラップしたVLAN内で通信する方法と、スプリットホライズンがどのように発生するかを説明するいくつかのシナリオを示します。
If a sub-link of the LAALP fails while remote RBridges continue to send packets towards the failed port, a black-hole happens. If the AAE member RBridge with that failed port starts to redirect the packets to other member RBridges for delivery, triangular forwarding occurs.
リモートRBridgeが障害のあるポートに向けてパケットを送信し続けている間にLAALPのサブリンクに障害が発生すると、ブラックホールが発生します。その障害のあるポートを持つAAEメンバーRBridgeが配信のために他のメンバーRBridgeにパケットをリダイレクトし始めると、三角転送が発生します。
The member RBridge attached to the failed sub-link makes use of the ESADI protocol to flush those MAC addresses affected by the failure, as defined in Section 5.2 of [RFC7357]. After doing that, no packets will be sent towards the failed port, and hence no black-hole will happen. Nor will the member RBridge need to redirect packets to other member RBridges; thus, triangular forwarding is avoided.
[RFC7357]のセクション5.2で定義されているように、障害のあるサブリンクに接続されているメンバーRBridgeは、ESADIプロトコルを使用して、障害の影響を受けるMACアドレスをフラッシュします。その後、障害が発生したポートに向けてパケットが送信されることはないため、ブラックホールは発生しません。また、メンバーRBridgeがパケットを他のメンバーRBridgeにリダイレクトする必要もありません。したがって、三角転送は回避されます。
Since a remote RBridge can see multiple attachments of one MAC address in ESADI, this remote RBridge can choose to spread the traffic towards the AAE members on a per-flow basis. Each of them is able to act as the egress point. In doing this, the forwarding paths need not be limited to the least-cost path selection from the ingress RBridge to the AAE RBridges. The traffic load from the remote RBridge towards the AAE RBridges can be balanced based on a pseudorandom selection method (see Section 4.1.3).
リモートRBridgeはESADIで1つのMACアドレスの複数のアタッチメントを見ることができるため、このリモートRBridgeはフローごとにAAEメンバーにトラフィックを分散することを選択できます。それらのそれぞれは、出口ポイントとして機能することができます。これを行う際、転送パスは、入口RBridgeからAAE RBridgeへの最小コストのパス選択に限定される必要はありません。リモートRBridgeからAAE RBridgeへのトラフィック負荷は、疑似ランダム選択法（セクション4.1.3を参照）に基づいて分散できます。
Note that the load-balance method adopted at a remote ingress RBridge is not to replace the load-balance mechanism of LAALP. These two load-spreading mechanisms should take effect separately.
リモート入力RBridgeで採用されている負荷分散方式は、LAALPの負荷分散メカニズムを置き換えるものではないことに注意してください。これらの2つの負荷分散メカニズムは個別に有効になります。
With Option A, multiple attachments need to be recorded for a MAC address learned from AAE RBridges. More entries may be consumed in the MAC learning table. However, MAC addresses attached to an LAALP are usually only a small part of all MAC addresses in the whole TRILL campus. As a result, the extra table memory space required by multi-attached MAC addresses can usually be accommodated in an RBridge's unused MAC table space.
オプションAでは、AAE RBridgeから学習したMACアドレスに対して複数のアタッチメントを記録する必要があります。 MAC学習テーブルでより多くのエントリが消費される可能性があります。ただし、LAALPに接続されたMACアドレスは、通常、TRILLキャンパス全体のすべてのMACアドレスのごく一部です。その結果、マルチアタッチMACアドレスに必要な追加のテーブルメモリスペースは、通常、RBridgeの未使用のMACテーブルスペースに収容できます。
With Option B, remote RBridges will keep the multiple attachments of a MAC address in the ESADI link-state databases, which are usually maintained by software. In the MAC table, which is normally implemented in hardware, an RBridge still establishes only one entry for each MAC address.
オプションBを使用すると、リモートRBridgeは、MACアドレスの複数のアタッチメントをESADIリンクステートデータベースに保持します。これは通常、ソフトウェアによって維持されます。通常ハードウェアに実装されているMACテーブルでは、RBridgeは各MACアドレスに対して1つのエントリのみを確立します。
The Extended TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document are to be used in an Extended Level 1 Flooding Scope (E-L1FS) PDU [RFC7356] [RFC7780]. For those RBridges that do not support E-L1FS, the EXTENDED-RBRIDGE-CAP TRILL APPsub-TLV will not be sent out either, and MAC multi-attach active-active is not supported.
このドキュメントのセクション4.1.2、4.1.3、および4.2で定義されている拡張TLVは、拡張レベル1フラッディングスコープ（E-L1FS）PDU [RFC7356] [RFC7780]で使用されます。 E-L1FSをサポートしないRBridgeの場合、EXTENDED-RBRIDGE-CAP TRILL APPsub-TLVも送信されず、MACマルチアタッチアクティブ-アクティブはサポートされません。
For security considerations pertaining to extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357].
TRILL ESADIによって転送される拡張機能に関連するセキュリティの考慮事項については、[RFC7357]のセキュリティに関する考慮事項のセクションを参照してください。
For extensions not transported by TRILL ESADI, RBridges may be configured to include the IS-IS Authentication TLV (10) in the IS-IS PDUs to use IS-IS security [RFC5304] [RFC5310].
TRILL ESADIによってトランスポートされない拡張の場合、IS-ISセキュリティ[RFC5304] [RFC5310]を使用するためにIS-IS PDUにIS-IS認証TLV（10）を含めるようにRBridgeを構成できます。
Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, AAE groups is proprietary. In environments where the above authentication is not adopted, a rogue RBridge that insinuates itself into an AAE group can disrupt end-station traffic flowing into or out of that group. For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group.
現在展開されているLAALP [RFC7379]は独自仕様であるため、AAEグループのメンバーシップおよび内部管理に関するセキュリティは独自仕様です。上記の認証が採用されていない環境では、自身をAAEグループに組み込む悪質なRBridgeが、そのグループに出入りするエンドステーショントラフィックを妨害する可能性があります。たとえば、グループにN個のRBridgeがある場合、通常、そのグループから流出するトラフィックの1 / Nと、そのグループに流入する同様の量のユニキャストトラフィックを制御できます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
IANA has allocated three new types under the TRILL GENINFO TLV [RFC7357] for the TRILL APPsub-TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document. The following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on the TRILL Parameters IANA web page.
IANAは、このドキュメントのセクション4.1.2、4.1.3、および4.2で定義されているTRILL APPsub-TLVのTRILL GENINFO TLV [RFC7357]の下に3つの新しいタイプを割り当てました。次のエントリが、TRILLパラメータIANA Webページの「IS-IS TLV 251 Application Identifier 1の下のTRILL APPsub-TLVタイプ」レジストリに追加されました。
Type Name Reference
---- ---- ---------
252 AA-LAALP-GROUP-RBRIDGES RFC 7782
253 AA-LAALP-GROUP-MAC RFC 7782
254 EXTENDED-RBRIDGE-CAP RFC 7782
IANA has created a registry under the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリの下に次のようにレジストリを作成しました。
Name: Extended RBridge Capabilities
名前：拡張RBridge機能
Registration Procedure: Expert Review
登録手順：専門家によるレビュー
Reference: RFC 7782
リファレンス：RFC 7782
Bit Mnemonic Description Reference
---- -------- ----------- ---------
0 E Option B Support RFC 7782
1 H Option A Support RFC 7782
2-63 - Unassigned
IANA has allocated two flag bits, with mnemonic "AA", as follows:
IANAは、次のようにニーモニック「AA」で2つのフラグビットを割り当てています。
One flag bit is allocated from the Interested VLANs Flag Bits.
関係するVLANフラグビットから1つのフラグビットが割り当てられます。
Bit Mnemonic Description Reference
--- -------- ----------- ---------
16 AA VLANs for Active-Active RFC 7782
One flag bit is allocated from the Interested Labels Flag Bits.
1つのフラグビットは、興味のあるラベルフラグビットから割り当てられます。
Bit Mnemonic Description Reference
--- -------- ----------- ---------
4 AA FGLs for Active-Active RFC 7782
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2014、DOI 10.1109 / IEEESTD.2014.7055197、2014年12月。
[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>。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、DOI 10.17487 / RFC6165、2011年4月、<http://www.rfc-editor.org/info / rfc6165>。
[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、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A.、and F. Hu、 "Routing Bridges（RBridges）：Appointed Forwarders"、RFC 6439、DOI 10.17487 / RFC6439、November 2011、 <http://www.rfc-editor.org/info/rfc6439>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、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.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、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.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<http://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, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-ISフラッディングスコープリンクステートPDU（LSP）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// 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, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<http://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, <http://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月、<http://www.rfc-editor.org/info/rfc7780>。
[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月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, DOI 10.17487/RFC1058, June 1988, <http://www.rfc-editor.org/info/rfc1058>.
[RFC1058] Hedrick、C。、「Routing Information Protocol」、RFC 1058、DOI 10.17487 / RFC1058、1988年6月、<http://www.rfc-editor.org/info/rfc1058>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[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 Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントと、リンクの透過的な相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標」 "、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<http://www.rfc-editor.org/info/rfc7379>。
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <http://www.rfc-editor.org/info/rfc7781>.
[RFC7781] Zhai、H.、Senevirathne、T.、Perlman、R.、Zhang、M.、Y。Li、「多数のリンクの透過的な相互接続（TRILL）：アクティブ-アクティブアクセスの疑似ニックネーム」、RFC 7781、DOI 10.17487 / RFC7781、2016年2月、<http://www.rfc-editor.org/info/rfc7781>。
[TRILL-MT] Eastlake 3rd, D., Zhang, M., Banerjee, A., and V. Manral, "TRILL: Multi-Topology", Work in Progress, draft-ietf-trill-multi-topology-00, September 2015.
[TRILL-MT] Eastlake 3rd、D.、Zhang、M.、Banerjee、A.、and V. Manral、 "TRILL：Multi-Topology"、Work in Progress、draft-ietf-trill-multi-topology-00、 2015年9月。
+------------------+ +------------------+ +------------------+
| RB1 | | RB2 | | RB3 |
+------------------+ +------------------+ +------------------+
L1 L2 L3 L1 L2 L3 L1 L2 L3
VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN
B1 B2 B10 B1 B2 B20 B1 B2 B30
Figure 2: An Example Topology to Explain Split Horizon
図2：スプリットホライズンを説明するトポロジの例
Suppose that RB1, RB2, and RB3 are the active-active group connecting LAALP1 and LAALP2. LAALP1 and LAALP2 are connected to B1 and B2 at their other ends. Suppose that all these RBridges use port L1 to connect LAALP1 while they use port L2 to connect LAALP2. Assume that all three L1 ports enable VLANs 10-20 while all three L2 ports enable VLANs 15-25, so that there is an overlap of VLANs 15-20. A customer may require that hosts within these overlapped VLANs communicate with each other. That is, hosts attached to B1 in VLANs 15-20 need to communicate with hosts attached to B2 in VLANs 15-20. Assume that the remote plain RBridge RB4 also has hosts attached in VLANs 15-20 that need to communicate with those hosts in these VLANs attached to B1 and B2.
RB1、RB2、およびRB3がLAALP1とLAALP2を接続するアクティブ-アクティブグループであると仮定します。 LAALP1とLAALP2は、他端でB1とB2に接続されています。これらすべてのRBridgeがポートL1を使用してLAALP1を接続し、ポートL2を使用してLAALP2を接続するとします。 3つのL1ポートすべてがVLAN 10〜20を有効にし、3つすべてのL2ポートがVLAN 15〜25を有効にするため、VLAN 15〜20のオーバーラップがあると仮定します。お客様は、これらの重複したVLAN内のホストが互いに通信することを要求する場合があります。つまり、VLAN 15〜20のB1に接続されたホストは、VLAN 15〜20のB2に接続されたホストと通信する必要があります。リモートのプレーンRBridge RB4にも、VLAN 15〜20に接続されたホストがあり、B1およびB2に接続されたこれらのVLAN内のホストと通信する必要があると仮定します。
There are two major requirements:
2つの主要な要件があります。
1. Frames ingressed from RB1-L1-VLANs 15-20 MUST NOT be egressed out of ports RB2-L1 and RB3-L1.
1. RB1-L1-VLAN 15-20から入ったフレームは、ポートRB2-L1とRB3-L1から出てはいけません（MUST NOT）。
2. At the same time, frames coming from B1-VLANs 15-20 should reach B2-VLANs 15-20.
2. 同時に、B1-VLAN 15-20からのフレームはB2-VLAN 15-20に到達する必要があります。
RB3 stores the information for split horizon on its ports L1 and L2.
RB3は、ポートL1およびL2にスプリットホライズンの情報を格納します。
On L1: {<ingress_nickname_RB1, VLANs 10-20>, <ingress_nickname_RB2, VLANs 10-20>}.
L1：{<ingress_nickname_RB1、VLANs 10-20>、<ingress_nickname_RB2、VLANs 10-20>}。
On L2: {<ingress_nickname_RB1, VLANs 15-25>, <ingress_nickname_RB2, VLANs 15-25>}.
L2の場合：{<ingress_nickname_RB1、VLANs 15-25>、<ingress_nickname_RB2、VLANs 15-25>}。
Five clarification scenarios follow:
5つの明確化シナリオが続きます。
a. Suppose that RB2 or RB3 receives a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB1. RB3 is the single exit point (selected according to the hashing function of LAALP) for this packet. On ports L1 and L2, RB3 has covered <ingress_nickname_RB1, VLAN 15>, so that RB3 will not egress this packet out of either L1 or L2. Here, "split horizon" happens.
a. RB2またはRB3が、VLAN 15とingress_nickname_RB1を持つTRILLマルチ宛先データパケットを受信するとします。 RB3は、このパケットの（LAALPのハッシュ関数に従って選択された）単一の出口点です。ポートL1およびL2では、RB3は<ingress_nickname_RB1、VLAN 15>をカバーしているため、RB3はL1またはL2のどちらからもこのパケットを出力しません。ここで、「スプリットホライズン」が起こります。
Beforehand, RB1 obtains a native frame on port L1 from B1 in VLAN 15. RB1 determines that it should be forwarded as a multi-destination packet across the TRILL campus. Also, RB1 replicates this frame without TRILL encapsulation and sends it out of port L2, so that B2 will get this frame.
事前に、RB1はVLAN 15のB1からポートL1のネイティブフレームを取得します。RB1は、フレームをTRILLキャンパス全体で複数の宛先のパケットとして転送する必要があると判断します。また、RB1はこのフレームをTRILLカプセル化なしで複製し、ポートL2から送信するため、B2はこのフレームを取得します。
b. Suppose that RB2 or RB3 receives a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB4. RB3 is the single exit point. On ports L1 and L2, since RB3 has not stored any tuple with ingress_nickname_RB4, RB3 will decapsulate the packet and egress it out of both ports L1 and L2. So, both B1 and B2 will receive the frame.
b. RB2またはRB3が、VLAN 15とingress_nickname_RB4を持つTRILLマルチ宛先データパケットを受信するとします。 RB3は単一の出口点です。ポートL1およびL2では、RB3はingress_nickname_RB4を持つタプルを格納していないため、パケットをカプセル化解除し、ポートL1とL2の両方からパケットを出力します。したがって、B1とB2の両方がフレームを受信します。
c. Suppose that there is a plain LAN link port L3 on RB1, RB2, and RB3, connecting to B10, B20, and B30, respectively. These L3 ports happen to be configured with VLAN 15. On port L3, RB2 and RB3 store no information for split horizon for AAE (since this port has not been configured to be in any LAALP). They will egress the packet ingressed from RB1-L1 in VLAN 15.
c. RB1、RB2、およびRB3に、それぞれB10、B20、およびB30に接続するプレーンLANリンクポートL3があるとします。これらのL3ポートはたまたまVLAN 15で構成されています。ポートL3では、RB2とRB3はAAEのスプリットホライズンの情報を格納しません（このポートはどのLAALPにも構成されていないため）。 VLAN 15のRB1-L1から入力されたパケットを出力します。
d. If a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, port RB1-L3 will not egress packets with ingress_nickname_RB1. RB1 needs to replicate this frame without encapsulation and sends it out of port L3. This kind of "bounce" behavior for multi-destination frames is just as specified in paragraph 3 of Section 4.6.1.2 of [RFC6325].
d. パケットがVLAN 15でRB1-L1またはRB1-L2から入力される場合、ポートRB1-L3はingress_nickname_RB1でパケットを出力しません。 RB1はこのフレームをカプセル化せずに複製し、ポートL3から送信する必要があります。マルチ宛先フレームのこの種の「バウンス」動作は、[RFC6325]のセクション4.6.1.2の段落3で指定されているとおりです。
e. If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2 cannot egress packets with VLAN 15 and ingress_nickname_RB1, RB1 needs to replicate this frame without encapsulation and sends it out of ports L1 and L2. (Also see paragraph 3 of Section 4.6.1.2 of [RFC6325].)
e. パケットがRB1-L3から入力された場合、RB1-L1とRB1-L2はVLAN 15とingress_nickname_RB1でパケットを出力できないため、RB1はカプセル化せずにこのフレームを複製し、ポートL1とL2から送信する必要があります。 （[RFC6325]のセクション4.6.1.2のパラグラフ3も参照してください）。
Acknowledgments
謝辞
The authors would like to thank the following people for their comments and suggestions: Andrew Qu, Donald Eastlake, Erik Nordmark, Fangwei Hu, Liang Xia, Weiguo Hao, Yizhou Li, and Mukhtiar Shaikh.
著者たちは、コメントと提案をしてくれた次の人々に感謝したいと思います。AndrewQu、Donald Eastlake、Erik Nordmark、Fangwei Hu、Liang Xia、Weiguo Hao、Yizhou Li、およびMukhtiar Shaikh。
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中国
Email: zhangmingui@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
らぢあ ぺｒｌまん えＭＣ ２０１０ ２５６ｔｈ あゔぇぬえ ね、 ＃２００ べっぇゔえ、 わ ９８００７ うにてｄ Ｓたてｓ
Email: radia@alum.mit.edu
Hongjun Zhai Nanjing Astute Software Technology Co. Ltd 57 Andemen Avenue, Yuhuatai District Nanjing, Jiangsu 210016 China
ニュージーランドによれば、NaNjingastute software technology co。Ltd 57 an、Y U Huatai District NaNjing、Jiangsu 210016 China
Email: honjun.zhai@tom.com
Muhammad Durrani Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 United States
Muhammad Durrani Cisco Systems 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国
Email: mdurrani@cisco.com
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangaloreインド560048
Email: sujay.gupta@ipinfusion.com