要約

  • PIM決定的ECMP草案の第01版は、送信元とグループに上流ルーターIDまたは四バイトのColorを加えてハッシュし、葉ルーターに同じ上流を選ばせる。狙いは等コスト経路上の重複したストリームを減らすことだ。
  • Arista互換の付録は私用HelloオプションとColorのリトルエンディアン計算を記す。本文の公開方式はネットワークバイト順を使い、Ciscoの付録にはルーターIDを使う別の計算がある。
  • 公開Colorオプションの番号はまだTBD。混在環境で一つの木ができたかどうかは、各葉が受けたHelloと実際のJoin宛先で確かめる。

余分なトラフィックは、最初のデータパケットより先に生まれる。葉・スパイン構成で複数の葉が同じマルチキャスト送信元へ等コストで到達できるとき、各葉はPIM Joinを送る上流の隣接ルーターを選ぶ。RFC 7761は逆方向経路とJoin状態を定めるが、この同点を全葉で同じように解く方法までは決めていない。葉ごとの選択が割れれば、一つのストリームが複数の上りリンクに載りうる。

草案は二層網向けに、送信元S、グループG、候補のルーターIDを組み合わせたハッシュを提示する。最大値を選び、同点ならローカル情報で決める。ただし「決定的」という名は、候補集合と入力値と計算手順が一致して初めて意味を持つ。ある葉だけが別の隣接候補を見ていれば、それぞれが正しく動いていても勝者は割れる。

三層網ではColorが登場する。中間層ルーターは、接続先の上位スパインを示すような四バイトのColorをPIM Helloで知らせられる。葉はS、G、Colorを比較材料にする。草案はColorを通知しない隣接をこの選択から外す。つまり導入の順番がそのまま選択肢の変更になる。半分のインターフェースだけを更新した期間には、同じトポロジーでも葉ごとの候補が変わる。

Arista EOSの既存実装は私用Helloオプション65001と65002を使う。前者は固定値で私用形式を示し、後者がColorを運ぶ。公開オプションの番号は未割当てだ。草案は、標準に従う実装が私用形式を既定で送受信しないよう勧める一方、インターフェース単位の互換設定を認める。便利な移行つまみだが、その設定をどの隣接でいつ変えるかを記録しなければ、実際に比較された候補は分からない。

さらにColorの値をハッシュへ入れるバイト順が違う。提案された公開方式はネットワークバイト順、Arista互換方式はリトルエンディアン。候補に私用Colorを広告する装置が一台でもあれば、草案はArista互換の計算を使うよう求める。これは橋渡しの規則であり、現場の全機器が同じ橋を渡ったという観測結果ではない。管理画面に同じ数値が表示されても、ハッシュに渡った四バイトまで一致したとは限らない。

Ciscoの付録は、ルーターIDによる選択にRFC 7761のRPハッシュを独自に使い、同点ではRFC 6395のインターフェースIDを使うと記す。草案本文の中心方式はJenkinsハッシュとローカル情報を使う。差が実運用で木を割るかは、具体的な(S,G)ごとに候補、Hello、ハッシュ入力、選ばれた上流を並べれば判定できる。スパイン障害後にも同じ表を採れば、切替時の振る舞いまで見える。

草案はRFC 6754のECMP Redirectとも比較する。Redirectは最初のJoinの後、上流から別の経路へ送り直す方法だ。稼働中のフローを動かす可能性がある。共通ハッシュは最初から同じ上流を選ぶことで、その修正を避けようとする。ただし共通の候補と計算が揃っていることが前提になる。調整を後で行うか、事前の相互接続試験で引き受けるかという違いだ。

草案に帯域節約の実測値はない。確認すべき点は明確である。Joinがどの隣接へ届き、同じストリームが何本のリンクに流れたか。Colorを掲げた設計より、その二つの記録のほうが容量判断に効く。

PIM草案第01版 · RFC 7761 · RFC 6395 · RFC 6754