要約

  • Donald EastlakeによるRouting Area Directorateの早期レビューは9月27日に完了し、評価は「Not ready」だった。一人の査読結果であり、IESGの否決や現行BGP仕様の変更ではない。
  • 第13版草案は、選択したデータプレーンの転送データベースで次ホップを解決することをSHOULD、経路の稼働確認をMAYと記す。確認に失敗した経路を最良経路の候補から外すかは明記されていない。
  • MPLSのラベル、SRのSID、トンネル、再帰的な次ホップ解決では見るべき状態が違う。査読者は実際にパケットが使う状態に照合すべきだと指摘する。

ルータが説明できる経路が、必ずしも送れる経路とは限らない。IDR作業部会の草案は、IPの経路表には次ホップが残る一方、VPNの通信を運ぶMPLSのラベル交換パスが機能しない例を置く。別の出口があっても、機能しない方を選んで広告し続ければ通信は途中で失われ得る。これは設計上の問題を示す仮想例であり、特定事業者の障害記録ではない。

今回のニュースは草案の成立ではなく査読の完了だ。Donald E. Eastlake IIIの本文には9月25日とあり、IETFの記録では27日に完了した。対象のdraft-ietf-idr-bgp-bestpath-selection-criteria-13は、9月14日付の有効なIDR作業部会Internet-Draftのまま。目標はProposed Standardだが、IESGの状態は「I-D Exists」で、会議日は設定されていない。「RFC 4271を更新」との記載も承認された場合に限る。2020年には作業部会Last Callと担当ADの審査を経験しており、今回はその続きを検討する早期レビューである。

第3節の提案は簡潔だ。政策が選んだデータプレーンの転送表で次ホップの到達性を解決することをSHOULDとし、同じプレーンに結び付いたOAMによる経路利用可能性の確認をMAYとしている。どの政策と方式を使うかは草案の対象外だ。Eastlakeは問題そのものを認めつつ、確認が失敗した場合の選路上の意味が抜けていると述べる。現行RFC 4271は、解決できない経路を第2段階の選択から除く。しかし草案は、新しい確認で失敗した経路がその「解決できない」状態に当たると明言しない。査読者が提示したMUSTの文は修正案であって、第13版の要件ではない。

何を調べるかも経路ごとに異なる。MPLSならLDP由来のラベルエントリ、Segment Routingのprefix SID、RSVP-TEやSR Policyのトンネル、ラベル付きBGP経路を通じた再帰的解決があり得る。直結の次ホップではラベルのないエントリを使う場合もある。関連のない転送表に「存在する」と記録されていても、実際のパケット経路を保証しない。査読は、選択済みの方式と転送と同じ再帰をたどる確認を求めている。そうでなければ、同じBGP情報から実装ごとに異なる最良経路を選び得る。

既存規則との関係も未整理だ。RFC 9012は、Tunnel Encapsulation属性に実行可能なトンネルがなければ、その経路をRFC 4271上で解決不能と扱う。査読者は新草案がそこに何を加えるのかを問い、規格同士の矛盾が確定したとは述べていない。また、OAMの稼働信号が揺れると経路の撤回と再広告が増え、誤検知やルータ間の判断差が生じ得ると警告する。IPの逐次転送でのループも懸念であって、実測事故ではない。

運用上は、次ホップが見えるかだけでなく、どの転送方式を選び、そのどの状態を検査し、失敗が候補経路の扱いをどう変えたかをつなぐ必要がある。これはDaniel Kadeの分析上の提案であり、IETFが共通ログを義務付けたという意味ではない。公表資料は導入状況や損失頻度も示していない。

出典