[要約] RFC 5882は、双方向転送検出（BFD）の一般的な応用に関するものであり、ネットワークデバイス間のリンクの状態を監視するためのプロトコルを提供します。目的は、高速で信頼性の高いリンク障害検出を実現し、ネットワークの可用性を向上させることです。
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5882 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Generic Application of Bidirectional Forwarding Detection (BFD)
双方向転送検出（BFD）の一般的な適用
Abstract
概要
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol.
このドキュメントでは、双方向転送検出（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/rfc5882.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5882で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Overview ........................................................3
3. Basic Interaction between BFD Sessions and Clients ..............4
3.1. Session State Hysteresis ...................................4
3.2. AdminDown State ............................................5
3.3. Hitless Establishment/Reestablishment of BFD State .........5
4. Control Protocol Interactions ...................................6
4.1. Adjacency Establishment ....................................6
4.2. Reaction to BFD Session State Changes ......................7
4.2.1. Control Protocols with a Single Data Protocol .......7
4.2.2. Control Protocols with Multiple Data Protocols ......8
4.3. Interactions with Graceful Restart Mechanisms ..............8
4.3.1. BFD Fate Independent of the Control Plane ...........9
4.3.2. BFD Shares Fate with the Control Plane ..............9
4.4. Interactions with Multiple Control Protocols ..............10
5. Interactions with Non-Protocol Functions .......................10
6. Data Protocols and Demultiplexing ..............................11
7. Multiple Link Subnetworks ......................................11
7.1. Complete Decoupling .......................................12
7.2. Layer N-1 Hints ...........................................12
7.3. Aggregating BFD Sessions ..................................12
7.4. Combinations of Scenarios .................................12
8. Other Application Issues .......................................13
9. Interoperability Issues ........................................13
10. Specific Protocol Interactions (Non-Normative) ................13
10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS ..........14
10.1.1. Session Establishment .............................14
10.1.2. Reaction to BFD State Changes .....................14
10.1.3. OSPF Virtual Links ................................15
10.2. Interactions with BGP ....................................15
10.3. Interactions with RIP ....................................15
11. Security Considerations .......................................16
12. References ....................................................16
12.1. Normative References .....................................16
12.2. Informative References ...................................16
The Bidirectional Forwarding Detection [BFD] protocol provides a liveness detection mechanism that can be utilized by other network components for which their integral liveness mechanisms are either too slow, inappropriate, or nonexistent. Other documents have detailed the use of BFD with specific encapsulations ([BFD-1HOP] [BFD-MULTI] [BFD-MPLS]). As the utility of BFD has become understood, there have been calls to specify BFD interactions with a growing list of network functions. Rather than producing a long series of short documents on the application of BFD, it seemed worthwhile to describe the interactions between BFD and other network functions ("BFD clients") in a broad way.
双方向転送検出[BFD]プロトコルは、その積分快適さのメカニズムが遅すぎる、不適切、または存在のいずれかである他のネットワークコンポーネントによって利用できるlivenives検出メカニズムを提供します。他のドキュメントでは、特定のカプセル（[BFD-1HOP] [BFD-Multi] [BFD-MPLS]）を使用したBFDの使用について詳しく説明しています。BFDの有用性が理解されるようになるにつれて、ネットワーク関数の増加リストとBFD相互作用を指定する呼び出しがありました。BFDの適用に関する長いシリーズの短いドキュメントを作成するのではなく、BFDと他のネットワーク関数（「BFDクライアント」）との相互作用を広範な方法で説明する価値があると思われました。
This document describes the generic application of BFD. Specific protocol applications are provided for illustrative purposes.
このドキュメントでは、BFDの一般的なアプリケーションについて説明します。特定のプロトコルアプリケーションは、例示的な目的で提供されます。
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 [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているように解釈されます。
The Bidirectional Forwarding Detection (BFD) specification defines a protocol with simple and specific semantics. Its sole purpose is to verify connectivity between a pair of systems, for a particular data protocol across a path (which may be of any technology, length, or OSI layer). The promptness of the detection of a path failure can be controlled by trading off protocol overhead and system load with detection times.
双方向転送検出（BFD）仕様は、単純で特定のセマンティクスを持つプロトコルを定義します。その唯一の目的は、パスを越えた特定のデータプロトコル（これはあらゆる技術、長さ、またはOSI層の場合がある）のペア間の接続性を検証することです。パス障害の検出の迅速性は、プロトコルオーバーヘッドと検出時間とのシステム負荷を取引することで制御できます。
BFD is *not* intended to directly provide control protocol liveness information; those protocols have their own means and vagaries. Rather, control protocols can use the services provided by BFD to inform their operation. BFD can be viewed as a service provided by the layer in which it is running.
BFDは、コントロールプロトコルの活性情報を直接提供することを意図していません。これらのプロトコルには、独自の手段と気まぐれがあります。むしろ、コントロールプロトコルは、BFDが提供するサービスを使用して運用を通知することができます。BFDは、実行中のレイヤーによって提供されるサービスとして見ることができます。
The service interface with BFD is straightforward. The application supplies session parameters (neighbor address, time parameters, protocol options), and BFD provides the session state, of which the most interesting transitions are to and from the Up state. The application is expected to bootstrap the BFD session, as BFD has no discovery mechanism.
BFDとのサービスインターフェイスは簡単です。アプリケーションは、セッションパラメーター（隣接アドレス、時間パラメーター、プロトコルオプション）を提供し、BFDはセッション状態を提供します。BFDには発見メカニズムがないため、アプリケーションはBFDセッションをブートストラップする予定です。
An implementation SHOULD establish only a single BFD session per data protocol path, regardless of the number of applications that wish to utilize it. There is no additional value in having multiple BFD sessions to the same endpoints. If multiple applications request different session parameters, it is a local issue as to how to resolve the parameter conflicts. BFD in turn will notify all applications bound to a session when a session state change occurs.
実装は、それを利用したいアプリケーションの数に関係なく、データプロトコルパスごとに単一のBFDセッションのみを確立する必要があります。同じエンドポイントに複数のBFDセッションを持つことには、追加の価値はありません。複数のアプリケーションが異なるセッションパラメーターを要求する場合、パラメーターの競合を解決する方法に関するローカルな問題です。BFDは、セッション状態の変更が発生したときにセッションにバインドされたすべてのアプリケーションに通知します。
BFD should be viewed as having an advisory role to the protocol or protocols or other network functions with which it is interacting, which will then use their own mechanisms to effect any state transitions. The interaction is very much at arm's length, which keeps things simple and decoupled. In particular, BFD explicitly does not carry application-specific information, partly for architectural reasons and partly because BFD may have curious and unpredictable latency characteristics and as such makes a poor transport mechanism.
BFDは、プロトコルまたはプロトコル、または相互作用している他のネットワーク関数に対してアドバイザリーの役割を持っていると見なされるべきであり、それが独自のメカニズムを使用して状態遷移に影響を与える。相互作用は非常に腕の長さであり、物事をシンプルで分離します。特に、BFDは、一部は建築上の理由で、BFDが好奇心が強く予測不可能なレイテンシ特性を持っている可能性があるため、輸送メカニズムが不十分である可能性があるため、アプリケーション固有の情報を明示的に保持していません。
It is important to remember that the interaction between BFD and its client applications has essentially no interoperability issues, because BFD is acting in an advisory nature (similar to hardware signaling the loss of light on a fiber optic circuit, for example) and existing mechanisms in the client applications are used in reaction to BFD events. In fact, BFD may interact with only one of a pair of systems for a particular client application without any ill effect.
BFDがアドバイザリーの性質で作用しているため（たとえば、光ファイバー回路の光の損失を示すハードウェアと同様）、および既存のメカニズムの既存のメカニズムであるため、BFDとそのクライアントアプリケーション間の相互作用には基本的に相互運用性の問題はないことを覚えておくことが重要です。クライアントアプリケーションは、BFDイベントに反応して使用されます。実際、BFDは、悪影響を及ぼさずに特定のクライアントアプリケーションのペアのシステムの1つのみと相互作用する場合があります。
The interaction between a BFD session and its associated client applications is, for the most part, an implementation issue that is outside the scope of this specification. However, it is useful to describe some mechanisms that implementors may use in order to promote full-featured implementations. One way of modeling this interaction is to create an adaptation layer between the BFD state machine and the client applications. The adaptation layer is cognizant of both the internals of the BFD implementation and the requirements of the clients.
BFDセッションとそれに関連するクライアントアプリケーションとの相互作用は、ほとんどの場合、この仕様の範囲外の実装問題です。ただし、フル機能の実装を促進するために、実装者が使用できるメカニズムを説明することは便利です。この相互作用をモデル化する1つの方法は、BFDステートマシンとクライアントアプリケーションの間に適応レイヤーを作成することです。適応層は、BFD実装の内部とクライアントの要件の両方を認識しています。
A BFD session can be tightly coupled to its client applications; for example, any transition out of the Up state could cause signaling to the clients to take failure action. However, in some cases, this may not always be the best course of action.
BFDセッションは、クライアントアプリケーションにしっかりと結合できます。たとえば、UP状態からの移行は、クライアントへの信号が失敗アクションを実行する可能性があります。ただし、場合によっては、これが必ずしも最良の行動方針とは限りません。
Implementors may choose to hide rapid Up/Down/Up transitions of the BFD session from its clients. This is useful in order to support process restarts without necessitating complex protocol mechanisms, for example.
実装者は、BFDセッションの迅速なアップ/ダウン/アップトランジションをクライアントから隠すことを選択できます。これは、たとえば、複雑なプロトコルメカニズムを必要とせずにプロセスの再起動をサポートするために役立ちます。
As such, a system MAY choose not to notify clients if a BFD session transitions from Up to Down state, and returns to Up state, if it does so within a reasonable period of time (the length of which is outside the scope of this specification). If the BFD session does not return to Up state within that time frame, the clients SHOULD be notified that a session failure has occurred.
そのため、システムは、BFDセッションがアップ状態からダウン状態に移行し、合理的な期間内にそうする場合（その長さがこの仕様の範囲外である場合、UP状態に戻る場合、クライアントに通知しないことを選択できます。）。BFDセッションがその時間枠内でUP状態に戻らない場合、クライアントはセッションの失敗が発生したことを通知する必要があります。
The AdminDown mechanism in BFD is intended to signal that the BFD session is being taken down for administrative purposes, and the session state is not indicative of the liveness of the data path.
BFDの承認メカニズムは、BFDセッションが管理目的で削除されていることを示すことを目的としており、セッション状態はデータパスの活性を示すものではありません。
Therefore, a system SHOULD NOT indicate a connectivity failure to a client if either the local session state or the remote session state (if known) transitions to AdminDown, so long as that client has independent means of liveness detection (typically, control protocols).
したがって、システムは、ローカルセッション状態またはリモートセッション状態（既知の場合）が承認に移行する場合、クライアントへの接続障害を示すべきではありません。
If a client does not have any independent means of liveness detection, a system SHOULD indicate a connectivity failure to a client, and assume the semantics of Down state, if either the local or remote session state transitions to AdminDown. Otherwise, the client will not be able to determine whether the path is viable, and unfortunate results may occur.
クライアントがlivensionの検出の独立した手段を持っていない場合、システムはクライアントへの接続障害を示し、ローカルまたはリモートのセッション状態が承認される場合、ダウン状態のセマンティクスを想定する必要があります。それ以外の場合、クライアントはパスが実行可能かどうかを判断できず、不幸な結果が発生する可能性があります。
It is useful to be able to configure a BFD session between a pair of systems without impacting the state of any clients that will be associated with that session. Similarly, it is useful for BFD state to be reestablished without perturbing associated clients when all BFD state is lost (such as in process restart situations). This interacts with the clients' ability to establish their state independent of BFD.
そのセッションに関連付けられるクライアントの状態に影響を与えることなく、一対のシステム間でBFDセッションを構成できると便利です。同様に、BFD状態は、すべてのBFD状態が失われた場合（プロセス再起動状況など）、関連するクライアントを混乱させることなく再確立されることが役立ちます。これは、BFDから独立した州を確立するクライアントの能力と相互作用します。
The BFD state machine transitions that occur in the process of bringing up a BFD session in such situations SHOULD NOT cause a connectivity failure notification to the clients.
このような状況でBFDセッションを持ち上げる過程で発生するBFD状態マシンの遷移は、クライアントに接続障害通知を引き起こすことはありません。
A client that is capable of establishing its state prior to the configuration or restarting of a BFD session MAY do so if appropriate. The means to do so is outside of the scope of this specification.
BFDセッションの構成または再起動の前に状態を確立できるクライアントは、必要に応じてそうすることができます。そうする手段は、この仕様の範囲外です。
Very common client applications of BFD are control protocols, such as routing protocols. The object, when BFD interacts with a control protocol, is to advise the control protocol of the connectivity of the data protocol. In the case of routing protocols, for example, this allows the connectivity failure to trigger the rerouting of traffic around the failed path more quickly than the native detection mechanisms.
BFDの非常に一般的なクライアントアプリケーションは、ルーティングプロトコルなどの制御プロトコルです。オブジェクトは、BFDが制御プロトコルと対話する場合、データプロトコルの接続性の制御プロトコルにアドバイスすることです。たとえば、ルーティングプロトコルの場合、これにより、接続の失敗がネイティブ検出メカニズムよりも迅速に失敗したパス周辺のトラフィックの再ルーティングをトリガーできます。
If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed.
ローカルシステムまたはリモートシステム（既知の場合）のいずれかのセッションが承認されている場合、BFDは管理上無効にされており、制御プロトコルの隣接性の確立を許可する必要があります。
BFD sessions are typically bootstrapped by the control protocol, using the mechanism (discovery, configuration) used by the control protocol to find neighbors. Note that it is possible in some failure scenarios for the network to be in a state such that the control protocol is capable of coming up, but the BFD session cannot be established, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficial not to allow the control protocol to establish a neighbor adjacency. However, this would preclude the operation of the control protocol in an environment in which not all systems support BFD.
BFDセッションは通常、コントロールプロトコル（発見、構成）を使用して近隣を見つけるために使用されるメカニズム（発見、構成）を使用して、制御プロトコルによってブートストラップされます。コントロールプロトコルが登場することができるように、ネットワークが状態にあることが可能であるが、BFDセッションを確立することができず、特にデータを転送することはできないことに注意してください。この状況を回避するために、制御プロトコルが近隣の隣接を確立することを許可しないことは有益です。ただし、これにより、すべてのシステムがBFDをサポートしていない環境での制御プロトコルの動作が妨げられます。
Therefore, the establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. One method for determining that both systems are willing to establish a BFD session is if the control protocol carries explicit signaling of this fact. If there is no explicit signaling, the willingness to establish a BFD session may be determined by means outside the scope of this specification.
したがって、両方のシステムがBFDセッションを確立する意思があるが、BFDセッションを確立できない場合、制御プロトコルの隣接の確立をブロックする必要があります。両方のシステムがBFDセッションを確立する意思があると判断する1つの方法は、制御プロトコルがこの事実の明示的なシグナル伝達を運ぶ場合です。明示的なシグナル伝達がない場合、BFDセッションを確立する意欲は、この仕様の範囲外の手段によって決定される場合があります。
If it is believed that the neighboring system does not support BFD, the establishment of a control protocol adjacency SHOULD NOT be blocked.
隣接システムがBFDをサポートしていないと考えられている場合、制御プロトコル隣接の確立はブロックされるべきではありません。
The setting of BFD's various timing parameters and modes are not subject to standardization. Note that all protocols sharing a session will operate using the same parameters. The mechanism for choosing the parameters among those desired by the various protocols is outside the scope of this specification. It is generally useful to choose the parameters resulting in the shortest Detection Time; a particular client application can always apply hysteresis to the notifications from BFD if it desires longer Detection Times.
BFDのさまざまなタイミングパラメーターとモードの設定は、標準化の対象ではありません。セッションを共有するすべてのプロトコルは、同じパラメーターを使用して動作することに注意してください。さまざまなプロトコルによって望ましいパラメーターの中からパラメーターを選択するメカニズムは、この仕様の範囲外です。一般的に、最も短い検出時間を得るパラメーターを選択すると便利です。特定のクライアントアプリケーションは、より長い検出時間が必要な場合、BFDからの通知にヒステリシスを常に適用できます。
Note that many control protocols assume full connectivity between all systems on multiaccess media such as LANs. If BFD is running on only a subset of systems on such a network, and adjacency establishment is blocked by the absence of a BFD session, the assumptions of the control protocol may be violated, with unpredictable results.
多くのコントロールプロトコルは、LANSなどのマルチアクセスメディア上のすべてのシステム間の完全な接続性を想定していることに注意してください。このようなネットワーク上のシステムのサブセットのみでBFDが実行され、隣接施設がBFDセッションの欠如によってブロックされている場合、制御プロトコルの仮定に違反し、予測不可能な結果が得られます。
If a BFD session transitions from Up state to AdminDown, or the session transitions from Up to Down because the remote system is indicating that the session is in state AdminDown, clients SHOULD NOT take any control protocol action.
BFDセッションがUP状態から承認への移行、またはリモートシステムがセッションが州の承認者であることを示しているため、UPからダウンへのセッションの移行の場合、クライアントは制御プロトコルアクションを取るべきではありません。
For other transitions from Up to Down state, the mechanism by which the control protocol reacts to a path failure signaled by BFD depends on the capabilities of the protocol, as specified in the following subsections.
上から下までの他の遷移の場合、コントロールプロトコルがBFDによってシグナル化されたパス障害に反応するメカニズムは、以下のサブセクションで指定されているように、プロトコルの機能に依存します。
A control protocol that is tightly bound to a single failing data protocol SHOULD take action to ensure that data traffic is no longer directed to the failing path. Note that this should not be interpreted as BFD replacing the control protocol liveness mechanism, if any, as the control protocol may rely on mechanisms not verified by BFD (multicast, for instance) so BFD most likely cannot detect all failures that would impact the control protocol. However, a control protocol MAY choose to use BFD session state information to more rapidly detect an impending control protocol failure, particularly if the control protocol operates in-band (over the data protocol).
単一の障害データプロトコルにしっかりとバインドされている制御プロトコルは、データトラフィックが故障パスに向けられなくなったことを確認するためにアクションを実行する必要があります。制御プロトコルはBFD（たとえばマルチキャスト）によって検証されていないメカニズムに依存している可能性があるため、これは制御プロトコルのlivensionメカニズムに置き換えるBFDとして解釈すべきではないことに注意してください。プロトコル。ただし、制御プロトコルは、特に制御プロトコルが帯域内（データプロトコルを介して）を動作させる場合、BFDセッションの状態情報を使用して、差し迫った制御プロトコル障害をより迅速に検出することを選択できます。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path over which BFD is running. If the control protocol has an explicit mechanism for announcing path state, a system SHOULD use that mechanism rather than impacting the connectivity of the control protocol, particularly if the control protocol operates out-of-band from the failed data protocol. However, if such a mechanism is not available, a control protocol timeout SHOULD be emulated for the associated neighbor.
したがって、BFDセッションが上から下に移行する場合、制御プロトコルでアクションを実行して、BFDが実行されているパスの接続の欠如を示すようにする必要があります。制御プロトコルにPATH状態を発表するための明示的なメカニズムがある場合、システムは、特に制御プロトコルが故障したデータプロトコルからバンド外で動作する場合、制御プロトコルの接続に影響を与えるのではなく、そのメカニズムを使用する必要があります。ただし、そのようなメカニズムが利用できない場合は、関連する隣接に対して制御プロトコルタイムアウトをエミュレートする必要があります。
Slightly different mechanisms are used if the control protocol supports the routing of multiple data protocols, depending on whether the control protocol supports separate topologies for each data protocol.
制御プロトコルが各データプロトコルの個別のトポロジーをサポートするかどうかに応じて、制御プロトコルが複数のデータプロトコルのルーティングをサポートする場合、わずかに異なるメカニズムが使用されます。
With a shared topology, if one of the data protocols fails (as signaled by the associated BFD session), it is necessary to consider the path to have failed for all data protocols. Otherwise, there is no way for the control protocol to turn away traffic for the failed data protocol (and such traffic would be black-holed indefinitely).
共有トポロジを使用すると、データプロトコルの1つが失敗した場合（関連するBFDセッションで知られているように）、すべてのデータプロトコルで失敗したパスを考慮する必要があります。それ以外の場合、制御プロトコルが故障したデータプロトコルのトラフィックを排除する方法はありません（そして、そのようなトラフィックは無期限にブラックホールになります）。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology corresponding to the BFD session. If this cannot be signaled otherwise, a control protocol timeout SHOULD be emulated for the associated neighbor.
したがって、BFDセッションが上から下に移行する場合、制御プロトコルでアクションを実行して、BFDセッションに対応するトポロジのパスの接続性の欠如を示す必要があります。これを特に知らせない場合は、関連する隣接に対して制御プロトコルタイムアウトをエミュレートする必要があります。
With individual routing topologies for each data protocol, only the failed data protocol needs to be rerouted around the failed path.
各データプロトコルの個々のルーティングトポロジーを使用すると、失敗したデータプロトコルのみを失敗したパスの周りで再ルーティングする必要があります。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology over which BFD is running. Generally, this can be done without impacting the connectivity of other topologies (since otherwise it is very difficult to support separate topologies for multiple data protocols).
したがって、BFDセッションが上から下に移行する場合、制御プロトコルでアクションを実行して、BFDが実行されているトポロジのパスの接続性の欠如を示すようにアクションを実行する必要があります。一般に、これは他のトポロジーの接続に影響を与えることなく実行できます（それ以外の場合は、複数のデータプロトコルの個別のトポロジーをサポートすることは非常に困難です）。
A number of control protocols support Graceful Restart mechanisms, including IS-IS [ISIS-GRACE], OSPF [OSPF-GRACE], and BGP [BGP-GRACE]. These mechanisms are designed to allow a control protocol to restart without perturbing network connectivity state (lest it appear that the system and/or all of its links had failed). They are predicated on the existence of a separate forwarding plane that does not necessarily share fate with the control plane in which the routing protocols operate. In particular, the assumption is that the forwarding plane can continue to function while the protocols restart and sort things out.
多くの制御プロトコルは、IS [ISIS-grace]、OSPF [OSPF-grace]、BGP [BGP-grace]を含む優雅な再起動メカニズムをサポートしています。これらのメカニズムは、コントロールプロトコルがネットワーク接続状態を摂動せずに再起動できるように設計されています（システムおよび/またはすべてのリンクが失敗したように見えないように）。それらは、ルーティングプロトコルが動作するコントロールプレーンと必ずしも運命を共有するわけではない、個別の転送面の存在に基づいています。特に、プロトコルが再起動して物事を整理する間、転送面は機能し続けることができるという仮定です。
BFD implementations announce via the Control Plane Independent "C" bit whether or not BFD shares fate with the control plane. This information is used to determine the actions to be taken in conjunction with Graceful Restart. If BFD does not share its fate with the control plane on either system, it can be used to determine whether Graceful Restart in a control protocol is NOT viable (the forwarding plane is not operating).
BFDの実装は、コントロールプレーンの独立した「C」ビットを介して、BFDがコントロールプレーンと運命を共有するかどうかを発表します。この情報は、優雅な再起動と組み合わせて行われるアクションを決定するために使用されます。BFDがどちらのシステムでもコントロールプレーンと運命を共有しない場合、コントロールプロトコルの優雅な再起動が実行不可能かどうかを判断するために使用できます（転送面は動作していません）。
If the control protocol has a Graceful Restart mechanism, BFD may be used in conjunction with this mechanism. The interaction between BFD and the control protocol depends on the capabilities of the control protocol and whether or not BFD shares fate with the control plane. In particular, it may be desirable for a BFD session failure to abort the Graceful Restart process and allow the failure to be visible to the network.
制御プロトコルに優雅な再起動メカニズムがある場合、BFDはこのメカニズムと組み合わせて使用できます。BFDと制御プロトコル間の相互作用は、制御プロトコルの機能と、BFDが制御プレーンと運命を共有するかどうかに依存します。特に、BFDセッションが優雅な再起動プロセスを中止し、ネットワークに表示されないことを可能にすることが望ましい場合があります。
If BFD is implemented in the forwarding plane and does not share fate with the control plane on either system (the "C" bit is set in the BFD Control packets in both directions), control protocol restarts should not affect the BFD session. In this case, a BFD session failure implies that data can no longer be forwarded, so any Graceful Restart in progress at the time of the BFD session failure SHOULD be aborted in order to avoid black holes, and a topology change SHOULD be signaled in the control protocol.
BFDが転送面に実装されており、いずれかのシステム（「C」ビットは両方向のBFDコントロールパケットに設定されている）の制御面と運命を共有しない場合、コントロールプロトコルの再起動はBFDセッションに影響しないはずです。この場合、BFDセッションの障害は、データを転送できなくなることを意味するため、ブラックホールを避けるためにBFDセッションの障害時に進行中の優雅な再起動は中止する必要があり、トポロジの変化を示す必要があります。制御プロトコル。
If BFD shares fate with the control plane on either system (the "C" bit is clear in either direction), a BFD session failure cannot be disentangled from other events taking place in the control plane. In many cases, the BFD session will fail as a side effect of the restart taking place. As such, it would be best to avoid aborting any Graceful Restart taking place, if possible (since otherwise BFD and Graceful Restart cannot coexist).
BFDがいずれかのシステムでコントロールプレーンと運命を共有している場合（「C」ビットはどちらの方向でもはっきりしていません）、BFDセッションの障害は、コントロールプレーンで行われている他のイベントから解き放つことはできません。多くの場合、BFDセッションは、再起動の副作用として失敗します。そのため、可能であれば、優雅な再起動を中止することを避けることが最善です（そうでなければBFDと優雅な再起動は共存できません）。
There is some risk in doing so, since a simultaneous failure or restart of the forwarding plane will not be detected, but this is always an issue when BFD shares fate with the control plane.
転送面の同時障害または再起動は検出されないため、ある程度のリスクがありますが、これはBFDが制御プレーンと運命を共有する場合は常に問題です。
Some control protocols can signal a planned restart prior to the restart taking place. In this case, if a BFD session failure occurs during the restart, such a planned restart SHOULD NOT be aborted and the session failure SHOULD NOT result in a topology change being signaled in the control protocol.
一部のコントロールプロトコルは、再起動する前に計画された再起動を信号することができます。この場合、再起動中にBFDセッションの障害が発生した場合、そのような計画された再起動は中止されるべきではなく、セッションの障害により、コントロールプロトコルでトポロジの変更が示されるべきではありません。
Control protocols that cannot signal a planned restart depend on the recently restarted system to signal the Graceful Restart prior to the control protocol adjacency timeout. In most cases, whether the restart is planned or unplanned, it is likely that the BFD session will time out prior to the onset of Graceful Restart, in which case a topology change SHOULD be signaled in the control protocol as specified in Section 3.2.
計画された再起動を通知できないコントロールプロトコルは、最近再起動したシステムに依存して、制御プロトコル隣接タイムアウトの前に優雅な再起動を通知します。ほとんどの場合、再起動が計画されているか予定外であろうと、BFDセッションは優雅な再起動の開始前にタイムアウトする可能性があります。
However, if the restart is in fact planned, an implementation MAY adjust the BFD session timing parameters prior to restarting in such a way that the Detection Time in each direction is longer than the restart period of the control protocol, providing the restarting system the same opportunity to enter Graceful Restart as it would have without BFD. The restarting system SHOULD NOT send any BFD Control packets until there is a high likelihood that its neighbors know a Graceful Restart is taking place, as the first BFD Control packet will cause the BFD session to fail.
ただし、再起動が実際に計画されている場合、実装は、各方向の検出時間が制御プロトコルの再起動期間よりも長くなるように再起動する前にBFDセッションタイミングパラメーターを調整し、再起動システムに同じように提供する場合があります。BFDなしであるように優雅な再起動を入力する機会。最初のBFDコントロールパケットがBFDセッションを失敗させるため、隣人が優雅な再起動が行われていることを知っているという高い可能性が高くなるまで、再起動システムはBFDコントロールパケットを送信してはなりません。
If multiple control protocols wish to establish BFD sessions with the same remote system for the same data protocol, all MUST share a single BFD session.
複数の制御プロトコルが同じデータプロトコルに対して同じリモートシステムでBFDセッションを確立したい場合、すべてが単一のBFDセッションを共有する必要があります。
If hierarchical or dependent layers of control protocols are in use (say, OSPF and Internal BGP (IBGP)), it may not be useful for more than one of them to interact with BFD. In this example, because IBGP is dependent on OSPF for its routing information, the faster failure detection relayed to IBGP may actually be detrimental. The cost of a peer state transition is high in BGP, and OSPF will naturally heal the path through the network if it were to receive the failure detection.
制御プロトコルの階層層または従属層が使用されている場合（たとえば、OSPFおよび内部BGP（IBGP））、それらの2つ以上がBFDと相互作用することは役に立たないかもしれません。この例では、IBGPはルーティング情報に対してOSPFに依存しているため、IBGPにリレーされたより速い障害検出は実際に有害である可能性があります。BGPではピアステートトランジションのコストが高く、OSPFは障害検出を受信する場合、ネットワークを通るパスを自然に癒します。
In general, it is best for the protocol at the lowest point in the hierarchy to interact with BFD, and then to use existing interactions between the control protocols to effect changes as necessary. This will provide the fastest possible failure detection and recovery in a network.
一般に、階層の最も低いポイントにあるプロトコルがBFDと相互作用し、その後、コントロールプロトコル間の既存の相互作用を使用して、必要に応じて変化をもたらすのが最適です。これにより、ネットワーク内の最速の障害検出と回復が提供されます。
BFD session status may be used to affect other system functions that are not protocol based (for example, static routes). If the path to a remote system fails, it may be desirable to avoid passing traffic to that remote system, so the local system may wish to take internal measures to accomplish this (such as withdrawing a static route and withdrawing that route from routing protocols).
BFDセッションステータスを使用して、プロトコルベースではない他のシステム関数（静的ルートなど）に影響を与える場合があります。リモートシステムへのパスが失敗した場合、そのリモートシステムへのトラフィックを渡すことを避けることが望ましい場合があるため、ローカルシステムはこれを達成するために内部測定を行うことを望む場合があります（静的ルートを撤回したり、ルーティングプロトコルからそのルートを引き出すなど）。
If it is known, or presumed, that the remote system is BFD capable and the BFD session is not in Up state, appropriate action SHOULD be taken (such as withdrawing a static route).
リモートシステムがBFD能力であり、BFDセッションがUP状態にないことがわかっている、または推定されている場合、適切なアクションを実行する必要があります（静的ルートの撤回など）。
If it is known, or presumed, that the remote system does not support BFD, action such as withdrawing a static route SHOULD NOT be taken.
リモートシステムがBFDをサポートしていないことがわかっている、または推定されている場合、静的ルートの撤回などのアクションは実行されないでください。
Bootstrapping of the BFD session in the non-protocol case is likely to be derived from configuration information.
非プロトコルケースでのBFDセッションのブートストラップは、構成情報から導き出される可能性があります。
There is no need to exchange endpoints or discriminator values via any mechanism other than configuration (via Operational Support Systems or any other means) as the endpoints must be known and configured by the same means.
エンドポイントは同じ手段によって既知および構成されている必要があるため、構成以外のメカニズム（運用サポートシステムまたはその他の手段を介して）を介してエンドポイントまたは識別子値を交換する必要はありません。
BFD is intended to protect a single "data protocol" and is encapsulated within that protocol. A pair of systems may have multiple BFD sessions over the same topology if they support (and are encapsulated by) different protocols. For example, if two systems have IPv4 and IPv6 running across the same link between them, these are considered two separate paths and require two separate BFD sessions.
BFDは、単一の「データプロトコル」を保護することを目的としており、そのプロトコル内でカプセル化されています。一対のシステムには、異なるプロトコルをサポートする（およびカプセル化されている）場合、同じトポロジに対する複数のBFDセッションがある場合があります。たとえば、2つのシステムにIPv4とIPv6がそれらの間で同じリンクを越えて実行されている場合、これらは2つの別々のパスと見なされ、2つの別々のBFDセッションが必要です。
This same technique is used for more fine-grained paths. For example, if multiple differentiated services [DIFFSERV] are being operated over IPv4, an independent BFD session may be run for each service level. The BFD Control packets must be marked in the same way as the data packets, partly to ensure as much fate sharing as possible between BFD and data traffic, and also to demultiplex the initial packet if the discriminator values have not been exchanged.
この同じ手法は、よりきめ細かいパスに使用されます。たとえば、複数の差別化されたサービス[diffserv]がIPv4を介して操作されている場合、各サービスレベルで独立したBFDセッションが実行される場合があります。BFDコントロールパケットは、データパケットと同じ方法でマークされ、一部はBFDとデータトラフィックの間にできるだけ多くの運命共有を確保する必要があります。また、識別子の値が交換されていない場合は、初期パケットをDemultlexにする必要があります。
A number of technologies exist for aggregating multiple parallel links at layer N-1 and treating them as a single link at layer N. BFD may be used in a number of ways to protect the path at layer N. The exact mechanism used is outside the scope of this specification. However, this section provides examples of some possible deployment scenarios. Other scenarios are possible and are not precluded.
レイヤーN-1で複数の平行リンクを集約し、レイヤーNの単一リンクとして扱うための多くのテクノロジーが存在します。BFDは、レイヤーNでパスを保護するためにいくつかの方法で使用できます。この仕様の範囲。ただし、このセクションでは、いくつかの可能な展開シナリオの例を示します。他のシナリオは可能であり、排除されていません。
The simplest approach is to simply run BFD over the layer N path, with no interaction with the layer N-1 mechanisms. Doing so assumes that the layer N-1 mechanism will deal with connectivity issues in individual layer N-1 links. BFD will declare a failure in the layer N path only when the session times out.
最も簡単なアプローチは、レイヤーN-1メカニズムとの相互作用なしに、レイヤーNパス上でBFDを単純に実行することです。そうすることで、レイヤーn-1メカニズムが個々のレイヤーn-1リンクの接続性の問題を扱うと想定しています。BFDは、セッションがタイムアウトしたときにのみ、レイヤーnパスの障害を宣言します。
This approach will work whether or not the layer N-1 neighbor is the same as the layer N neighbor.
このアプローチは、レイヤーn-1隣接がレイヤーn隣接と同じかどうかにかかわらず機能します。
A slightly more intelligent approach than complete decoupling is to have the layer N-1 mechanism inform the layer N BFD when the aggregated link is no longer viable. In this case, the BFD session will detect the failure more rapidly, as it need not wait for the session to time out. This is analogous to triggering a session failure based on the hardware-detected failure of a single link.
完全なデカップリングよりもわずかにインテリジェントなアプローチは、集約されたリンクが生存できなくなったときに、レイヤーN-1メカニズムにレイヤーn BFDを通知することです。この場合、BFDセッションは、セッションのタイムアウトを待つ必要がないため、障害をより迅速に検出します。これは、単一のリンクのハードウェア検出された障害に基づいてセッション障害をトリガーすることに類似しています。
This approach will also work whether or not the layer N-1 neighbor is the same as the layer N neighbor.
このアプローチは、レイヤーn-1隣接がレイヤーn隣接と同じかどうかにも機能します。
Another approach would be to use BFD on each layer N-1 link and to aggregate the state of the multiple sessions into a single indication to the layer N clients. This approach has the advantage that it is independent of the layer N-1 technology. However, this approach only works if the layer N neighbor is the same as the layer N-1 neighbor (a single hop at layer N-1).
別のアプローチは、各レイヤーn-1リンクでBFDを使用し、複数のセッションの状態をレイヤーnクライアントへの単一の表示に集約することです。このアプローチには、レイヤーN-1テクノロジーに依存しないという利点があります。ただし、このアプローチは、レイヤーn隣接がレイヤーn-1隣接（レイヤーn-1の単一ホップ）と同じ場合にのみ機能します。
Combinations of more than one of the scenarios listed above (or others) may be useful in some cases. For example, if the layer N neighbor is not directly connected at layer N-1, a system might run a BFD session across each layer N-1 link to the immediate layer N-1 neighbor and then run another BFD session to the layer N neighbor. The aggregate state of the layer N-1 BFD sessions could be used to trigger a layer N BFD session failure.
上記のシナリオの複数の組み合わせ（または他のシナリオ）の組み合わせは、場合によっては役立つ場合があります。たとえば、レイヤーn隣接がレイヤーn-1で直接接続されていない場合、システムは各レイヤーn-1リンクを即座にレイヤーn-1ネイバーにリンクし、レイヤーnに別のBFDセッションを実行する可能性があります。近所の人。レイヤーn-1 BFDセッションの総計状態を使用して、レイヤーn BFDセッションの障害をトリガーできます。
BFD can provide liveness detection for functions related to Operations, Administration, and Maintenance (OAM) in tunneling and pseudowire protocols. Running BFD inside the tunnel is recommended, as it exercises more aspects of the path. One way to accommodate this is to address BFD packets based on the tunnel endpoints, assuming that they are numbered.
BFDは、トンネリングおよび擬似化プロトコルで、運用、管理、およびメンテナンス（OAM）に関連する機能のlivenives検出を提供できます。トンネル内でBFDを実行することをお勧めします。これは、パスのより多くの側面を行使するためです。これに対応する1つの方法は、トンネルのエンドポイントに基づいてBFDパケットに対処することです。
If a planned outage is to take place on a path over which BFD is run, it is preferable to take down the BFD session by going into AdminDown state prior to the outage. The system asserting AdminDown SHOULD do so for at least one Detection Time in order to ensure that the remote system is aware of it.
BFDが実行されるパスで計画された停止が行われる場合、停止前に承認状態に入ることにより、BFDセッションを倒すことが望ましいです。Asserting Asmindownのシステムは、リモートシステムがそれを認識していることを確認するために、少なくとも1つの検出時間の間そうすべきです。
Similarly, if BFD is to be deconfigured from a system, it is desirable not to trigger any client application action. Simply ceasing the transmission of BFD Control packets will cause the remote system to detect a session failure. In order to avoid this, the system on which BFD is being deconfigured SHOULD put the session into AdminDown state and maintain this state for a Detection Time to ensure that the remote system is aware of it.
同様に、BFDがシステムからデコンフィギングされる場合、クライアントアプリケーションアクションをトリガーしないことが望ましいです。BFD制御パケットの送信を停止するだけで、リモートシステムがセッションの障害を検出します。これを回避するために、BFDがデコン構成されているシステムは、セッションを承認状態に入れ、リモートシステムがそれを認識していることを確認するためにこの状態を維持する必要があります。
The BFD protocol itself is designed so that it will always interoperate at a basic level; asynchronous mode is mandatory and is always available, and other modes and functions are negotiated at run time. Since the service provided by BFD is identical regardless of the variants used, the particular choice of BFD options has no bearing on interoperability.
BFDプロトコル自体は、基本レベルで常に相互操作できるように設計されています。非同期モードは必須であり、常に利用可能であり、他のモードと機能は実行時にネゴシエートされます。BFDが提供するサービスは使用されるバリエーションに関係なく同一であるため、BFDオプションの特定の選択には相互運用性に関係していません。
The interaction between BFD and other protocols and control functions is very loosely coupled. The actions taken are based on existing mechanisms in those protocols and functions, so interoperability problems are very unlikely unless BFD is applied in contradictory ways (such as a BFD session failure causing one implementation to go down and another implementation to come up). In fact, BFD may be advising one system for a particular control function but not the other; the only impact of this would be potentially asymmetric control protocol failure detection.
BFDと他のプロトコルと制御機能の間の相互作用は、非常にゆるく結合されています。実行されたアクションは、これらのプロトコルと機能の既存のメカニズムに基づいているため、BFDが矛盾した方法で適用されない限り、相互運用性の問題は非常にありそうにありません（BFDセッションの障害など、1つの実装がダウンし、別の実装が発生します）。実際、BFDは、特定の制御機能については1つのシステムにアドバイスしている可能性がありますが、もう1つのシステムではありません。これの唯一の影響は、潜在的に非対称制御プロトコル障害検出です。
As noted above, there are no interoperability concerns regarding interactions between BFD and control protocols. However, there is enough concern and confusion in this area so that it is worthwhile to provide examples of interactions with specific protocols.
上記のように、BFDと制御プロトコル間の相互作用に関する相互運用性の懸念はありません。ただし、この分野では十分な懸念と混乱があるため、特定のプロトコルとの相互作用の例を提供する価値があります。
Since the interactions do not affect interoperability, they are non-normative.
相互作用は相互運用性に影響しないため、それらは非規範的です。
The two versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS [ISIS], all suffer from an architectural limitation, namely that their Hello protocols are limited in the granularity of their failure detection times. In particular, OSPF has a minimum detection time of two seconds, and IS-IS has a minimum detection time of one second.
OSPF（[OSPFV2]および[OSPFV3]）の2つのバージョン、およびIS [ISIS]はすべて、故障検出時間の粒度において、ハロープロトコルが制限されているという建築制限に苦しんでいます。特に、OSPFの最小検出時間は2秒で、IS-ISの最小検出時間は1秒です。
BFD may be used to achieve arbitrarily small detection times for these protocols by supplementing the Hello protocols used in each case.
BFDは、各ケースで使用されるハロープロトコルを補足することにより、これらのプロトコルの任意の小さな検出時間を達成するために使用できます。
The most obvious choice for triggering BFD session establishment with these protocols would be to use the discovery mechanism inherent in the Hello protocols in OSPF and IS-IS to bootstrap the establishment of the BFD session. Any BFD sessions established to support OSPF and IS-IS across a single IP hop must operate in accordance with [BFD-1HOP].
これらのプロトコルでBFDセッションの確立をトリガーするための最も明白な選択は、OSPFのハロープロトコルに固有の発見メカニズムを使用し、BFDセッションの確立をブートストラップすることです。OSPFとIS-ISをサポートするために確立されたBFDセッションは、[BFD-1HOP]に従って動作する必要があります。
The basic mechanisms are covered in Section 3 above. At this time, OSPFv2 and OSPFv3 carry routing information for a single data protocol (IPv4 and IPv6, respectively) so when it is desired to signal a topology change after a BFD session failure, this should be done by tearing down the corresponding OSPF neighbor.
基本的なメカニズムについては、上記のセクション3で説明しています。現時点では、OSPFV2とOSPFV3は、単一のデータプロトコル（それぞれIPv4とIPv6）のルーティング情報を運びます。
IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology-specific path associated with a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) in order to signal a lack of connectivity. Otherwise, a failing BFD session should be signaled by simulating an IS-IS adjacency failure.
IS-ISは、1つのデータプロトコル、または複数のデータプロトコルのみをサポートするために使用できます。[ISIS]は、複数のデータプロトコルの共通トポロジを指定していますが、複数のトポロジーをサポートする作業が進行中です。複数のトポロジが複数のデータプロトコル（または同じデータプロトコルのサービスの複数のクラス）をサポートするために使用される場合、障害のあるBFDセッションに関連付けられたトポロジ固有のパスは、IS-ISラベルスイッチ付きパス（LSP）で宣伝されなくなります。接続の欠如を知らせるために。それ以外の場合、IS-IS隣接障害をシミュレートすることにより、障害のあるBFDセッションを通知する必要があります。
OSPF has a planned restart signaling mechanism, whereas IS-IS does not. The appropriate mechanisms outlined in Section 3.3 should be used.
OSPFには計画された再起動シグナリングメカニズムがありますが、ISはそうではありません。セクション3.3で概説されている適切なメカニズムを使用する必要があります。
If it is desired to use BFD for failure detection of OSPF Virtual Links, the mechanism described in [BFD-MULTI] MUST be used, since OSPF Virtual Links may traverse an arbitrary number of hops. BFD authentication SHOULD be used and is strongly encouraged.
OSPF仮想リンクの障害検出にBFDを使用することが望ましい場合は、[BFD-Multi]に記載されているメカニズムを使用する必要があります。これは、OSPF仮想リンクが任意の数のホップを横断する可能性があるためです。BFD認証を使用する必要があり、強く推奨されています。
BFD may be useful with External Border Gateway Protocol (EBGP) sessions [BGP] in order to more rapidly trigger topology changes in the face of path failure. As noted in Section 4.4, it is generally unwise for IBGP sessions to interact with BFD if the underlying IGP is already doing so.
BFDは、パス障害に直面してトポロジの変化をより迅速にトリガーするために、外部ボーダーゲートウェイプロトコル（EBGP）セッション[BGP]で役立つ場合があります。セクション4.4で述べたように、基礎となるIGPがすでにそうしている場合、IBGPセッションがBFDと対話することは一般に賢明ではありません。
EBGP sessions being advised by BFD may establish either a one-hop [BFD-1HOP] or a multihop [BFD-MULTI] session, depending on whether or not the neighbor is immediately adjacent. The BFD session should be established to the BGP neighbor (as opposed to any other Next Hop advertised in BGP). BFD authentication SHOULD be used and is strongly encouraged.
BFDが助言するEBGPセッションは、隣人がすぐに隣接するかどうかに応じて、1ホップ[BFD-1HOP]またはマルチホップ[BFD-Multi]セッションのいずれかを確立する場合があります。BFDセッションは、BGP隣人に（BGPで宣伝されている他の次のホップとは対照的に確立される必要があります。BFD認証を使用する必要があり、強く推奨されています。
[BGP-GRACE] describes a Graceful Restart mechanism for BGP. If Graceful Restart is not taking place on an EBGP session, and the corresponding BFD session fails, the EBGP session should be torn down in accordance with Section 3.2. If Graceful Restart is taking place, the basic procedures in Section 4.3 apply. BGP Graceful Restart does not signal planned restarts, so Section 4.3.2.2 applies. If Graceful Restart is aborted due to the rules described in Section 4.3, the "receiving speaker" should act as if the "restart timer" expired (as described in [BGP-GRACE]).
[BGPグレース]は、BGPの優雅な再起動メカニズムを説明しています。EBGPセッションで優雅な再起動が行われず、対応するBFDセッションが失敗した場合、EBGPセッションはセクション3.2に従って取り壊されるはずです。優雅な再起動が行われている場合、セクション4.3の基本手順が適用されます。BGP Graceful Restartは計画された再起動を信号しないため、セクション4.3.2.2が適用されます。セクション4.3で説明されているルールのために優雅な再起動が中止された場合、「受信スピーカー」は「[BGP-Grace]で説明されているように）の有効期限が切れたように動作するはずです。
The Routing Information Protocol (RIP) [RIP] is somewhat unique in that, at least as specified, neighbor adjacency state is not stored per se. Rather, installed routes contain a next hop address, which in most cases is the address of the advertising neighbor (but may not be).
ルーティング情報プロトコル（RIP）[RIP]は、少なくとも指定されているように、近隣隣接状態自体が保存されていないという点で、ややユニークです。むしろ、インストールされたルートには次のホップアドレスが含まれています。これは、ほとんどの場合、広告の隣人のアドレスです（しかしそうではないかもしれません）。
In the case of RIP, when the BFD session associated with a neighbor fails, an expiration of the "timeout" timer for each route installed from the neighbor (for which the neighbor is the next hop) should be simulated.
RIPの場合、隣人に関連付けられたBFDセッションが失敗すると、隣人（隣人が次のホップである）からインストールされた各ルートの「タイムアウト」タイマーの有効期限をシミュレートする必要があります。
Note that if a BFD session fails, and a route is received from that neighbor with a next hop address that is not the address of the neighbor itself, the route will linger until it naturally times out (after 180 seconds). However, if an implementation keeps track of all of the routes received from each neighbor, all of the routes from the neighbor corresponding to the failed BFD session should be timed out, regardless of the next hop specified therein, and thereby avoiding the lingering route problem.
BFDセッションが失敗し、隣人自体のアドレスではない次のホップアドレスを持つその隣人からルートを受け取った場合、ルートは自然に時間が取られるまで（180秒後）残ることに注意してください。ただし、各近隣から受信したすべてのルートを実装が追跡する場合、その中で指定された次のホップに関係なく、故障したBFDセッションに対応する隣人からのすべてのルートをタイムアウトする必要があります。。
This specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references.
この仕様では、規範的参照のリストに記載されている仕様の問題を超えた追加のセキュリティ問題は発生しません。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、RFC 5880、2010年6月。
[BFD-1HOP] Katz, D. and D. Ward,"Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-1HOP] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、2010年6月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[BFD-MULTI] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[BFD-Multi] Katz、D。およびD. Ward、「マルチホップパスの双方向転送検出（BFD）」、RFC 5883、2010年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、Ed。、Li、T.、Ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[BGP-GRACE] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[BGPグレース] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPの優雅な再起動メカニズム」、RFC 4724、2007年1月。
[DIFFSERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[Diffserv] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[ISIS] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[ISIS-GRACE] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[ISIS-Grace] Shand、M。およびL. Ginsberg、「IS-ISの再起動シグナリング」、RFC 5306、2008年10月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[OSPF-GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[Ospf-grace] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
Authors' Addresses
著者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089-1206 USA
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089-1206 USA
Phone: +1-408-745-2000
EMail: dward@juniper.net