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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の一つの特定のアプリケーションは、転送能力を検証することである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]を可能にするために、BFDセッションが前IS-IS隣接関係の確立に確立することを必要としない、ことを観察します。このように、ルータ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はhelloメッセージ（IIHS）の株式の運命の送受信。これは、BFDの主な用途は、IPv4（およびIPv6）の転送を保護するためであることを考えると作るために公正な仮定ではなく、IS-ISが送信またはそのhelloを受信するための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は現在、IIHSが送受信されるのを可能に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.
この問題の簡単な解決策は、それがBFD特定のインターフェイス上で有効になっていることを宣伝するためのルータISは、ISのためです。この文書で説明したように、それはその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の内容がどのようなトポロジ/プロトコル[RFC5120]を示さなければなりません適切なマルチトポロジ識別子（MTID）/ネットワーク層プロトコル識別子（NLPID）対を含むことにより、BFDのために有効にされています。
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」変数はそのMTIDに関連付けられているすべての「ISIS_TOPO_NLPID_BFD_REQUIRED」変数の論理「OR」に設定されています。
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」変数の論理「AND」に設定されています。
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_USEABLE」変数は、そのMTIDに関連する「ISIS_TOPO_NLPID_STATE」変数のセットの論理「AND」に設定されています。
An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all "ISIS_TOPO_USEABLE" variables.
「ISIS_NEIGHBOR_USEABLE」変数はすべて「ISIS_TOPO_USEABLE」変数の論理「OR」に設定されています。
Whenever "ISIS_BFD_REQUIRED" is "TRUE", the following extensions to the rules for adjacency establishment and maintenance MUST apply:
「ISIS_BFD_REQUIRED」は「TRUE」であるときはいつでも、隣接関係の確立と維持のための規則に次の拡張機能は、適用する必要があります。
o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can transition from "INIT" to "UP" state.
隣接関係が「UP」状態に「INIT」から移行することができる前にO「ISIS_NEIGHBOR_USEABLE」が「TRUE」でなければなりません。
o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE" becomes "FALSE", the IS-IS adjacency MUST transition to "DOWN".
隣接であるが、ある場合にO "UP" であり、 "ISIS_NEIGHBOR_USEABLE" IS-IS隣接関係が "DOWN" に遷移しなければならない、 "FALSE" となります。
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.
○「ISIS_NEIGHBOR_USEABLE」が「FALSE」であるときはいつでもポイントツーポイント回路上に、三方隣接状態は、全ての送信IIHSでポイントツーポイントスリーウェイ隣接TLV [RFC5303]で「DOWN」に設定しなければなりません。
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_USEABLE」は「FALSE」である時はいつでもLAN回路では、ISの隣人が隣人のメディアアクセス制御（MAC）アドレスを広告するTLVがすべて送信IIHSに省略しなければなりません。
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_USEABLE」の値によって決定されます。 「ISIS_TOPO_USEABLE」は「TRUE」である場合には、トポロジ固有の隣人がアドバタイズされます。 「ISIS_TOPO_USEABLE」は「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」の値が「TRUE」になったときの結果としてBFD有効インターフェースの「UP」隣接関係をダウンさせる前に、許容されるべきです隣人のIIHにある既存のBFD TLVの（新しいサポートMTID / NLPIDを追加することによって）BFD TLVまたは変更の導入。これを行うための簡単な方法は、「ISIS_NEIGHBOR_USEABLEは」「TRUE」になるまで、我々は「UP」の隣接関係を持っている人と隣人からそのような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」の値が隣人のIIHに既存のBFD TLVの（サポートMTID / NLPIDを取り除くことによって）除去BFD TLVや変更の結果として、「FALSE」になると、BFDセッションの確立が不要になりました隣接関係を維持するか、または「UP」状態に隣接関係を遷移させます。
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_USEABLE」の値をシャットダウンされている場合、-ISは、IS対応MTID / NLPIDのための時間が更新されないことにより、ネイバーのBFD TLVから削除できるようにするべきです「ISIS_BFD_REQUIRED」は「FALSE」になるまでの隣接関係は時間を保持します。この無停止の移行を可能にするが、それはまだBFDセッションの管理状態とBFD TLVでアドバタイズMTID / NLPID（S）との間の整合性を強制することに留意されたいです。これは関係なく、BFD AdminDown状態が前またはIS-IS隣接関係「UP」状態が達成された後に導入されているかどうかの一貫性のある動作を提供することが必要です。
This section describes IS-IS implementation considerations when both IS-IS graceful restart [RFC5306] and BFD are co-deployed.
このセクションでは、両方の時にグレースフルリスタート[RFC5306]とBFDが共同展開しているIS-ISの実装の考慮事項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に含まれるものとBFDはIIHが送信されているインターフェイス上の一つ以上のサポートMTID /プロトコルが有効になっている場合にのみ。 TLVでエンコードNLPIDsは[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
BFDサポートが有効になっている各トポロジー/データプロトコル用MTID / NLPIDを指定する値フィールドのオクテットの長さ148の＃を入力し（3から255）値3つのオクテット
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は、HelloプロトコルIS-ISへの追加を説明しています。サービス拒否の形態でそれぞれが - この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コードポイントレジストリが更新されました。
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.
作者はこのドキュメント上のさまざまな入力のためのジェフリー・ハース、マシュー・ジョーンズ、デイブ・カッツ、ジョナサン・ムーン、ステファノPrevidi、マイク・シャンド、マイケルShiplett、とDavidウォードに感謝したいです。
[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.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、シェン、N。、およびN. Shethは、 "M-ISIS：中間システムへの中間システムにおけるマルチトポロジー（MT）ルーティング（IS-ISS）"、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]カッツ、D.、Saluja、R.、およびD.イーストレイク、 "IS-ISポイントツーポイント隣接関係のためのスリーウェイハンドシェイク"、RFC 5303、2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306]シャンド、M.およびL.ギンズバーグ、 "IS-ISのための再起動シグナリング"、RFC 5306、2008年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]カッツ、D.およびD.区、 "双方向フォワーディング検出（BFD）"、RFC 5880、2010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882]カッツ、D.およびD.区、 "双方向フォワーディング検出（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
クリスチャン・E. Hoppsがシスコシステムズ170 W.タスマン博士は、カリフォルニア州サンノゼ95134 USA電子メール：chopps@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, California 95035 USA EMail: ginsberg@cisco.com
レ・ギンズバーグシスコシステムズ510マッカーシーブルバードミルピタス、カリフォルニア95035 USA Eメール：ginsberg@cisco.com