要約

  • RFC 10005はLink Bandwidth Extended CommunityをtransitiveのType 0x00とnon-transitiveのType 0x40で定義し、移行中は両方を同じ値で付加できるとする。
  • 旧実装が一形式しか理解しない環境で片方だけを更新すると、下流は異なる加重転送を行い得る。移行完了の証拠は対応表ではなく、受信属性、multipath集合、FIB重み、実トラフィックの一致である。

設定レビューでは両方のcommunityが見えていた。新装置は二形式を処理し、旧装置は従来から理解する一形式だけを読んだ。途中のルーターがnext hopを変更した際、transitive値だけを再生成し、non-transitive値を以前のまま残した。以後、ネットワークには一つの「正しい帯域」が存在しなかった。

新装置は低い方を採用した。旧装置は自分が理解する方を採用した。別の装置ではローカル設定が優先規則を変えていた。経路はwithdrawされず、BGPセッションも落ちなかったため、一般的な可用性監視には現れない。差はトラフィックの偏りとして初めて見えた。

RFC 10005 は2026年6月にProposed Standardとして公開され、この不整合を運用上の主要課題として扱う。これは新機能を一斉導入する仕様ではなく、既に異なる形式で存在してきた実装を共存させるための規律でもある。

二形式の役割と限界

transitive形式はType 0x00、non-transitive形式は0x40で、SubTypeはともに0x04である。受信機は両形式を処理できなければならず、形式とiBGP/eBGPセッション種別の組合せだけを理由に経路をflapさせたりmalformed扱いしたりしてはならない。

移行中、送信機は各形式を一つずつ同じ経路に付けられる。値は一致すべきである。この「べき」は比較可能な運用条件になる。二つのraw communityを個別に保存し、一致を監視しなければならない。単にLink Bandwidthが存在するかを調べるだけでは足りない。

IANAは両方のTwo-Octet AS-Specific Extended CommunityレジストリでSubType 0x04をLink Bandwidthとして更新した。共通登録は符号化を整理するが、旧ソフトウェアを自動的に更新しない。RFCの付録は、Route Reflectorだけを更新して相互運用性を得ることを目的外と明記する。送信または受信するBGP speaker自身が必要な手順を持つ必要がある。

二つの値はどこで分かれるか

communityはAdj-RIB-In処理で付加・更新でき、Adj-RIB-Outでも付加・更新できる。next hopを変更して再広告するspeakerは、値を削除、保持、または再生成できる。実装は既定動作を示し、session単位で他の選択肢を与えるべきである。next hopが変わらないroute reflectionでは、値を変更すべきではない。

この自由度は、一形式しか認識しない旧装置との組合せで危険になる。ポリシーが「Link Bandwidthを更新する」と記述されていても、実際にどちらのTypeへ作用するかは実装とリリースで異なり得る。片側だけが新しい値になると、下流は自分の理解できる形式によって別の重みを得る。

RFCは、旧実装が残ると分かっている場合、旧speakerの広告時に未対応形式をfilterするか、送信側の能力を知る受信機が未対応形式をstripする案を示す。重要なのは能力を推測しないことである。装置、リリース、address family、session方向ごとの実測マトリクスが必要になる。

値の一致だけでも十分ではない

Local AdministratorにはIEEE 754の32-bit浮動小数点が入り、単位はbitではなくbyte/秒である。Global Administratorは二オクテットで、付加するrouterのASNが推奨されるが任意値も可能で、四オクテットASN全体は表現できない。Global Administratorは意味を変えず、認証でもない。

さらにRFCは値の算出方法を範囲外に置く。現在のuse-case draft v11は、remote bandwidth、local link bandwidth、両者の関数を区別し、集約経路やserver数も例示する。同じraw値が同じTypeで届いても、何を表すかは一致しない可能性がある。

受信側では、全multipath候補が非ゼロ値を持つとき、その値または比率を重みに使える。ゼロと非ゼロの混在、全ゼロはlocal policyで決まる。どれかのpathに有効値がなければ、local overrideがない限りequal load balancingが推奨される。負値は無視し、ゼロはmalformedではない。

複数communityがある場合、既定ではtransitivityを無視してゼロを含む最小値を使うが、設定で変更できる。この規則は二形式不一致を安全側へ寄せることはあっても、全装置の結果を統一しない。旧装置は片方しか見ず、local overrideは最小値規則を変えられるからである。

移行をrunning stateで判定する

まず全peerについて、受信した二形式とpolicy後の二形式をraw octetで採取する。next hop変更の有無、remove/retain/regenerateの実効動作、Global Administrator、decoded value、値の生成元を記録する。設定文ではなくAdj-RIB-InとAdj-RIB-Outを比較する。

次にmultipath候補、選定理由、zero/missing/multiple処理、FIB memberとhardware weightを保存する。最後にflow比率、queue、loss、latency、application結果を重ねる。二形式が一致していてもFIBが期待通りでなければ移行は終わっていない。

Juniper、Cisco、Aristaの現行資料はtransitivity、interface由来、policy値、再生成など異なる制御面を示す。これはversionごとの試験が必要である根拠であり、相互互換性の証明ではない。

Heng LuのRunning-Code Primacyを適用すれば、機能表やRFC準拠宣言より、実際に受け取って転送に使う状態が優先される。Minimum Initial Specificationは共通層を決定的な符号化と安全な相互運用に限定し、将来の導入判断を運用者へ残す。

同じ経路に二つの値を載せるのは移行手段であって、整合性そのものではない。