要約

  • SPRING作業部会の草案には、200 Mbpsの負荷を100 Mbpsずつ受け持つ二つのSegment Listが登場する。一方が無効になっても、RFC 9256の推奨条件では候補経路CP1が「有効」のまま残り得る。
  • 草案は有効なリストの最低本数と重みの最低合計を提案する。どちらも満たして初めてCP1を有効とする設計だ。閾値が守る容量を決め、維持するのはネットワーク運用者である。

片側の車線が消えても、信号は青い

200 Mbpsを二つの経路へ半分ずつ流す。それぞれの最大容量を100 Mbpsと想定すれば、平時の計算は合う。片方が使えなくなった瞬間、残る100 Mbpsの経路に200 Mbpsを任せる計算は合わない。それでもSPRING作業部会の提案の例では、候補経路CP1は活動状態を維持し得る。RFC 9256が推奨する有効性の基準は、構成するSegment Listの少なくとも一つが有効であることだからだ。

この矛盾は規格の計算ミスではない。規格が判定するのは経路の存在で、サービス側が心配するのは残存容量だ。運用画面が両方に同じ「有効」という札を貼ると、最も重要な差が消える。通信が実際に詰まったという報告は草案にない。それでも二つの判断を同じものとして扱う危険は、例の数字だけで十分に見える。

例のSR Policy POL1にはCP1とCP2がある。CP1の優先度が高く、有効なので選ばれている。CP1のSL1とSL2にはそれぞれ重み1が与えられ、フロー単位のハッシュで負荷を均等に振り分ける。片方のリストが無効でも、もう一方が残る。RFC 9256の明示的候補経路は、有効なリストをすべて失った時に無効になる。CP1の札はそのまま残り、優先度の低いCP2に選択が移るとは限らない。CP2の容量や、その後の転送結果は、この例からは読めない。

本数で止めるか、重みで止めるか

提案は候補経路に二つの閾値を置く。最初の「Minimum Valid Segment List Count」は有効なリストの最低本数を8ビットで示す。例なら2にすれば、どちらか一方を失った時点でCP1は無効になる。0は追加条件なし、0xffは全リストが有効であることを要求する。次の「Minimum Cumulative SL Weight」は有効なリストの重みの合計についての32ビットの下限だ。SL1とSL2の重みが各1なら、下限2は同じく一方の喪失でCP1を退場させる。こちらも0は追加条件なし、0xffffffffは全リストを要求する。設定された二条件は両方を満たさなければならず、どちらも0ならRFC 9256の仕組みに戻る。

本数は監査しやすい。しかし二本生きていれば容量も十分、という保証はない。太い経路と細い経路を同じ一票で数えるからだ。重みはより柔軟だが、重み1を100 Mbpsと読めるのは草案の具体的な想定のおかげである。重みはトラフィック配分の相対値であり、帯域の測定値ではない。回線の容量が変わっても重みの設定を据え置けば、合計2という表示は古い設備図面を精密に再現するだけになる。

閾値をどこから受け取るかにも持ち主がいる。草案はヘッドエンドが設定、PCEP、BGPなどから制御パラメータを受け取れるとする。具体的なプロトコル拡張は別文書へ委ね、この文書はIANAへの新たな要求を出していない。つまり共通の「正しい値」が配られるわけではない。どのサービスに何Mbpsを約束し、残存経路にどこまで負わせるかは、事業者が決める。コントローラが送った閾値、ヘッドエンドが採用した閾値、運用チームが信じている閾値が食い違えば、そのズレこそ障害調査の入口になる。

故障は一枚の札では表せない

Segment Listが無効になる条件と、候補経路CP1が無効になる条件と、SR Policy全体が無効になる条件は別々だ。RFC 9256では候補経路の有効性が変わると選択をやり直し、有効な候補のうち優先度の高いものを選ぶ。政策全体が無効になるのは、全候補経路が無効になった時である。提案の閾値はその途中、CP1がまだ最後のリストを残している段階で効く。

既存のDrop-Upon-Invalidは政策全体が無効になった後の動作を扱う。こちらの問題はもっと手前にある。容量が足りないまま「有効」なCP1が選ばれ続ける時間だ。閾値によってCP1を外せば、選択をやり直す機会が生まれる。ただし、次に選ぶ候補の能力までこの閾値が証明してくれるわけではない。退場判定と安全な代替先の設計は、別の仕事である。

草案には実運用のトレース、測定負荷、設定値の履歴がない。実際の効果を論じるには、その三点に選択結果を結んだ記録が要る。ここで言えるのは、これまで暗黙だった容量の前提を運用者が閾値として明示できる、ということだ。

出典