[要約] RFC 6213は、IS-ISプロトコルにおけるBFD-Enabled TLVの仕様を定義しています。このTLVは、BFD（Bidirectional Forwarding Detection）を使用してネットワークのリンク状態を監視するために使用されます。目的は、IS-ISプロトコルを使用してネットワークの高速なリンク障害検出を実現することです。
Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 6213 L. Ginsberg
Category: Standards Track Cisco Systems
ISSN: 2070-1721 April 2011
IS-IS BFD-Enabled TLV
IS-IS BFD対応TLV
Abstract
概要
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method.
このドキュメントでは、双方向転送検出（BFD）プロトコルの適切な使用を可能にするIS-ISルーティングプロトコルで使用するためのタイプ長値（TLV）について説明します。IS-ISは、このTLVまたは他の方法を使用せずにBFD検出された転送面の故障に適切に反応しない特定のシナリオが存在します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6213.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6213で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. The Problem .....................................................2
3. The Solution ....................................................3
3.1. State Definitions ..........................................3
3.2. Adjacency Establishment and Maintenance ....................4
3.3. Advertisement of Topology-Specific IS Neighbors ............4
4. Transition ......................................................4
5. Graceful Restart ................................................5
6. The BFD-Enabled TLV .............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgements ................................................6
10. Normative References ...........................................7
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is a protocol that allows for detection of a forwarding plane failure between two routers. A router can use [RFC5880] to validate that a peer router's forwarding ability is functioning.
双方向転送検出（BFD）プロトコル[RFC5880]は、2つのルーター間の転送面故障を検出できるプロトコルです。ルーターは[RFC5880]を使用して、ピアルーターの転送能力が機能していることを検証できます。
One specific application of BFD as described in [RFC5882] is to verify the forwarding ability of an IS-IS [RFC1195] router's adjacencies; however, the method described in [RFC5882] does not allow for certain failure scenarios. We will define a TLV that will allow for proper response to the detection of all forwarding failures where the use of BFD is employed with IS-IS.
[RFC5882]で説明されているBFDの特定の適用の1つは、IS-IS [RFC1195]ルーターの隣接の転送能力を検証することです。ただし、[RFC5882]で説明されている方法では、特定の障害シナリオは許可されていません。BFDの使用がIS-ISで採用されている場合、すべての転送障害の検出に対する適切な応答を可能にするTLVを定義します。
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]で説明されているように解釈されます。
We observe that, in order to allow for mixed use (i.e., some routers running BFD and some not), [RFC5882] does not require a BFD session be established prior to the establishment of an IS-IS adjacency. Thus, if a router A has neighbors B and C, and B does not support BFD, A would still form adjacencies with B and C, and it would only establish a BFD session with C.
混合使用を可能にするために（つまり、BFDを実行しているルーターと一部のルーター）、[RFC5882]はIS-IS隣接を確立する前にBFDセッションを確立する必要がないことを観察します。したがって、ルーターAに近隣BとCがあり、BがBFDをサポートしていない場合、Aは依然としてBとCの隣接を形成し、CとのBFDセッションのみを確立します。
The problem with this solution is that it assumes that the transmission and receipt of IS-IS Hellos (IIHs) shares fate with forwarded data packets. This is not a fair assumption to make given that the primary use of BFD is to protect IPv4 (and IPv6) forwarding, and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its hellos.
このソリューションの問題は、IS-IS Hellos（IIHS）の送信と受領が転送されたデータパケットと運命を共有することを前提としていることです。これは、BFDの主な使用がIPv4（およびIPv6）転送を保護することであり、IS-ISはHELLOSの送信または受信にIPv4またはIPv6を使用していないことを考えると、これは公正な仮定ではありません。
Thus, if we consider our previous example, and if C is currently experiencing an IPv4 forwarding failure that allows for IIHs to be sent and received, when A first starts (or restarts), A will assume that C simply does not support BFD, will form an adjacency with C, and may incorrectly forward IPv4 traffic through C.
したがって、前の例を検討し、Cが現在IIHを送信および受信できるIPv4転送障害を経験している場合、最初のスタート（または再起動）の場合、AはCがBFDをサポートしないと仮定します。Cの隣接を形成し、Cを介してIPv4トラフィックを誤って転送する可能性があります
A simple solution to this problem is for an IS-IS router to advertise that it has BFD enabled on a given interface. It can do this through the inclusion of a TLV in its IIHs as described in this document.
この問題の簡単な解決策は、IS-ISルーターが特定のインターフェイスでBFDが有効になっていることを宣伝することです。このドキュメントに記載されているように、IIHSにTLVを含めることでこれを行うことができます。
When sending an IIH on a BFD enabled interface, a router that supports this extension MUST include the BFD-enabled TLV in its IIH. The contents of the TLV MUST indicate what topologies/protocols [RFC5120] have been enabled for BFD by including the appropriate Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier (NLPID) pairs.
BFD対応インターフェイスでIIHを送信する場合、この拡張機能をサポートするルーターには、IIHにBFD対応のTLVを含める必要があります。TLVの内容は、適切なマルチトポロジ識別子（MTID）/ネットワークレイヤープロトコル識別子（NLPID）ペアを含めることにより、BFDに対してどのトポロジー/プロトコル[RFC5120]が有効になっているかを示す必要があります。
When sending an IIH on an interface on which BFD is NOT enabled, a router MUST NOT include the BFD-enabled TLV.
BFDが有効になっていないインターフェイスにIIHを送信する場合、ルーターはBFD対応のTLVを含めてはなりません。
The following definitions apply to each IS-IS neighbor:
次の定義は、それぞれのISネイバーに適用されます。
For each locally supported MTID/NLPID pair, an "ISIS_TOPO_NLPID_BFD_REQUIRED" variable is assigned. If BFD is supported by both the local system and the neighbor of the MTID/ NLPID, this variable is set to "TRUE". Otherwise, the variable is set to "FALSE".
ローカルでサポートされている各MTID/NLPIDペアに対して、「ISIS_TOPO_NLPID_BFD_REQUIRED」変数が割り当てられています。BFDがローカルシステムとMTID/ NLPIDの隣人の両方によってサポートされている場合、この変数は「true」に設定されています。それ以外の場合、変数は「false」に設定されます。
For each locally supported MTID, an "ISIS_TOPO_BFD_REQUIRED" variable is set to the logical "OR" of all "ISIS_TOPO_NLPID_BFD_REQUIRED" variables associated with that MTID.
ローカルでサポートされている各MTIDについて、「ISIS_TOPO_BFD_REQUIRED」変数は、すべての「ISIS_TOPO_NLPID_BFD_REQUIRED "変数の論理または「」に設定されます。
An "ISIS_BFD_REQUIRED" variable is set to the logical "AND" of all "ISIS_TOPO_BFD_REQUIRED" variables.
「ISIS_BFD_REQUIRED」変数は、すべての「ISIS_TOPO_BFD_REQUIRED」変数の論理に設定されています。
For each locally supported MTID/NLPID pair, an "ISIS_TOPO_NLPID_STATE" variable is assigned. If "ISIS_TOPO_NLPID_BFD_REQUIRED" is "TRUE", this variable follows the BFD session state for that MTID/NLPID ("UP == TRUE"). Otherwise, the variable is set to "TRUE".
ローカルでサポートされている各MTID/NLPIDペアについて、「ISIS_TOPO_NLPID_STATE」変数が割り当てられます。「isis_topo_nlpid_bfd_required」が「true」である場合、この変数はそのmtid/nlpid（ "up == true"）のBFDセッション状態に従います。それ以外の場合、変数は「true」に設定されています。
For each locally supported topology (MTID), an "ISIS_TOPO_USEABLE" variable is set to the logical "AND" of the set of "ISIS_TOPO_NLPID_STATE" variables associated with that MTID.
各ローカルサポートトポロジ（MTID）ごとに、「ISIS_TOPO_USABLE」変数は、そのMTIDに関連付けられた「ISIS_TOPO_NLPID_STATE」変数のセットの論理に設定されます。
An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all "ISIS_TOPO_USEABLE" variables.
「isis_neighbor_usable」変数は、すべての "isis_topo_usable"変数の論理 "または「"に設定されます。
Whenever "ISIS_BFD_REQUIRED" is "TRUE", the following extensions to the rules for adjacency establishment and maintenance MUST apply:
「ISIS_BFD_REQUIRED」が「真」である場合はいつでも、隣接する確立とメンテナンスのルールの次の拡張を適用する必要があります。
o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can transition from "INIT" to "UP" state.
o 「isis_neighbor_usable」は、隣接が「init」から「up」状態に移行する前に、「真の」でなければなりません。
o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE" becomes "FALSE", the IS-IS adjacency MUST transition to "DOWN".
o IS-ISの隣接が「上」であり、「ISIS_NEIGHBOR_USABERE」が「false」になると、IS-IS隣接は「ダウン」に移行する必要があります。
o On a Point-to-Point circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the Three-Way adjacency state MUST be set to "DOWN" in the Point-to-Point Three-Way Adjacency TLV [RFC5303] in all transmitted IIHs.
o 「isis_neighbor_usable」が「false」である場合は、ポイントツーポイントサーキットでは、3方向隣接状態を、すべての送信されたIIHでポイントツーポイント3ウェイ隣接TLV [RFC5303]で「ダウン」する必要があります。
o On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the IS Neighbors TLV advertising the Media Access Control (MAC) address of the neighbor MUST be omitted in all transmitted IIHs.
o 「isis_neighbor_usable」が「false」である場合はいつでもLAN回路で、IS Neighbors TLVは、メディアアクセス制御（MAC）をすべて送信されたすべてのIIHで省略する必要があります。
The advertisement of a topology-specific IS neighbor (as well as the use of the neighbor in the topology-specific decision process) is determined by the value of "ISIS_TOPO_USEABLE" for each topology. If "ISIS_TOPO_USEABLE" is "TRUE", then the topology-specific neighbor is advertised. If "ISIS_TOPO_USEABLE" is "FALSE", then the topology-specific neighbor is not advertised.
トポロジ固有の広告は隣人（およびトポロジ固有の決定プロセスでの隣人の使用）は、各トポロジの「isis_topo_usable」の値によって決定されます。「isis_topo_usable」が「真」である場合、トポロジ固有の隣人が宣伝されます。「isis_topo_usable」が「false」である場合、トポロジ固有の隣人は宣伝されません。
To allow for a non-disruptive transition to the use of BFD, some amount of time should be allowed before bringing down an "UP" adjacency on a BFD enabled interface when the value of "ISIS_BFD_REQUIRED" becomes "TRUE" as a result of the introduction of the BFD TLV or the modification (by adding a new supported MTID/ NLPID) of an existing BFD TLV in a neighbor's IIH. A simple way to do this is to not update the adjacency hold time when receiving such an IIH from a neighbor with whom we have an "UP" adjacency until "ISIS_NEIGHBOR_USEABLE" becomes "TRUE".
BFDの使用への非破壊的な移行を可能にするために、「ISIS_BFD_REQUIRED」の値が「真」になると、BFD対応インターフェイスに「アップ」隣接を倒す前に、ある程度の時間を許可する必要があります。隣人のIIHに既存のBFD TLVのBFD TLVまたは変更（新しいサポートされているMTID/ NLPIDを追加することによる）の導入。これを行う簡単な方法は、「ISIS_NEIGHBOR_USABLE」が「真」になるまで「アップ」隣接を持っている隣人からそのようなIIHを受け取るときに隣接保持時間を更新しないことです。
If the value of "ISIS_BFD_REQUIRED" becomes "FALSE" as a result of the removal the BFD TLV or the modification (by removing a supported MTID/NLPID) of an existing BFD TLV in a neighbor's IIH, then BFD session establishment is no longer required to maintain the adjacency or transition the adjacency to the "UP" state.
「ISIS_BFD_REQUIRED」の値が、BFD TLVまたは（サポートされているMTID/NLPIDを削除することにより）近隣のIIHの修正（サポートされているMTID/NLPIDを削除することにより）の結果として「false」になる場合、BFDセッションの確立はもはや必要ありません隣接または移行を維持するために、隣接は「上」状態になります。
If a BFD session is administratively shut down [RFC5880] and the BFD session state change impacts the value of "ISIS_NEIGHBOR_USEABLE", then IS-IS SHOULD allow time for the corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by not updating the adjacency hold time until "ISIS_BFD_REQUIRED" becomes "FALSE". Note that while this allows a non-disruptive transition, it still enforces consistency between the administrative state of the BFD session and the MTID/NLPID(s) advertised in the BFD TLV. This is necessary to provide consistent behavior regardless of whether the BFD AdminDown state is introduced before or after an IS-IS adjacency "UP" state has been achieved.
BFDセッションが管理上シャットダウンされ[RFC5880]、BFDセッションの状態の変更が「ISIS_NEIGHBOR_USABLE」の値に影響を与える場合、IS-ISは、対応するMTID/NLPIDが近隣のBFD TLVから削除されることを可能にするはずです。「ISIS_BFD_REQUIRED」が「false」になるまで、隣接時間を保持します。これにより、非破壊的な遷移が可能になりますが、BFDセッションの管理状態とBFD TLVで宣伝されているMTID/NLPID（S）の間の一貫性が依然として強制されることに注意してください。これは、IS-IS隣接する「アップ」状態が達成された前または後にBFD承認国家が導入されるかどうかに関係なく、一貫した動作を提供するために必要です。
This section describes IS-IS implementation considerations when both IS-IS graceful restart [RFC5306] and BFD are co-deployed.
このセクションでは、IS-I-I-ISの優雅な再起動[RFC5306]とBFDの両方が共同展開されている場合、IS-IS実装の考慮事項について説明します。
In cases where BFD shares fate with the control plane, it can be expected that BFD session failure may occur in conjunction with the control-plane restart. In such cases, premature abort of IS-IS graceful restart as a result of BFD session failure is undesirable. Therefore, some mechanism to ignore the BFD session failure for a limited period of time would be beneficial. The issue of the interaction between graceful restart and BFD is described at length in RFC 5882. The implementation of this interaction is outside the scope of this document.
BFDが制御プレーンと運命を共有している場合、BFDセッションの障害がコントロールプレーンの再起動と併せて発生する可能性があると予想されます。そのような場合、BFDセッションの故障の結果としてのIS-ISの優雅な再起動の早期中断は望ましくありません。したがって、限られた期間BFDセッションの障害を無視するメカニズムは有益です。優雅な再起動とBFDの間の相互作用の問題は、RFC 5882で詳細に説明されています。この相互作用の実装は、このドキュメントの範囲外です。
The BFD-enabled TLV is formatted as shown below. The TLV SHALL only be included in an IIH and only when BFD is enabled for one or more supported MTID/protocols on the interface over which the IIH is being sent. The NLPIDs encoded in the TLV are defined in [ISO9577].
BFD対応のTLVは、以下に示すようにフォーマットされています。TLVは、IIHにのみ含まれ、IIHが送信されているインターフェイス上の1つ以上のサポートされているMTID/プロトコルに対してBFDが有効になっている場合にのみ含まれます。TLVでエンコードされたNLPIDは[ISO9577]で定義されています。
Type 148 Length # of octets in the value field (3 to 255) Value 3 octets specifying the MTID/NLPID for each topology/data protocol for which BFD support is enabled
タイプ148値フィールドのオクテットの長さ＃値（3〜255）値3オクテットBFDサポートが有効になっている各トポロジ/データプロトコルのMTID/NLPIDを指定する
No. of octets
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
: :
: :
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
The TLV defined within this document describes an addition to the IS-IS Hello protocol. Inappropriate use of this TLV could prevent an IS-IS adjacency from forming or lead to failure to detect bidirectional forwarding failures -- each of which is a form of denial of service. However, a party who can manipulate the contents of this TLV is already in a position to create such a denial of service by disrupting IS-IS routing in other ways.
このドキュメント内で定義されているTLVは、IS-IS Helloプロトコルへの追加について説明しています。このTLVの不適切な使用は、IS-ISの隣接が形成されたり、双方向転送の障害を検出しなかったりするのを防ぐ可能性があります。それぞれがサービスの拒否の一形態です。ただし、このTLVの内容を操作できる当事者は、IS-ISルーティングを他の方法で混乱させることにより、このようなサービスの拒否を作成する立場にあります。
Note that the introduction of this TLV has no impact on the use/ non-use of authentication either by IS-IS or by BFD.
このTLVの導入は、IS-ISまたはBFDによる認証の使用/非使用に影響を与えないことに注意してください。
The following IS-IS TLV type is defined by this document.
次のIS-IS TLVタイプは、このドキュメントで定義されています。
Name Value IIH LSP SNP Purge
---------------------- ----- --- --- --- -----
BFD-Enabled TLV 148 y n n n
The IS-IS TLV Codepoint registry has been updated accordingly.
IS-IS TLV CodePointレジストリはそれに応じて更新されました。
The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz, Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett, and David Ward for various input on this document.
著者は、ジェフリー・ハース、マシュー・ジョーンズ、デイブ・カッツ、ジョナサン・ムーン、ステファノ・プレビディ、マイク・シャンド、マイケル・シップレット、デビッド・ワードに、この文書にさまざまな入力をしてくれたことに感謝します。
[ISO9577] International Organization for Standardization, "Protocol identification in the network layer(ISO/IEC 9577)", ISO/ IEC 9577:1999, Fourth Edition, December 1999.
[ISO9577]国際標準化機関、「ネットワーク層におけるプロトコル識別（ISO/ IEC 9577）」、ISO/ IEC 9577：1999、第4版、1999年12月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）中間システムのルーティング（MT）中間システム（IS-IS）、RFC 5120、2008年2月。
[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.
[RFC5303] Katz、D.、Saluja、R。、およびD. Eastlake、「IS-IS Point-to-Point隣接の3方向の握手」、RFC 5303、2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306] Shand、M。およびL. Ginsberg、「IS-ISの再起動信号」、RFC 5306、2008年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、2010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882] Katz、D。およびD. Ward、「双方向転送検出の一般的な応用（BFD）」、RFC 5882、2010年6月。
Authors' Addresses
著者のアドレス
Christian E. Hopps Cisco Systems 170 W. Tasman Dr. San Jose, California 95134 USA EMail: chopps@cisco.com
Christian E. Hopps Cisco Systems 170 W. Tasman Dr. San Jose、California 95134 USAメール：chupps@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, California 95035 USA EMail: ginsberg@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd.カリフォルニア州ミルピタス95035 USAメール：ginsberg@cisco.com