7. Operational Considerations (運用上の考慮事項)

7. Operational Considerations (運用上の考慮事項)

BFD は, ネットワークインフラストラクチャの重要な部分として展開される可能性が高いため, 混乱を避けるように注意する必要があります。

明らかに, ファイアウォールやその他のポリシープロセスなど, BFD パケットをブロックするメカニズムは BFD を失敗させます。

ポリサー, トラフィックシェーパー, 優先度キューイングなどのパケットスケジューリングを制御するメカニズムは, 検出時間がスケジュールされたパケット送信または受信レートと同程度の規模である場合, BFD 動作に影響を与える可能性があります。BFD パケットの配信は, 検出時間の大きさに対して時間的に重要であるため, 特に非常に短い検出時間を使用する場合は, 実装と展開においてこれを考慮する必要があるかもしれません。

BFD が複数のホップを通じて使用される場合, 輻輳制御メカニズムを実装しなければならず (MUST), 輻輳が検出された場合, BFD 実装は生成するトラフィックの量を削減しなければなりません (MUST)。使用される正確なメカニズムは, この仕様の範囲外であり, このメカニズムの要件は, BFD がどのように展開されるか, およびシステムの他の部分とどのように相互作用するか (たとえば, ルーティングプロトコルが BFD と密接に相互作用している場合, 指数バックオフは適切でない可能性があります) に応じて異なる場合があります。

"輻輳" はトラフィック現象だけでなく, 計算上の現象でもあることに注意してください。多数の BFD セッションおよび/または非常に短いパケット間隔を持つシステムが CPU バウンドになる可能性があります。そのため, 他の定期的な Hello ベースのプロトコルで繰り返し見られたような壊滅的なシステム崩壊の可能性を避けるために, 単一ホップを通じても輻輳制御アルゴリズムを使用すべきです (SHOULD)。

輻輳を検出するメカニズムは, この仕様の範囲外ですが, 失われた BFD Control パケットの検出 (認証シーケンス番号空間の穴によって, または BFD セッション障害によって) またはその他の手段を含む可能性があります。

BFD のトラフィック負荷を削減するメカニズムは, Min RX Interval および Min TX Interval フィールドを介したローカルおよびリモートパケット送信レートの制御です。

送信または受信間隔を増加させるメカニズムは, セッションの検出時間を増加させることに注意してください。

単一の BFD セッションが大量の帯域幅を消費しないことは注目に値します。16.7ミリ秒の送信間隔と3の検出乗数を使用して50ミリ秒の検出時間を実現する積極的なセッションは, 毎秒60パケットを生成します。ワイヤ上の各パケットの最大長は約100バイトで, 各方向で合計約48キロビット毎秒の帯域幅消費になります。