要約

  • 第 34 版では、対応するピアが Site Physical Availability の 0% を受信すると、その Site-ID に関連づけられた全経路を転送不能として扱う。個々の経路を withdraw したのと同じ効果を、個別の撤回なしで生む。
  • 同じ経路は通常の BGP では有効なままでもよい。認可された送信元、対応表の世代、各ルーターの判断、RIB、FIB、実フロー、サービス結果を一枚の経路表で代用してはならない。

09時14分、あるエッジサイトで最後の稼働可能なサーバーが失われる。出口ルーターは Site-ID と物理可用性ゼロを載せた BGP UPDATE を一通だけ送る。入口ルーターの BGP 表には数十のプレフィックスが残るが、メタデータを使うサービス転送の候補からは一斉に外れる。withdrawal の列は流れない。ルーティング担当には経路が見え、サービス担当にはサイトが消えて見える。

この二つの状態を同時に成立させる点が、BGP Extension for 5G Edge Service Metadata 第 34 版の重要な変更である。改訂は 2026 年 9 月 25 日に受理され、表紙の日付は 9 月 23 日。IDR ワーキンググループの Internet-Draft で、Datatracker 上は I-D Exists にとどまる。表紙は Standards Track とする一方、Datatracker の Intended RFC status は空欄である。shepherd、担当 Area Director、telechat はなく、2027 年 7 月のマイルストーンが WGLC を目標にする。RFC でも、割り当て済み IANA コードポイントでも、実装・相互接続・展開の結果でもない。

一通の更新が過去の対応表を引き受ける

案は optional non-transitive な Edge Metadata Path Attribute を定義する。サービスのプレフィックスは 16 ビットの Site-ID と関連づけられる。その後、サイトの動的な属性を単独更新で伝えれば、全経路に同じデータを重ねる必要がない。単独の Site Availability UPDATE では出口ルーターのループバックを NLRI とし、RouteFlag-I をゼロにする。受信側がすでにその Site-ID へ結びつけた経路が対象になる。RouteFlag-I が一なら関連づけ用のメッセージであり、可用性の百分率は無視される。

第 34 版はゼロの扱いを強くした。機構に対応する speaker は、関連する全経路を転送に利用できないものとしなければならない。案はその効果を各経路の個別撤回と同等と説明するが、個別 withdrawal は送らない。Edge Metadata に対応しないピアから同じ経路を消すには、通常の BGP withdrawal が依然として必要だ。

したがって「同等」とは、メタデータ機構の選択結果が同じという意味であり、通常の BGP 状態まで同一になるという意味ではない。案の別の箇所では、メタデータに基づく選択から外れた経路が、通常の BGP 到達性には有効であり得る。プレフィックスは RIB に存在しつつ、特定のエッジサービスには不適格になる。この分離は経路変動を抑え、サービス健全性と到達性を混同しない。その代わり、セッションが緑で経路が存在するという二つの表示だけでは、サービス提供を証明できない。

ゼロ値の対象はメッセージの中にない

単独更新は影響を受けるサービスプレフィックスを列挙しない。作用範囲は、受信側が以前に受け取った「経路と Site-ID の対応」に依存する。入口 A が Site-ID 711 に 42 経路を結びつけ、入口 B が過去の更新を逃して 41 経路しか持たなければ、両者は同じゼロ値を正しく解釈しながら異なる集合を止める。

そのため、「Site-ID 711 = 0 を受信」という記録だけでは足りない。必要なのは、経路キー、発効時刻、生成した speaker、受領を確認した判断点を含む対応表の世代である。解決した対象数とダイジェストを残せば、プロトコルに内部選択の全明細を載せずに、意図した集合と適用した集合を比較できる。

世代番号、確認、件数、ダイジェストは本稿が提案する運用上の制御であって、第 34 版の規範要件ではない。案が定めるのはプロトコル動作であり、全ルーターの受領証明システムではない。ローカルテレメトリー、コントローラー状態、署名ログなど実装の選択肢は残せる。しかし「ゼロが何に効くはずだったか」は、後から再現できなければならない。

送信元の認可が遠隔停止を防ぐ

受信側は、該当する出口ルーターから来た単独更新、または、その出口を Originator-ID で示す認可済み route reflector からの更新だけを受け入れる。偽造または誤ったゼロ値は、関連する全経路を利用不能にして denial of service を起こし得るため、この条件は単なる形式ではない。

BGP セッションが正しいことと、その制御行為が認可されていることは別の証拠である。reflector は正規の隣接でも、想定外の Originator-ID を載せる可能性がある。出口ループバックが到達可能でも、セッションの役割は違うかもしれない。認証済みピア、AFI/SAFI、双方で合意した Edge Metadata Processing Capability、出口の識別、Originator-ID、Site-ID、属性の生データ、ポリシー判断を分けて保存すべきだ。

能力は AFI/SAFI ごとに双方向でネゴシエートする。属性は optional non-transitive で、NO_ADVERTISE、AS-Scope sub-TLV、通常の経路フィルターが範囲を抑える。未知または非対応の sub-TLV は無視され、値の欠如をゼロと解釈してはならない。これらは誤拡散を減らすが、全入口が能力を持つことや、非対応ピアへ通常の撤回が届いたことまでは証明しない。

測定、通知、適用、フローには別の時計がある

Site Physical Availability はゼロから 100 までで、範囲外の値は無視される。案は測定間隔と広告間隔を分け、特別な設定がなければ広告間隔の既定最小値を 30 秒とし、dampening や hysteresis を勧める。フロー親和性は実装依存で、すでに選ばれた出口が本当に到達不能になるまで既存フローを残すこともできる。

サイトが 09:14:00 にゼロを測り、出口が 09:14:12 に広告し、一つの入口が 09:14:13 に適用し、固定されたフローが 09:15:00 に終了することは矛盾ではない。すべてを「ゼロ発生」と一括りにすると、測定された事実、配布された制御、実行、利用者体験の距離が消える。

単独更新は next-hop resolution の通知でもない。関連サイトのサービス選択を変えるだけで、出口ループバックの到達不能や BGP 収束を意味しない。証拠は、測定源、認可された起点、対応表世代、能力合意、更新受信、対象集合の解決、ローカルポリシー、RIB と FIB、フロー処理、サービス結果の順に積み上げる必要がある。

最小仕様と実行証拠を組み合わせる

Heng Lu の最小初期仕様の考え方は、協調に必要な最小の共通部分だけを標準化し、将来およびローカルな判断を各運用者に残す。ここではサイト識別、可用性の意味、許容される送信元、スコープが共通部分になり得る。測定アルゴリズム、順位付け、fallback はローカルのままでよい。running code の優先は次に、その意味が転送判断へ変わる境界を観測可能にするよう求める。

展開時には、対応表の世代 ID、影響経路数とダイジェスト、判断点ごとの適用受領、ゼロ遷移時の canary フローを要求したい。これは本稿の運用提案であり、draft の要件ではない。初期仕様を中央集権的なコントローラー設計に膨らませず、独立した検証を可能にする。

ゼロ値は、複数の withdrawal を省けるから強力である。制御が短いほど、実行証拠は精密でなければならない。RIB、メタデータエンジン、利用者は、同時に別々の真実を示し得る。三つを照合できて初めて、運用上の信頼が成立する。

情報源