要約

  • 11月2日付のROV測定法の個人草案は、最初の関連RTR更新PDUの送信からBGP RIBとFIBの安定までを一つの時間として測る。もう一つは関連VRPの導入完了から同じ終点までだ。
  • 前者にはRTRの配送、VRPの導入、経路の再検証、BGPの収束が入る。後者は導入後の処理を切り出す。一方だけを報告する場合、どちらか明記するよう草案は求める。
  • 草案の表規模は試験条件であり、付録BにはBIRD/Linux環境での実測値もある。他の装置の速度を示す数値ではない。始点と終点、負荷、反復結果を示さない「高速ROV」は比較材料にならない。

新しいVRPが届いた瞬間、パケットの行き先が変わるわけではない。ルーターはRTRのメッセージを受け、ローカル表を更新し、影響を受けるBGP経路の起点検証状態を見直す。その後、ポリシーに沿って最良経路を選び、FIBを書き換える。運用者が知りたいのは最後の状態に至るまでの経過時間だ。VRP導入後から測れば、前半の待ち時間は成績から消える。

RFC 8210はキャッシュとルーターを結ぶRPKI-to-Routerの交換を定める。RFC 6811はBGP経路の起点をValid、Invalid、NotFoundに分類し、その扱いはローカルポリシーに委ねる。検証状態の変化と転送経路の変化は別の出来事である。配送、導入、再計算、経路選択、FIB更新を「検証遅延」の一語に押し込めると、どの段階を短縮したのか分からなくなる。

草案の第00版はVRPを契機とする収束試験で二つの起点を置く。全行程の時計は、RTRエミュレーターが最初の関連更新PDUを送った時に始まり、BGP RIBとFIBがともに安定した時に止まる。もう一方は、被試験装置が関連VRP更新を導入し終えた時に始まり、同じ安定状態で止まる。前者は新たな根拠が転送に反映されるまでを問う。後者は導入後のBGP処理を切り分ける。

二台の装置が更新後、同じ時刻にFIBを安定させたとする。より遅い起点から測る装置の数値は当然小さい。これは特定のメーカーが数字を操作したという話ではなく、始点の置き方から生じる算術だ。実機について判断するには、同じ試験の中で二つの始点と共通の終点を刻んだ記録が要る。

草案は中間点も指定する。VRP導入試験では最初のRTR更新PDUと装置内のVRP表への反映を記録し、計測できれば最初と最後のVRP導入、バッチ全体の処理時間を分ける。検証遅延の試験では、影響を受けるBGPプレフィックスの状態変化を追う。収束試験では最良経路の選択、経路の撤回や置換、RIBとFIBの最終安定を追う。「検証は数ミリ秒」という数字が真実でも、購買者の求める最終点とは異なり得る。

負荷条件も同じ紙面に必要だ。草案はVRP数について5万、10万、50万、100万という例を示し、BGP経路の試験基準としてIPv4の100万、IPv6の25万にも言及する。アドレス族ごとの試験も、そう記せば認める。これらは実験用の設定例であって、世界の経路表の現況でも製品性能でもない。実際のROA・VRP数、BGP表のカバー範囲、VRPの重なり、プレフィックス長の分布、検証状態が変わる経路数を報告すべきだ。

付録Bには、この区別を確かめられる実測もある。BIRD 2.19.2/Linuxの試験環境で、初期VRPが1,060,368件、対象プレフィックスが1,000件、VRP操作が1,230件の場合、十回の平均は全行程が5,027.552ミリ秒、導入後が4,813.556ミリ秒だった。差の約214ミリ秒が、その環境で遅い起点によって除かれる区間だ。測定時間の大半は導入後にかかっている。この数値を別のルーターの性能として扱うことはできない。起点、負荷、終点を数字と一緒に示す必要がある。

変更が検証構造の一部に集中する場合と広く散る場合では、内部処理は同じとは限らない。草案は両方を試すよう求める。RTR、VRP、BGPを同期させた状態から装置を予熱し、ログ、リアルタイムテレメトリー、背景処理を止めるか抑えて計測を乱さないことも勧める。再現性には有効だが、その静かな実験の値を、監視機能を動かす本番環境の保証値にすることはできない。本番設定での追加試験が必要になる。

草案は勝者も障害事例も示していない。示したのは、時計の目盛りより先に起点を明かすという最低限の規律だ。ROVの設備容量を判断する主な数値は、関連RTR更新の送信からFIB安定まで。導入後の数値は遅延の所在を探すために使う。

ROV測定法草案・第00版 · RFC 8210 · RFC 6811