要約

  • 10月28日の個人草案は、広告元ルーターのIDを4バイト、出口グループIDを2バイト載せるBGP拡張コミュニティを提案する。対応する入口ルーターが、遠隔のグループ番号を自分のECMP回線群へ対応づける。
  • 図のタイプ欄は 0x83、サブタイプは TBD。一方、IANAの現行登録表は 0x83–0x8f を実験用に予約している。恒久的なタイプ番号をどう得るかは草案に書かれていない。

宛先が付けた札で、入口の回線を選ぶ

通常のECMPはフローをハッシュで等コストの回線に振る。巨大なフローが少数しかなければ、同じ回線にぶつかることがある。パケット単位で分けると今度は順序が乱れる。対になる強化ECMP草案は、入口ルーターの回線を複数の小組に分け、組を選んだ後で組内の振り分けを行う案を示す。図中の回線数は設計例だ。

その組を選ぶ手掛かりをBGP経路へ載せるのが今回の草案だ。出口側の装置は自分のRouter IDと出口グループ番号を広告する。入口側は受け取った番号を、自分で設定した回線の小組へ写す。遠隔の番号を決める人と、実際のポートを決める人は同じではない。経路に札が付いているだけでは、パケットがどの回線を通ったか分からない。

札の名前にも問題がある。草案の形式図は先頭バイトを 0x83 と固定している。IANAが公開する転送可能な拡張コミュニティの登録表では、その範囲は実験用だ。サブタイプも未定のまま。IANAへの要請は新しいGroupIDサブタイプに触れるが、実験用タイプを恒久割当へ移す手順を示さない。試験の札と、異なる実装が長く共有する札は同じ扱いにできない。

IETFの状態は個人草案だ。非対応ルーターはこの属性を無視し、通常のECMPを続けられる。セキュリティ節も TBD。実装間試験や通信改善の測定結果は示されていない。番号の割当を明確にした改訂と、受信した札、入口での対応表、実際の回線を結ぶ試験記録が次の判断材料になる。

出典：Group ID草案、強化ECMP草案、IETFの状態、IANA登録表。