RFC 8564 - Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8564
タイトル : RFC 8564 - 多数のリンクの透過的な相互接続（TRILL）でのポイントツーマルチポイント双方向転送検出（BFD）のサポート
翻訳編集 : 自動生成

[要約] RFC 8564は、TRILLでのPoint-to-Multipoint BFDのサポートに関するものであり、TRILLネットワークでのBFDの機能を拡張することを目的としています。

Internet Engineering Task Force (IETF)                          M. Zhang
Request for Comments: 8564                           Huawei Technologies
Updates: 7175, 7177                                        S. Pallagatti
Category: Standards Track                                         Vmware
ISSN: 2070-1721                                              V. Govindan
                                                           Cisco Systems
                                                              April 2019

Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)

多数のリンクの透過的な相互接続（TRILL）でのポイントツーマルチポイント双方向転送検出（BFD）のサポート

Abstract

概要

Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages. This document updates RFCs 7175 and 7177.

ポイントツーマルチポイント（P2MP）双方向転送検出（BFD）は、マルチポイント接続を検証するように設計されています。このドキュメントでは、リンクの透過的な相互接続（TRILL）におけるP2MP BFDのサポートについて説明します。 TRILLポイントツーポイントBFDと同様に、TRILL P2MP BFDのBFD制御パケットは、RBridgeチャネルメッセージを使用して送信されます。このドキュメントは、RFC 7175および7177を更新します。

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/rfc8564.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8564で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Acronyms and Terminology  . . . . . . . . . . . . . . . . . .   3
     2.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  A New RBridge Channel Message for P2MP BFD  . . . . . . . . .   4
   5.  Discriminators and Packet Demultiplexing  . . . . . . . . . .   4
   6.  Tracking Active Tails . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

TRILL supports multicast forwarding. Applications based on TRILL multicast may need quick detection of multicast failures using P2MP BFD [RFC8562]. This document specifies TRILL support of P2MP BFD.

TRILLはマルチキャスト転送をサポートしています。 TRILLマルチキャストに基づくアプリケーションは、P2MP BFD [RFC8562]を使用してマルチキャスト障害の迅速な検出を必要とする場合があります。このドキュメントでは、P2MP BFDのTRILLサポートを指定しています。

To use P2MP BFD, the head end needs to periodically transmit BFD Control packets to all tails using TRILL multicast. A new RBridge Channel message is allocated for this purpose.

P2MP BFDを使用するには、ヘッドエンドがTRILLマルチキャストを使用してBFD制御パケットをすべてのテールに定期的に送信する必要があります。このために、新しいRBridge Channelメッセージが割り当てられます。

In order to execute the global protection of distribution used for multicast forwarding [TRILL-TREES], the head needs to track the active status of tails [RFC8563]. If the tail loses connectivity as detected by not receiving the new RBridge Channel message from the head, the tail should notify the head of the lack of multipoint connectivity with unicast BFD Control packets. These unicast BFD Control packets are transmitted using the existing RBridge Channel message assigned to BFD Control [RFC7175].

マルチキャスト転送[TRILL-TREES]に使用される配信のグローバル保護を実行するには、ヘッドがテールのアクティブステータスを追跡する必要があります[RFC8563]。ヘッドから新しいRBridge Channelメッセージを受信しないことによって検出されたテールの接続が失われた場合、テールはユニキャストBFD制御パケットによるマルチポイント接続の欠如をヘッドに通知する必要があります。これらのユニキャストBFD制御パケットは、BFD制御に割り当てられた既存のRBridge Channelメッセージを使用して送信されます[RFC7175]。

This document updates [RFC7177] as specified in Section 3 and updates [RFC7175] as specified in Sections 4 and 5.

このドキュメントは、セクション3で指定されているように[RFC7177]を更新し、セクション4および5で指定されているように[RFC7175]を更新します。

2. Acronyms and Terminology

2. 頭字語と用語

2.1. Acronyms

2.1. 頭字語

Data Label: VLAN or Fine-Grained Label [RFC7172].

データラベル：VLANまたは細かいラベル[RFC7172]。

BFD: Bidirectional Forwarding Detection

BFD：双方向転送検出

P2MP: Point to Multipoint

P2MP：ポイントツーマルチポイント

TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer

TRILL：多数のリンクの透過的な相互接続またはリンク層のトンネルルーティング

2.2. Terminology

2.2. 用語

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]で説明されているように解釈されます。

Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in this document.

このドキュメントでは、[RFC6325]、[RFC7175]、および[RFC7178]に精通していることを前提としています。

3. Bootstrapping

3. ブートストラップ

The TRILL adjacency mechanism bootstraps the establishment of one-hop TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to be configured by the network manager. A slight wording update to the second sentence in Section 6 of [RFC7177] is required.

TRILL隣接メカニズムは、1ホップのTRILL BFDセッション[RFC7177]の確立をブートストラップします。マルチホップセッションは、ネットワーク管理者によって構成されることが期待されています。 [RFC7177]のセクション6の2番目の文の文言を少し更新する必要があります。

It currently reads:

それは現在読み取ります：

If an RBridge supports BFD [RFC7175], it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.

RBridgeがBFD [RFC7175]をサポートしている場合、BFD対応TLV [RFC6213]がHelloに含まれていたかどうかによって、他のRBridgeでBFDが有効になっているかどうかがわかります。

Now it should read:

今それは読むべきです：

If an RBridge supports BFD (see [RFC7175] and [RFC8564]), it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.

RBridgeがBFDをサポートしている場合（[RFC7175]と[RFC8564]を参照）、BFD対応のTLV [RFC6213]がHelloに含まれているかどうかによって、他のRBridgeでBFDが有効になっているかどうかがわかります。

In addition, a normative reference to this document is added to RFC 7177 as a result of this update.

さらに、この更新の結果として、このドキュメントへの規範的な参照がRFC 7177に追加されました。

4. A New RBridge Channel Message for P2MP BFD

4. P2MP BFDの新しいRBridgeチャネルメッセージ

RBridge Channel protocol number 0x002 is defined for TRILL point-to-point BFD Control packets in [RFC7175]. That RFC states that if the M bit of the TRILL Header of the RBridge Channel packet containing a BFD Control packet is nonzero, the packet is generally dropped. In P2MP BFD, the head is required to probe tails using multicast. This means the M bit will be set to 1. For this reason, a new RBridge Channel message (P2MP BFD Control), whose protocol code point is 0x007, is specified in this document. An RBridge that supports P2MP BFD MUST support the new RBridge Channel message for P2MP BFD. The capability to support the RBridge Channel message for P2MP BFD, and therefore support performing P2MP BFD, is announced within the RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs) [RFC7176].

RBridge Channelプロトコル番号0x002は、[RFC7175]のTRILLポイントツーポイントBFD制御パケットに対して定義されています。そのRFCは、BFD制御パケットを含むRBridgeチャネルパケットのTRILLヘッダーのMビットがゼロ以外の場合、パケットは通常ドロップされると述べています。 P2MP BFDでは、マルチキャストを使用してテールをプローブするためにヘッドが必要です。つまり、Mビットは1に設定されます。このため、このドキュメントでは、プロトコルコードポイントが0x007である新しいRBridgeチャネルメッセージ（P2MP BFDコントロール）が指定されています。 P2MP BFDをサポートするRBridgeは、P2MP BFDの新しいRBridge Channelメッセージをサポートする必要があります。 P2MP BFDのRBridge Channelメッセージをサポートする機能、つまりP2MP BFDの実行をサポートする機能は、リンク状態PDU（LSP）[RFC7176]のRBridge Channel ProtocolsサブTLV内でアナウンスされます。

As specified in [RFC7178], when the tail receives TRILL Data packets sent as BFD RBridge Channel messages, it will absorb the packets itself rather than deliver these packets to its attached end stations.

[RFC7178]で指定されているように、BFD RBridge Channelメッセージとして送信されたTRILLデータパケットをテールが受信すると、接続されているエンドステーションにパケットを配信するのではなく、パケット自体を吸収します。

5. Discriminators and Packet Demultiplexing

5. 弁別器とパケット逆多重化

The processing in Section 3.2 of [RFC7175] generally applies except that the test on the M bit in the TRILL Header is reversed. If the M bit is zero, the packet MUST be discarded. If the M bit is one, it is processed.

[RFC7175]のセクション3.2の処理は、TRILLヘッダーのMビットのテストが逆になっていることを除いて、一般的に適用されます。 Mビットがゼロの場合、パケットは破棄されなければなりません（MUST）。 Mビットが1の場合、処理されます。

After the processing per Section 3.2 of [RFC7175], the tail demultiplexes incoming BFD packets based on a combination of the source address and My Discriminator as specified in [RFC8562]. In addition to this combination, TRILL P2MP BFD requires that the tail use the Data Label, which is either the inner VLAN or the Fine-Grained Label [RFC7172], for demultiplexing. If the tail needs to notify the head about the failure of a multipath, the tail is required to send unicast BFD Control packets using the same Data Label as used by the head.

[RFC7175]のセクション3.2による処理の後、テールは、[RFC8562]で指定されているソースアドレスとMy Discriminatorの組み合わせに基づいて、着信BFDパケットを逆多重化します。この組み合わせに加えて、TRILL P2MP BFDでは、逆多重化のために、テールが内部VLANまたは細粒度ラベル[RFC7172]のいずれかであるデータラベルを使用する必要があります。テールがマルチパスの障害についてヘッドに通知する必要がある場合、テールが使用するのと同じデータラベルを使用してユニキャストBFD制御パケットを送信する必要があります。

6. Tracking Active Tails

6. アクティブテールの追跡

According to [RFC8562], the head has a session of type MultipointHead that is bound to a multipoint path. Multipoint BFD Control packets are sent by this session over the multipoint path, and no BFD Control packets are received by it. Each tail dynamically creates a MultipointTail per a multipoint path. MultipointTail sessions receive BFD Control packets from the head over multipoint paths.

[RFC8562]によれば、ヘッドにはマルチポイントパスにバインドされたタイプMultipointHeadのセッションがあります。マルチポイントBFD制御パケットは、このセッションによってマルチポイントパスを介して送信され、BFD制御パケットは受信されません。各テールは、マルチポイントパスごとにMultipointTailを動的に作成します。 MultipointTailセッションは、マルチポイントパスを介してヘッドからBFD制御パケットを受信します。

An example use is when a multicast tree root needs to keep track of all the receivers as in [TRILL-TREES]; this can be done by maintaining a session of type MultipointClient per receiver that is of interest, as described in [RFC8563]. See [RFC8563] for detailed operations of tracking active tails.

使用例は、[TRILL-TREES]のように、マルチキャストツリールートがすべてのレシーバーを追跡する必要がある場合です。これは、[RFC8563]で説明されているように、対象のレシーバーごとにタイプMultipointClientのセッションを維持することで実行できます。アクティブテールを追跡する詳細な操作については、[RFC8563]を参照してください。

7. Security Considerations

7. セキュリティに関する考慮事項

Multipoint BFD provides its own authentication but does not provide encryption (see the Security Considerations in [RFC8562]). As specified in this document, the point-to-multipoint BFD payloads are encapsulated in RBridge Channel messages that have been extended by [RFC7978] to provide security. [RFC7978] provides encryption only for point-to-point extended RBridge Channel messages, so its encryption facilities are not applicable to this document. However, [RFC7978] provides stronger authentication than that currently provided in BFD. Thus, there is little reason to use the BFD security mechanisms if authentication per [RFC7978] is in use. It is expected that a future TRILL document will provide for group keying; when that occurs, the use of RBridge Channel security [RFC7978] will be able to provide both encryption and authentication.

マルチポイントBFDは独自の認証を提供しますが、暗号化は提供しません（[RFC8562]のセキュリティに関する考慮事項を参照）。このドキュメントで指定されているように、ポイントツーマルチポイントBFDペイロードは、セキュリティを提供するために[RFC7978]によって拡張されたRBridge Channelメッセージにカプセル化されています。 [RFC7978]は、ポイントツーポイントの拡張RBridgeチャネルメッセージに対してのみ暗号化を提供するため、その暗号化機能はこのドキュメントには適用されません。ただし、[RFC7978]は、BFDで現在提供されているものよりも強力な認証を提供します。したがって、[RFC7978]による認証が使用されている場合、BFDセキュリティメカニズムを使用する理由はほとんどありません。今後のTRILLドキュメントでグループキーイングが提供される予定です。その場合、RBridge Channelセキュリティ[RFC7978]を使用すると、暗号化と認証の両方を提供できます。

For general multipoint BFD security considerations, see [RFC8562].

一般的なマルチポイントBFDセキュリティの考慮事項については、[RFC8562]を参照してください。

For general RBridge Channel security considerations, see [RFC7178].

RBridgeチャネルのセキュリティに関する一般的な考慮事項については、[RFC7178]を参照してください。

8. IANA Considerations

8. IANAに関する考慮事項

IANA has allocated the following from the Standards Action [RFC8126] range of the "RBridge Channel Protocols" registry, which is part of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.

IANAは、「RBridge Channel Protocols」レジストリの標準アクション[RFC8126]の範囲から以下を割り当てました。これは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリの一部です。

          Protocol          Number
          ----------------  ------
          P2MP BFD Control  0x007

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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>。

[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <https://www.rfc-editor.org/info/rfc7175>.

[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「多数のリンクの透過的相互接続（TRILL）：双方向転送検出（BFD）サポート」、RFC 7175、DOI 10.17487 / RFC7175、2014年5月、<https://www.rfc-editor.org/info/rfc7175>。

[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>。

[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <https://www.rfc-editor.org/info/rfc7178>.

[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、DOI 10.17487 / RFC7178、2014年5月、<https://www.rfc-editor.org/info/rfc7178>。

[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <https://www.rfc-editor.org/info/rfc7978>.

[RFC7978] Eastlake 3rd、D.、Umair、M.、Y。Li、「Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Header Extension」、RFC 7978、DOI 10.17487 / RFC7978、2016年9月、<https： //www.rfc-editor.org/info/rfc7978>。

[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>。

[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, <https://www.rfc-editor.org/info/rfc8562>.

[RFC8562] Katz、D.、Ward、D.、Pallagatti、S。、編、およびG. Mirsky、編、「Bidirectional Forwarding Detection（BFD）for Multipoint Networks」、RFC 8562、DOI 10.17487 / RFC8562、April 2019、<https://www.rfc-editor.org/info/rfc8562>。

[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, <https://www.rfc-editor.org/info/rfc8563>.

[RFC8563] Katz、D.、Ward、D.、Pallagatti、S。、編、およびG. Mirsky、編、「Bidirectional Forwarding Detection（BFD）Multipoint Active Tails」、RFC 8563、DOI 10.17487 / RFC8563、4月2019、<https://www.rfc-editor.org/info/rfc8563>。

9.2. Informative References

9.2. 参考引用

[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, DOI 10.17487/RFC6213, April 2011, <https://www.rfc-editor.org/info/rfc6213>.

[RFC6213] Hopps、C。およびL. Ginsberg、「IS-IS BFD-enabled TLV」、RFC 6213、DOI 10.17487 / RFC6213、2011年4月、<https://www.rfc-editor.org/info/rfc6213> 。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

[TRILL-TREES] Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., and A. Ghanwani, "TRILL: Resilient Distribution Trees", Work in Progress, draft-ietf-trill-resilient-trees-09, January 2018.

[TRILL-TREES] Zhang、M.、Senevirathne、T.、Pathangi、J.、Banerjee、A。、およびA. Ghanwani、「TRILL：Resilient Distribution Trees」、Work in Progress、draft-ietf-trill-resilient- trees-09、2018年1月。

Acknowledgements

謝辞

The authors would like to thank Gayle Noble and Donald Eastlake 3rd for their comments and suggestions.

著者は、コメントと提案をしてくれたGayle NobleとDonald Eastlake 3rdに感謝します。

Authors' Addresses

著者のアドレス

Mingui Zhang Huawei Technologies No.156 Beiqing Rd. Haidian District Beijing 100095 China

min鬼Zhang hu Aはテクノロジーno.156であるiqing RD。H短地点地区北京100095中国

   Email: zhangmingui@huawei.com

Santosh Pallagatti Vmware

サントシュパラガッティ

   Email: santosh.pallagatti@gmail.com

Vengada Prasad Govindan Cisco Systems

   Email: venggovi@cisco.com