要約

  • IETFのLSR作業部会が9月29日に公開したL2バンドル・メンバーの遠端識別子草案第07版は、広告する遠端IDを、隣接ルーターが同じメンバーについて広告する非ゼロの32ビットのローカルIDと完全に一致させるよう求める。前版はLLDPのPort ID利用を推奨していた。
  • 改訂版は、LLDPやLACPが相手ポートの発見に役立っても、必要な数値IDをそのまま与えるわけではないと明記した。IGP広告を認証しても、その前段で作られたポート対応の正しさまでは証明できない。

論理的には一本に見える集約リンクにも、物理的なメンバーは複数ある。トラフィックエンジニアリングでメンバー単位の経路を選んだり、障害の範囲を絞ったりするには、片側の一本が相手側のどの一本に対応するかを知る必要がある。IETFのAdvertisement of Remote Interface Identifiers for Layer 2 Bundle Membersは、OSPFとIS-ISでその遠端IDを知らせ、BGP-LS経由でコントローラーにも届けるための案だ。9月29日の第07版で変わったのは、知らせる前に何を「分かった」と言えるかである。

8月22日の第06版は、LLDPで得た隣接ポートのPort IDを遠端インターフェースIDとして用いる方法を推奨し、LACPの番号から導く案も挙げていた。第07版はこの短絡を取り除く。両端のルーターは各メンバーに非ゼロの32ビットのローカルIDを独立に割り当てる。こちらが広告する遠端IDは、向こうが同じ物理メンバーについて広告するローカルIDと同じ数値でなければならない。名称が似ていることでも、同じポートに見えることでもなく、相手が公表した値との一致が基準になる。

理由は識別子の性質にある。LLDPのPort IDはサブタイプによって形式が異なり、32ビットの数値とは限らない。LACPのActor/Partner Port Numberは16ビットで、両端が独立に付ける。こうした情報から相手ポートを見つけることはできるが、相手がL2バンドルのメンバー属性で広告する数値への変換は実装ごとの仕事だ。新稿はその正確な数値をどう取得するかを規定範囲外とし、設定や実装固有の発見方法を認める。LLDPとLACPを禁じたわけではない。

たとえば片側のメンバーAについて、発見したポート名を別の数値IDと取り違えたまま広告したとする。IGPの認証は、その広告をルーターが発したことを確かめても、元のL2発見情報が古くないか、偽られていないか、誤って対応付けられていないかまでは確かめない。第07版の安全性の節はこの信頼境界を新たに明示し、誤った対応が経路選択や障害相関を乱す可能性を述べる。これは起きた事故の報告ではなく、誤りが伝わる仕組みの説明である。

空欄にも意味を上乗せできない。遠端IDがないのは、値を学習していないか広告していないことを意味し、相手にメンバーがない証拠ではない。一方のみが拡張を実装した場合にも起こる。IS-ISの順序付きリストではゼロを「不明」の位置合わせに使えるが、BGP-LSではゼロを有効な遠端IDとして転送しない。伝搬役は意味の検証を担わず、最終的な利用者であるコントローラーが整合性を調べる。部分導入を前提とするなら、不明を不存在と読み替えない設計が欠かせない。

Datatrackerでは第07版は有効なInternet-Draftであり、10月13日までのIESG Last Call中、目標はProposed Standardだ。RFCとして確定したわけではない。リンクごとの広告を既定で無効とする条件は旧版にもあった。今回の焦点は、広告を有効にしたとき、その数値が何を裏付けるかに移っている。

出典