[要約] RFC 7419は、双方向転送検出（BFD）での共通間隔サポートに関する仕様です。このRFCの目的は、異なるBFD実装間での共通の間隔設定を提供し、ネットワークの信頼性と効率を向上させることです。
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セッションを実行する間隔の共通値を2つのサイドが見つけられない可能性があります。
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で見られるような簡素化された実装が可能になります。これは、実装が共通の間隔に加えて、より多くの間隔をサポートすることを制限しません。
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コミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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で入手できます。
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
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.
Bidirectional Forwarding Detection（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 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の潜在的な問題は、インターバルタイマーの粒度です。実装によっては、相互運用性の問題を引き起こす可能性がある数個の間隔のみがサポートされる場合があります。このドキュメントでは、すべての実装でサポートされる一連の間隔値を提案しています。詳細は以下のセクションで説明されています。
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セッションを実行する間隔について合意することはできません。
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」はどちらも、共通の間隔セット以外の追加の値を自由にサポートできます。
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プロトコルを実装するデバイスに適用されます。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[G.8013_Y.1731] International Telecommunications Union, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
[G.8013_Y.1731]国際電気通信連合、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T勧告G.8013 / Y.1731、2013年11月。
[GR-253-CORE] Telcordia Technologies, Inc., "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", GR-253-CORE Issue 05, October 2009.
[GR-253-CORE] Telcordia Technologies、Inc。、「Synchronous Optical Network（SONET）Transport Systems：Common Generic Criteria」、GR-253-CORE Issue 05、2009年10月。
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操作には必要ないため、共通間隔の設定外に保持されます。代わりに、予想される使用法は、必要に応じてグレースフルリスタート用です。
[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 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
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
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
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
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
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
Router B would adjust its timers based on the received Final bit
ルータBは受信したFinalビットに基づいてタイマーを調整します
(B) Tx: 300 msec , Detect: 3 * 1 sec
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
which finally makes router A adjust its timers:
これにより、最終的にルーターAのタイマーが調整されます。
(A) Tx: 1 sec, Detect: 3 * 1 sec
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".
投票シーケンスについての議論を提起してくれたSylvain MasseとAnca Zamfirに感謝し、「正確」と「知識」の境界線を見つける手助けをしてくれたJeffrey Haasに感謝します。
Authors' Addresses
著者のアドレス
Nobo Akiya Cisco Systems
のぼ あきや しｓこ Ｓｙｓてｍｓ
EMail: nobo@cisco.com
Marc Binderberger Cisco Systems
Marc Binderberger Cisco Systems
EMail: mbinderb@cisco.com
Greg Mirsky Ericsson
グレッグ・ミルスキー・エリクソン
EMail: gregory.mirsky@ericsson.com