要約

  • 10月28日付の帯域幅を考慮する弾性ルーティング案は、混雑時の迂回後にトラフィックを戻す条件を改めた。
  • 新しい条件は全トラフィックが主経路へ戻り、利用率が復旧後の閾値以下であることを求める。だが案は、その移動そのものを復帰と定義している。

混雑から逃がす手順はある。戻す手順の入口がない

束ねた回線の一部が故障しても、リンク全体は生きていることがある。経路計算上は最短のまま、実際の帯域だけが減る。改訂された提案は、このずれに対し、出口で混雑を検知したノードがトラフィックを代替経路へ分散させる仕組みを描く。迂回にはSegment Routingの厳密な経路を使い、UCMPの重みは経路の空き帯域と利用率に応じて決める。中央のトラフィックエンジニアリングを待たずに現場で動けることが狙いだ。

しかし、迂回はいつ終わるのか。第4.4節は復帰を「代替経路から主経路へトラフィックを移すこと」と定める。その直後の条件1は、すべてのトラフィックが主経路へ戻った後、その利用率が復旧後の閾値を超えないことを要求する。条件2は、その状態が設定可能な期間続くことを求める。始めるための条件が、終わった後の状態を記述している。

7月の旧版には、復帰を開始する方法が二つあった。混雑リンクの利用率が復旧閾値を下回ったとき、またはローカルリンクが全トラフィックを混雑なく運べると動的に判断したときだ。どちらも一定期間の継続を求めた。10月版はこの二つを削除し、全量が戻った後の状態を条件にした。全体説明には閾値を下回ると戻すという趣旨が残るが、詳細な手順は最初の一歩を指定しない。

全量が戻った場合の負荷を事前に推計するつもりかもしれない。少量ずつ戻し、再び混めば引き返す方式も考えられる。現行の第4.4節には、推計式も試行手順も書かれていない。迂回中の主経路が空いて見えることは、全量を受け入れられる証拠にはならない。必要なのは移動前に実行できる判定であり、次版にそれが加われば、この指摘の対象は消える。

IETFの記録では、これは個人提出のインターネット草案である。現場の障害を報じているわけではない。それでも、復帰条件は提案の中心にある。混雑への判断を現場のノードに任せるなら、迂回を終える判断もそのノードが持つ情報で行えるようにしなければならない。出口だけを描いて、扉を開ける条件を未来に置いている。

出典