要約

  • draft-ietf-idr-bgpls-inter-as-topology-ext-46 は、Inter-AS Link NLRIと遠隔AS／ASBR記述子を定義し、BGP-LS利用側が接続の両側から来た情報を照合できるようにする。
  • 完成したリンクは一個の直接観測ではない。IGPまたはローカル設定、BGP-LSへの写像、フィルター、識別子、鮮度、利用側の照合規則から作られる派生状態である。
  • そのエッジを経路制御に使うなら、両入力と判断理由を残す相関レシートが必要だ。稼働、容量、経路投入、実転送は別のレシートで確認する。

境界にだけ存在する空白

BGP-LSで各IGPドメインを収集すれば、AS AとAS Bの内部は詳細に見える。それでも二つをつなぐ線は得られないことがある。IGPは通常、Inter-ASリンク上で動作しないからだ。ASBR自身は相手を知っていても、従来のBGP-LS表現だけでは利用側がその関係を取り込めない。

rev46はNLRIタイプ7を新設し、Remote AS Number、IPv4 Remote ASBR ID、IPv6 Remote ASBR IDを記述子として定義する。元になる情報は、RFC 5392のOSPF Inter-AS TEやRFC 9346のIS-IS Inter-AS Reachabilityから得られ、RFC 9552のBGP-LS手順で運ばれる。

草案が描く完成形は、片側の広告だけではできない。通常は両端から学んだ情報を、ローカル／リモートAS、ASBR識別子、BGP-LS Instance Identifier、必要に応じてインターフェース情報で突き合わせる。合わなければ、利用側に残るのは未ペアまたは不完全なリンクである。

ここでコントローラーは単なる表示装置ではない。「この二つは同じ接続である」という新しい主張の作成者になる。

片側ずつ異なる根を持てる

基本手順では、ASBRがOSPFまたはIS-IS内でInter-AS情報を広告し、BGP-LS speakerがそれを受けてNLRIにする。さらにimport/export policyを通って利用側へ届く。片側だけがフィルターされても、各装置は自分の規則どおり正しく動作している場合がある。

別の手順もある。ASBR自身がBGP-LS speakerであれば、直結インターフェースや静的ルートを根拠にNLRIを作り、Protocol-IDをDirectまたはStatic configurationにできる。利用側はAS番号とアドレスで反対側と対応させる。

つまり、同じ形の二つの広告でも、片側はIGPの更新・洪水・撤回に従い、もう片側は人間の設定変更に従うことがある。最終的な記述子だけを保存すると、鮮度と責任の違いが消える。

最低限の相関レシートには、各広告の安定参照またはハッシュ、source protocol、BGP-LS instance、local/remote ASとASBR、補助的なリンク記述子、受信時刻、年齢、撤回状態を含めたい。その上で、照合規則、policy version、paired／unpaired／conflicting／staleという判断を記録する。

これは本稿の運用提案であり、Internet-Draftの必須要件ではない。目的は中央集権的なトポロジー台帳ではなく、ローカル判断を後から検証可能にすることだ。

解析成功から転送成功までは遠い

証拠を一段ずつ分けると、少なくとも九つある。実際の接続と設定、OSPF／IS-IS／ローカル記述、BGP-LS speakerの受信とNLRI生成、policy通過、consumerの解析、二側面の相関、snapshotへの採用、経路計算と投入、最後にパケットとサービス結果である。

一段の成功は次段を代行しない。IANAのコードポイントは共通の番号を与える。構文妥当性はデコードできることを示す。ペア成立は二つの文が規則に合ったことを示す。そこからリンクの現時点の稼働、帯域、経路投入、配送を推測してはいけない。

rev46は2026年9月29日付のIDR作業部会Internet-Draftであり、RFCではない。凍結した資料には公開導入、相互運用試験、測定された転送結果がない。IANAのBGP-LS registryにあるearly allocationは実装準備を助けるが、運用の正しさを認証しない。

非対称は欠陥ではなく観測状態である

この拡張は段階導入できる。AS内の全ルーターではなく、元情報を生成する装置、BGP-LSへ輸出するspeaker、NLRIを処理するconsumerが対応すればよい。導入しやすい一方で、片側だけ見える状態は十分起こり得る。

一方のASBR IDが欠ける。片方だけpolicyで落ちる。sessionの遅れで更新順が逆転する。一方が撤回済みでも他方が残る。双方の運用者は同じ回線だと思っていても、記述子が一致しない。

草案は、両ASBRの元情報、OSPF／IS-IS広告、BGP-LS speakerでの受信と輸出、識別子整合、policyの順に確認するよう促している。また相関できたかを運用可視性として示すことを勧める。

その状態を単一の「link present」に丸めるべきではない。paired、unpaired、conflicting、stale、withdrawing、unsupportedを区別すれば、不完全性自体が診断情報になる。

時間の違う二行が、偽の同時刻を作る

相関にはsnapshot境界が必要だ。A側の広告が09:00に届き、B側が09:04に届く。09:02にA側が識別子を変更し旧広告を撤回していても、撤回の到着が遅れれば、09:04のデータベース上では一致する二行がそろう。だが実際のネットワークでは同時に有効だった瞬間がない。

草案は普遍的な鮮度窓や撤回policyを定めない。多様な運用に適した判断だが、責任はconsumer側に残る。許容時間差、片側保持時間、撤回時の削除またはconfidence低下、採用したsnapshot IDを記録しなければならない。

「両端が一致した」は、宣言した時間窓で共存したという意味で使うべきだ。単にテーブルに二行残っていた、では足りない。

機密性と監査性は両立できる

想定の中心は、一つの管理主体がbackbone、metro、data centerなど複数ASを運用するwalled gardenである。草案は、Inter-ASのアドレスや識別子がcritical network informationであり、管理境界内に制限するか、外へ出る前にfilterすべきだとする。

相関レシートを公開台帳にする必要はない。内部参照やハッシュ、role-based access、限定retentionで保護しながら、権限ある監査者だけが判断を再構成できる。Minimum Initial Specificationの発想なら、共有すべきなのは全地図ではなく、比較できる最小の判断材料である。

完全なレシートでも証明するのは地図の採用だけだ。RFC 8735のmulti-domain TEは、なぜ横断トポロジーが経路計算に必要かを示す。計算後にはprogramming、convergence、forwarding、service outcomeが続く。それぞれ独立に観測する必要がある。

線を否定できるテストを作る

Running Code Primaryに沿う受入試験は、NLRIを読み取って終わらない。独立した二実装に、正常なペア、remote ASBR不一致、片側filter、更新順逆転、遅延撤回、IGP由来とstatic由来の組み合わせを投入する。どのエッジを作成・劣化・削除・復旧したか、その理由まで比較する。

最終図が同じでも、時間窓や競合処理が違えば障害時に分岐する。相互運用とは平常時の一本線ではなく、異常時の同じ説明可能な遷移である。

結論は簡単な「リンクあり」から変わる。コントローラーは、この時間窓で、この出所を持つ二つの文を受け、この規則で照合し、未解決の矛盾がないため、このsnapshotに採用した。経路投入とパケット観測は別記録である。

図は短い。運用責任は短くない。

出典

  1. BGP-LS Inter-AS Topology Retrieval rev46
  2. 文書履歴
  3. RFC 9552
  4. RFC 5392
  5. RFC 9346
  6. IANA BGP-LS Parameters
  7. Lu Heng — Minimum Initial Specification
  8. Lu Heng — On Reality Layers
  9. Lu Heng — Running Code Primary
  10. rev46 HTML
  11. rev46 プレーンテキスト
  12. rev45からrev46への公式差分
  13. RFC 7426 — SDN用語
  14. RFC 9086 — BGP-LS Egress Peer Engineering