双方向転送検出における共通の間隔のサポート
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7419 M. Binderberger
Updates: 5880 Cisco Systems
Category: Informational G. Mirsky
ISSN: 2070-1721 Ericsson
December 2014
Common Interval Support in Bidirectional Forwarding Detection
双方向転送検出における共通の間隔のサポート
Abstract
概要
Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.
双方向転送検出（BFD）では、メッセージを定期的に送信する必要があり、BFDピアが使用する間隔をネゴシエートする方法を提供します。 一部のBFD実装は、いくつかの間隔値のみをサポートするように制限されている場合があります。 このようなBFD実装が相互に通信する場合、BFDセッションを実行する間隔の共通値を見つけることができない可能性があります。
This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.
このドキュメントでは、「共通間隔」と呼ばれるBFDの間隔値の小さなセットを定義することによってRFC 5880を更新し、定義された間隔をサポートする実装を推奨しています。 これにより、両方のBFDスピーカーがサポートできる間隔値を見つける問題が解決され、ハードウェアベースのBFDで見られるような簡素化された実装が可能になります。 これは、実装がCommon Intervalsに加えてより多くの間隔をサポートすることを制限しません。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 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/rfc7419.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7419で入手できます。
Akiya, et al. Informational [Page 1] RFC 7419 Common Interval Support in BFD December 2014 Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。 全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem with Few Supported Intervals . . . . . . . . . . 3
3. Well-Defined, Common Intervals . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Why Some Values Are in the Common Interval Set . . . 6
Appendix B. Timer Adjustment with Non-identical Interval Sets . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1.はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.サポートされている間隔が少ない問題 . . . . . . . . . . . . . . 3
3.明確な共通間隔 . . . . . . . . . . . . . . . . . . . . . . . . 4
4.セキュリティに関する考慮事項 . . . . . . . . . . . . . . . . . 4
5.参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. 規範的な参照 . . . . . . . . . . . . . . . . . . . . . . 5
5.2. 有益な参照 . . . . . . . . . . . . . . . . . . . . . . . 5
付録A.一部の値が共通間隔セットに含まれる理由 . . . . . . . . . . 6
付録B.間隔セットが同一でないタイマー調整 . . . . . . . . . . . . 6
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
1.はじめに
The Bidirectional Forwarding Detection (BFD) standard [RFC5880] describes how to calculate the transmission interval and the detection time. However, it does not make any statement about how to solve a situation where one BFD speaker cannot support the calculated value. In practice, this may not have been a problem as long as software-implemented timers were used and as long as the granularity of such timers was small compared to the interval values being supported, i.e. as long as the error in the timer interval was small compared to 25 percent jitter.
双方向転送検出（BFD）標準[RFC5880]は、送信間隔と検出時間の計算方法を説明しています。 ただし、1つのBFDスピーカーが計算値をサポートできない状況を解決する方法については何も述べられていません。 実際には、ソフトウェア実装のタイマーが使用されていて、そのようなタイマーの粒度がサポートされている間隔の値と比較して小さい限り、これは問題ではなかった可能性があります。 タイマー間隔のエラーが25％のジッターと比較して小さい限り。
In the meantime, requests exist for very fast interval values, down to 3.3 msec for the MPLS Transport Profile (MPLS-TP). At the same time, the requested scale for the number of BFD sessions is increasing. Both requirements have driven vendors to use Network Processors (NP), Field Programmable Gate Arrays (FPGAs), or other hardware-based solutions to offload the periodic packet transmission and the timeout detection in the receive direction. A potential Akiya, et al. Informational [Page 2] RFC 7419 Common Interval Support in BFD December 2014 problem with this hardware-based BFD is the granularity of the interval timers. Depending on the implementation, only a few intervals may be supported, which can cause interoperability problems. This document proposes a set of interval values that should be supported by all implementations. Details are laid out in the following sections.
その間、MPLSトランスポートプロファイル（MPLS-TP）の場合は3.3ミリ秒までの非常に高速な間隔値の要求が存在します。 同時に、BFDセッション数の要求されるスケールが増加しています。 両方の要件により、ベンダーはネットワークプロセッサ（NP）、フィールドプログラマブルゲートアレイ（FPGA）、またはその他のハードウェアベースのソリューションを使用して、定期的なパケット送信と受信方向のタイムアウト検出をオフロードしています。 このハードウェアベースのBFDの潜在的な問題は、インターバルタイマーの粒度です。 実装によっては、相互運用性の問題を引き起こす可能性がある数個の間隔のみがサポートされる場合があります。 このドキュメントでは、すべての実装でサポートされる一連の間隔値を提案しています。 詳細については、次のセクションで説明します。
2. The Problem with Few Supported Intervals
2.サポートされている間隔が少ない問題
Let's assume vendor "A" supports 10 msec, 100 msec, and 1 sec interval timers in hardware, and vendor "B" supports every value from 20 msec onward, with a granularity of 1 msec. For a BFD session, "A" tries to set up the session with 10 msec while "B" uses 20 msec as the value for RequiredMinRxInterval and DesiredMinTxInterval. Rx and Tx are negotiated as described in [RFC5880], which is 20 msec in this case. However, system "A" is not able to support the 20 msec interval timer. Multiple ways exist to resolve the dilemma, but none of them is without problems.
ベンダー「A」がハードウェアで10ミリ秒、100ミリ秒、1秒のインターバルタイマーをサポートし、ベンダー「B」が1ミリ秒の粒度で20ミリ秒以降のすべての値をサポートするとします。 BFDセッションの場合、「A」は10ミリ秒でセッションをセットアップしようとしますが、「B」はRequiredMinRxIntervalおよびDesiredMinTxIntervalの値として20ミリ秒を使用します。 RxとTxは、[RFC5880]で説明されているようにネゴシエートされます。この場合、20ミリ秒です。 ただし、システム「A」は20ミリ秒のインターバルタイマーをサポートできません。 ジレンマを解決するにはいくつかの方法がありますが、どれも問題がないわけではありません。
a. Realizing that it cannot support 20 msec, system "A" sends out a
new BFD packet advertising the next larger interval of 100 msec
with RequiredMinRxInterval and DesiredMinTxInterval. The new
negotiated interval between "A" and "B" is then 100 msec, which
is supported by both systems. However, the problem is that we
moved from the 10/20 msec range to 100 msec, which has far
deviated from operator expectations.
a。 20ミリ秒をサポートできないことを認識して、システム「A」は、RequiredMinRxIntervalとDesiredMinTxIntervalを使用して、次に大きい100ミリ秒の間隔をアドバタイズする新しいBFDパケットを送信します。 「A」と「B」の間の新しいネゴシエートされた間隔は100ミリ秒であり、これは両方のシステムでサポートされています。 ただし、問題は10/20ミリ秒の範囲から100ミリ秒に移動したことで、これはオペレーターの期待とはかけ離れたものです。
b. System "A" could violate [RFC5880] and use the 10 msec interval
for the Tx direction. In the receive direction, it could use an
adjusted multiplier value M' = 2 * M to match the correct
detection time. Now, in addition to the fact that we explicitly
violate [RFC5880], there may be the problem that system "B" drops
up to 50% of the packets; this could be the case when "B" uses an
ingress rate policer to protect itself and the policer would be
programmed with an expectation of 20 msec receive intervals.
b。 システム「A」は違反する可能性があり[RFC5880]、Tx方向に10ミリ秒の間隔を使用します。 受信方向では、調整された乗数値M '= 2 * Mを使用して、正しい検出時間と一致させることができます。 ここで、明示的に[RFC5880]に違反しているという事実に加えて、システム「B」がパケットの最大50％をドロップするという問題がある可能性があります。 これは、「B」がそれ自体を保護するために入力レートポリサーを使用し、ポリサーが20ミリ秒の受信間隔の期待値でプログラムされる場合に当てはまります。
The example above could be worse when we assume that system "B" can only support a few timer values itself. Let's assume "B" supports 20 msec, 300 msec, and 1 sec. If both systems would adjust their advertised intervals, then the adjustment ends at 1 sec. The example above could even be worse when we assume that system "B" can only support 50 msec, 500 msec, and 2 sec. Even if both systems walk through all of their supported intervals, the two systems will never be able to agree on an interval to run any BFD sessions.
上記の例は、システム "B"が少数のタイマー値のみをサポートできると想定すると、さらに悪くなる可能性があります。 「B」が20ミリ秒、300ミリ秒、1秒をサポートするとします。 両方のシステムがアドバタイズされた間隔を調整する場合、調整は1秒で終了します。 上記の例は、システム "B"が50ミリ秒、500ミリ秒、2秒しかサポートできないと想定すると、さらに悪くなる可能性があります。 両方のシステムがサポートされている間隔をすべて通過したとしても、2つのシステムがBFDセッションを実行する間隔について合意することはできません。
Akiya, et al. Informational [Page 3] RFC 7419 Common Interval Support in BFD December 2014 3. Well-Defined, Common Intervals
3.明確に定義された一般的な間隔
The problem can be reduced by defining interval values that are supported by all implementations. Then, the adjustment mechanism could find a commonly supported interval without deviating too much from the original request.
この問題は、すべての実装でサポートされている間隔値を定義することで軽減できます。 次に、調整メカニズムは、元の要求から大きく逸脱することなく、一般的にサポートされている間隔を見つけることができます。
In technical terms, the requirement is as follows: a BFD implementation should support all values in the set of Common Interval values that are equal to or larger than the fastest (i.e., lowest) interval the particular BFD implementation supports.
技術的には、要件は次のとおりです。BFD実装は、特定のBFD実装がサポートする最速（つまり、最低）間隔以上の共通間隔値のセット内のすべての値をサポートする必要があります。
This document defines the set of Common Interval values to be: 3.3 msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
このドキュメントでは、共通間隔の値のセットを3.3ミリ秒、10ミリ秒、20ミリ秒、50ミリ秒、100ミリ秒、1秒に定義しています。
In addition, both a 10 sec interval and multiplier values up to 255 are recommended to support graceful restart.
さらに、グレースフルリスタートをサポートするために、10秒間隔と最大255の乗数値の両方が推奨されます。
The adjustment is always towards larger (i.e., slower) interval values when the initial interval proposed by the peer is not supported.
ピアによって提案された初期間隔がサポートされていない場合、調整は常により大きい（つまり、遅い）間隔値に向かって行われます。
This document is not adding new requirements with respect to the precision with which a timer value must be implemented. Supporting an interval value means advertising this value in the DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD packets and providing timers that are reasonably close. [RFC5880] defines safety margins for the timers by defining a jitter range.
このドキュメントは、タイマー値を実装する必要がある精度に関して新しい要件を追加するものではありません。 間隔値をサポートするということは、BFDパケットのDesiredMinTxIntervalフィールドまたはRequiredMinRxIntervalフィールド、あるいはその両方でこの値をアドバタイズし、適度に近いタイマーを提供することを意味します。 [RFC5880]は、ジッター範囲を定義することにより、タイマーの安全マージンを定義します。
How is the Common Interval set used exactly? In the example above, vendor "A" has a fastest interval of 10 msec and thus would be required to support all intervals in the Common Interval set that are equal or larger than 10 msec, i.e., it would support 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec. Vendor "B" has a fastest interval of 20 msec and thus would need to support 20 msec, 50 msec, 100 msec, and 1 sec. As long as this requirement is met for the common set of values, then both vendor "A" and "B" are free to support additional values outside of the Common Interval set.
共通間隔セットはどのように正確に使用されますか？ 上記の例では、ベンダー「A」は最速の間隔が10ミリ秒であるため、10ミリ秒以上の共通間隔セット内のすべての間隔をサポートする必要があります。つまり、10ミリ秒、20ミリ秒をサポートします。 50ミリ秒、100ミリ秒、1秒。 ベンダー「B」は20ミリ秒の最速間隔を持っているため、20ミリ秒、50ミリ秒、100ミリ秒、1秒をサポートする必要があります。 共通の値のセットについてこの要件が満たされている限り、ベンダー「A」と「B」の両方が、共通の間隔セット以外の追加の値を自由にサポートできます。
4. Security Considerations
4.セキュリティに関する考慮事項
This document does not introduce any additional security concerns. The security considerations described in the BFD documents, [RFC5880] and others, apply to devices implementing the BFD protocol, regardless of whether or not the Common Interval set is implemented.
このドキュメントでは、セキュリティに関する追加の問題は紹介していません。 BFDドキュメント[RFC5880]などで説明されているセキュリティの考慮事項は、Common Intervalセットが実装されているかどうかに関係なく、BFDプロトコルを実装しているデバイスに適用されます。
Akiya, et al. Informational [Page 4] RFC 7419 Common Interval Support in BFD December 2014 5. References
5.リファレンス
5.1. Normative References
5.1。 規範的な参考文献
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
5.2. Informative References
5.2。 参考情報
[G.8013_Y.1731]
International Telecommunications Union, "OAM functions and
mechanisms for Ethernet based networks", ITU-T
Recommendation G.8013/Y.1731, November 2013.
[GR-253-CORE]
Telcordia Technologies, Inc., "Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria",
GR-253-CORE Issue 05, October 2009.
Akiya, et al. Informational [Page 5]
RFC 7419 Common Interval Support in BFD December 2014
Appendix A. Why Some Values Are in the Common Interval Set
付録A.一部の値が共通間隔セットに含まれる理由
The list of Common Interval values is trying to balance various objectives. The list should not contain too many values, as more timers may increase the implementation costs. On the other hand, fewer values produces larger gaps and adjustment jumps. More values in the lower interval range are thus seen as critical to support customer needs for fast detection in setups with multiple vendors.
Common Interval値のリストは、さまざまな目的のバランスをとろうとしています。 タイマーを増やすと実装コストが増加する可能性があるため、リストにはあまり多くの値を含めないでください。 一方、値が少ないと、ギャップと調整ジャンプが大きくなります。 したがって、複数のベンダーのセットアップでの高速検出に対する顧客のニーズをサポートするには、より低い間隔範囲のより多くの値が重要であると見なされます。
o 3.3 msec: required by MPLS-TP, to support the defect detection
time of 10 msec from [GR-253-CORE].
o 3.3ミリ秒：[GR-253-CORE]からの10ミリ秒の欠陥検出時間をサポートするためにMPLS-TPで必要です。
o 10 msec: general consensus is to support 10 msec. Multiple
vendors plan to or do already implement 10 msec.
o 10ミリ秒：一般的なコンセンサスは10ミリ秒をサポートすることです。 複数のベンダーが10ミリ秒の実装を計画しているか、すでに実装しています。
o 20 msec: basically avoids a larger gap in this critical interval
region. Still allows 50-60 msec detect and restore (with
multiplier of 2) and covers existing software-based
implementations.
o 20ミリ秒：基本的に、このクリティカルインターバル領域の大きなギャップを回避します。 それでも50〜60ミリ秒の検出と復元を可能にし（乗数2）、既存のソフトウェアベースの実装をカバーします。
o 50 msec: widely deployed interval. Supporting this value reflects
the reality of many BFD implementations today.
o 50ミリ秒：広く展開された間隔。 この値のサポートは、今日の多くのBFD実装の現実を反映しています。
o 100 msec: similar to 10 msec, this value allows the reuse of
[G.8013_Y.1731] implementations, especially hardware. It supports
a large number of 100 msec sessions with multiplier 9 (9 x 100
msec), which could be replacing of 3 x 300 msec configurations
used by customers to have a detection time slightly below 1 sec
for VoIP setups.
o 100ミリ秒：10ミリ秒と同様に、この値は[G.8013_Y.1731]実装、特にハードウェアの再利用を可能にします。 乗数9（9 x 100ミリ秒）で多数の100ミリ秒セッションをサポートします。これは、VoIPセットアップで検出時間が1秒をわずかに下回るように顧客が使用する3 x 300ミリ秒構成の代わりになる可能性があります。
o 1 sec: as mentioned in [RFC5880]. While the interval for Down
packets can be 1 sec or larger, this document recommends use of
exactly 1 sec to avoid interoperability issues.
o 1秒：[RFC5880]で述べられているとおり。 ダウンパケットの間隔は1秒以上にすることができますが、このドキュメントでは、相互運用性の問題を回避するために正確に1秒を使用することを推奨しています。
The recommended value for large intervals is 10 sec, allowing for a timeout of 42.5 minutes with a multiplier of 255. This value is kept outside the Common Interval set, as it is not required for normal BFD operations that occur in the sub-second range. Instead, the expected usage is for graceful restart, if needed.
大きな間隔の推奨値は10秒で、255の乗数で42.5分のタイムアウトが可能です。 この値は、1秒未満の範囲で発生する通常のBFD操作には必要ないため、共通間隔セットの外側に保持されます。 代わりに、予想される使用法は、必要に応じてグレースフルリスタート用です。
Appendix B. Timer Adjustment with Non-identical Interval Sets
付録B.同一でない間隔セットを使用したタイマー調整
[RFC5880] implicitly assumes that a BFD implementation can support any timer value equal to or above the advertised value. When a BFD speaker starts a Poll Sequence, then the peer must reply with the Final (F) bit set and adjust the transmit and detection timers accordingly. With contiguous software-based timers, this is a valid assumption. Even in the case of a small number of supported interval Akiya, et al. Informational [Page 6] RFC 7419 Common Interval Support in BFD December 2014 values, this assumption holds when both BFD speakers support exactly the same interval values.
[RFC5880]は、BFD実装がアドバタイズされた値以上の任意のタイマー値をサポートできることを暗黙的に想定しています。 BFDスピーカーがポーリングシーケンスを開始すると、ピアは最終（F）ビットを設定して応答し、それに応じて送信および検出タイマーを調整する必要があります。 連続したソフトウェアベースのタイマーでは、これは有効な仮定です。 サポートされる間隔値の数が少ない場合でも、両方のBFDスピーカーがまったく同じ間隔値をサポートしている場合は、この仮定が当てはまります。
But what happens when both speakers support intervals that are not supported by the peer? An example is router "A" supporting the Common Interval set plus 200 msec, while router "B" supports the Common Intervals plus 300 msec. Assume both routers are configured and run at 50 msec. Now, router A is configured for 200 msec. We know the result must be that both BFD speakers use 1 sec timers, but how do they reach this endpoint?
しかし、両方のスピーカーがピアによってサポートされていない間隔をサポートするとどうなりますか？ 例としては、ルーター「A」が共通間隔に加えて200ミリ秒をサポートし、ルーター「B」が共通間隔に加えて300ミリ秒をサポートする場合があります。 両方のルーターが構成され、50ミリ秒で実行されているとします。 これで、ルータAは200ミリ秒に設定されました。 結果は両方のBFDスピーカーが1秒のタイマーを使用する必要があることを知っていますが、どのようにしてこのエンドポイントに到達しますか？
First, router A sends a packet with 200 msec. The P bit is set according to [RFC5880]. The Tx timer stays at 50 msec, the detection timer is 3 * 200 msec:
まず、ルータAが200ミリ秒のパケットを送信します。 Pビットは[RFC5880]に従ってセットされます。 Txタイマーは50ミリ秒のままで、検出タイマーは3 * 200ミリ秒です。
(A) DesiredTx: 200 msec, MinimumRx: 200 msec, P-bit
Tx: 50 msec, Detect: 3 * 200 msec
（A）DesiredTx：200ミリ秒、MinimumRx：200ミリ秒、Pビット Tx：50ミリ秒、検出：3 * 200ミリ秒
Router B now must reply with an F bit. The problem is B is confirming timer values that it cannot support. The only setting to avoid a session flap would be
ルータBはFビットで応答する必要があります。 問題は、Bがサポートできないタイマー値を確認していることです。 セッションフラップを回避する唯一の設定は
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 50 msec, Detect: 3 * 300 msec
（B）DesiredTx：300ミリ秒、MinimumRx：300ミリ秒、Fビット Tx：50ミリ秒、検出：3 * 300ミリ秒
immediately followed by a P-bit packet, as the advertised timer values have been changed:
アドバタイズされたタイマー値が変更されたため、直後にPビットパケットが続きます。
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, P-bit
Tx: 50 msec, Detect: 3 * 300 msec
（B）DesiredTx：300ミリ秒、MinimumRx：300ミリ秒、Pビット Tx：50ミリ秒、検出：3 * 300ミリ秒
This is not exactly what Section 6.8.7 of [RFC5880] states about the transmission rate. On the other hand, as we will see, this state does not last for long. Router A would adjust its timers based on the received Final bit:
これは、[RFC5880]のセクション6.8.7が伝送速度に関して述べていることとは正確には異なります。 一方、後で見るように、この状態は長く続きません。 ルータAは、受信したFinalビットに基づいてタイマーを調整します。
(A) Tx: 200 msec, Detect: 3 * 1 sec
（A）Tx：200ミリ秒、検出：3 * 1秒
Router A is not supporting the proposed 300 msec and would use 1 sec instead for the detection time. It would then respond to the received Poll Sequence from router B using 1 sec, as router A does not support the Max(200 msec, 300 msec):
ルータAは提案された300ミリ秒をサポートしておらず、代わりに検出時間に1秒を使用します。 次に、ルーターAはMax（200ミリ秒、300ミリ秒）をサポートしていないため、ルーターBから受信したポーリングシーケンスに1秒で応答します。
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, F-bit
Tx: 200 msec, Detect: 3 * 1 sec
（A）DesiredTx：1秒、MinimumRx：1秒、Fビット Tx：200ミリ秒、検出：3 * 1秒
Akiya, et al. Informational [Page 7] RFC 7419 Common Interval Support in BFD December 2014 followed by its own Poll Sequence, as the advertised timer values have been changed:
アドバタイズされたタイマー値が変更されたため、独自のポーリングシーケンスが続きます。
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, P-bit
Tx: 200 msec, Detect: 3 * 1 sec
（A）DesiredTx：1秒、MinimumRx：1秒、Pビット Tx：200ミリ秒、検出：3 * 1秒
Router B would adjust its timers based on the received Final bit
ルータBは受信したFinalビットに基づいてタイマーを調整します
(B) Tx: 300 msec , Detect: 3 * 1 sec
（B）Tx：300ミリ秒、検出：3 * 1秒
and would then reply to the Poll Sequence from router A:
次に、ルータAからのポーリングシーケンスに応答します。
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 1 sec, Detect: 3 * 1 sec
（B）DesiredTx：300ミリ秒、MinimumRx：300ミリ秒、Fビット Tx：1秒、Detect：3 * 1秒
which finally makes router A adjust its timers:
最終的にルーターAのタイマーを調整します。
(A) Tx: 1 sec, Detect: 3 * 1 sec
（A）Tx：1秒、Detect：3 * 1秒
In other words, router A and B go through multiple Poll Sequences until they reach a commonly supported interval value. Reaching such a value is guaranteed by this document.
つまり、ルータAとBは、一般的にサポートされている間隔値に達するまで、複数のポーリングシーケンスを実行します。 このような値に到達することは、このドキュメントで保証されています。
Acknowledgments We would like to thank Sylvain Masse and Anca Zamfir for bringing up the discussion about the Poll Sequence, and Jeffrey Haas for helping find the fine line between "exact" and "pedantic". Authors' Addresses Nobo Akiya Cisco Systems EMail: nobo@cisco.com Marc Binderberger Cisco Systems EMail: mbinderb@cisco.com Greg Mirsky Ericsson EMail: gregory.mirsky@ericsson.com Akiya, et al. Informational [Page 8]