要約

  • BMP Statistics Information TLV の01版は、測定窓の長さ、標本数、P5とP95、時刻有無のフラグ、最小値と最大値のマイクロ秒精度時刻を追加した。
  • これにより端点だけでは見えない変動を確認できるが、標本の並び、ある値にとどまった時間、収集側が実際に行動可能になった時点は分からない。

正午の経路数が10,000で、15分後も10,000だったとする。従来の定期スナップショットだけなら、Adj-RIB-In は安定していたと判断しやすい。だが途中で15,000まで増え、8,000まで減り、最後に10,000へ戻った可能性がある。提案中の Statistics Information TLV は、その最小値と最大値に加え、平均、中央値、P5、P95、標本数を送れる。二つの極値には観測時刻も付けられる。

これは重要な前進である。ただし15分間の再生記録ではない。15,000への一秒の跳ね上がり、10分続く高止まり、何度もの往復は、同じ要約を作り得る。同じ十五個の値を別の順番に並べても、最小、最大、平均、中央値、パーセンタイルは変わらない一方、運用上の説明は変わる。

対象文書は draft-ietf-grow-bmp-stats-informational-tlv-01 で、2026年9月11日に公開され、2027年3月15日に失効する。GROW ワーキンググループの Internet-Draft で状態は I-D Exists。表紙は Standards Track とするが、Datatracker の Intended RFC status は空欄である。document shepherd、担当 area director、telechat の記録はない。要求される IANA レジストリと型は TBD1 のままで、コードポイントは未割り当てだ。実装報告、相互接続試験、商用導入、実測結果も示されていない。

01版が窓と分母を追加した意味

RFC 7854 は BMP Statistics Report を定義するが、周期的なゲージ値は報告間の出来事を落とす。00版は最小、最大、スナップショット、平均、中央値を提案した。01版は32ビットの Measurement Window Duration と Sample Count を加え、P5 と P95 を導入し、予約バイトをフラグに置き換えた。

T ビットは時刻の有無を示す。最小値と最大値には1970年UTCからの秒とマイクロ秒を必ず付ける。スナップショット、平均、中央値、P5、P95には付けてはならない。標本数は派生値の母数を示す。同時に、報告された最大値は観測できた標本の中で最大だっただけであり、標本間のさらに高い値を否定しない。

測定窓は送信間隔と同じとは限らない。イベント起動の報告、新しいセッション、peer の状態遷移では部分窓になる場合がある。同じ統計を異なる窓で表すなら、送信側は別々の Information TLV を使う必要がある。最初の報告では TLV 自体を省略することも認められる。

分布を残す圧縮は時系列を捨てる

一分ごとに十五回測る。窓Aでは十三回が10,000付近で、一回が15,000、一回が8,000だった。窓Bは同じ値を持つが、15,000から始まり8,000で終わる。出力欄は同じにできる。しかし経路急増が大量withdrawより先か、復旧が対策後か、二つの症状に因果の時間条件があるかは、順序なしには判断できない。

極値時刻は二点を固定するだけで、その間を並べ直さない。P95 は高い状態が連続したのか、短い現象が散発したのかを示さない。Sample Count は分母であって順番ではなく、Window Duration は長さであって滞在時間ではない。

草案は、収集方式が周期型、イベント型、混合型になり得ること、nearest-rank と線形補間が同じ標本から異なる値を出し得ることも明記する。内部設定や計算法はメッセージに含まれないため、ルータ間比較には別途互換性の確保が必要だ。しかし方式、時計、アルゴリズムを全てそろえても、分布要約から捨てた並びを復元することはできない。

観測時刻は開始時刻でも継続時間でもない

最小と最大については、メッセージ作成時刻ではなく実際の観測時刻を送るべきだとされる。その精度はルータの時計分解能と時刻同期に依存する。TLS や IPsec で通信を守っても、誤った時計は直らない。

一分間隔で12時08分に最大値を見た場合、しきい値を超えたのは12時07分01秒かもしれず、07分59秒かもしれない。一秒後に戻った可能性も、次の標本まで続いた可能性もある。さらに、12時01分の異常が15分周期の報告で12時15分に届くこともある。極値時刻は過去の位置を補うが、通知をリアルタイムにはしない。証拠時刻、生成、転送、受信、行動の各時刻を分離する必要がある。

パーサには厳密な文脈が要る

TLV は有効な BMP gauge Stat Type を参照しなければならず、単調増加 counter に使うものではない。誤用は受信側が無視し、必要なら記録する。未知の Entry Type は T ビットにより10または18オクテットと判断して読み飛ばせる。同じ Entry Type が重複した場合、最初より後は無視する。

Stat Type 9 と10は AFI/SAFI ごとの意味を持つが、Information TLV 自体にアドレスファミリ識別子はない。同じ報告に同一 AFI/SAFI の通常統計 TLV がなければ、分布の対象が分からず利用できない。通常スナップショットと Information TLV が共存する場合、値は最小と最大の間にあるべきだ。これは整合性検査にはなるが、全標本の正しさを証明しない。

BMP は統計内容そのものを暗号学的に保証しない。通信路と相手を TLS や IPsec で守れても、侵害された監視ルータは偽の要約を出せる。TLV の拡張はサイズと状態も増やすため、レート制御と資源管理も残る。

判断に使う場所だけでも狭い生データを残す

Heng Lu の最小初期仕様という考え方は、参照指標、窓、分母、共通要約だけを相互運用可能にし、各社の収集実装まで固定しない設計を支持する。稼働コード優先の原則は、圧縮値がアラート、変更、緩和措置に変わる地点で追加の証拠を求める。

重大なしきい値については、超過前後の生標本またはイベントを有限リングに保つべきだ。窓の開始と終了、方式と間隔、パーセンタイル手法、時計源と偏差、報告生成時刻と受信時刻、設定世代、TLV の正確なバイト列を記録する。報告間隔を延ばす前に、要約ベースのアラートをこの追跡データと照合する。これは運用上の提案であり、01版の必須要件ではない。

新しい TLV は「何も変わらなかった」という誤認を崩せる。それでも、分布を生んだ出来事を単独では説明できない。原因、継続時間、責任を決める前に、経営層は圧縮で失われた順序を確保しなければならない。

出典