要約

  • RFC 9819はRFC 9252を更新する。Ethernet A-D経路とInclusive Multicast経路のSID構造が同一である場合に限り、単純なビットORで意図したEnd.DT2M Service SIDを構成できるからだ。
  • ESI Filteringでは、Inclusive Multicast経路がLOC:FUNCと引数の挿入境界を所有し、Ethernet A-D per ES経路がArg.FE2を供給する。非ゼロのArgument Lengthが一致することは必要条件だが、構造全体の一致を意味しない。
  • 2本の経路を受信し解析できたことは制御プレーンの証拠でしかない。関連付けの鮮度、ローカル選択、FIBやLocal SIDのプログラム、Split Horizonの実行、正しいBUM配信までは証明しない。

障害票には「両経路あり、属性は妥当、SIDは計算済み」と書きやすい。しかし本当に閉じるべき問いは一段細かい。どちらの構造に従って計算したのか。

RFC 9252は当初、EVPN Ethernet Auto-Discovery per Ethernet Segment経路のESI Filtering Argumentと、Inclusive Multicast Ethernet Tag経路のEnd.DT2M SIDをビット論理ORで結合する手順を示した。双方の有効ビットが同じ位置にあるなら成立する。RFC 9819は2025年7月、実装と相互接続の経験から、SID構造が常に一様だという前提には曖昧さがあると明記した。

パケット形式上の修正は小さいが、証拠の意味は大きく変わる。構文的に正しい2つのBGPオブジェクトも、128ビット値を機械的に混ぜられるというだけでは有効な転送命令にならない。受信側は、どの広告がService SIDのレイアウトを所有するか、引数を受け入れるか、何ビットか、どこから始まるか、どのサービスとの対応が利用を正当化するかを知る必要がある。

一つのSIDに二つの意味の供給元

RFC 8986はSRv6 SIDをLocator、Function、任意のArgumentに分ける。End.DT2MはEthernetペイロードをデカプセル化し、L2テーブルへフラッディングする。Arg.FE2はローカルでEthernet Segment Identifierへ対応付けられ、Disposition PEが該当する出力インターフェースを除外してSplit Horizonを維持するために使われる。

RFC 9819では役割が明確だ。EVPN Route Type 3であるInclusive Multicast Ethernet Tag経路は、ブロードキャストドメイン用End.DT2MのLOC:FUNC部分を広告する。Route Type 1のEthernet A-D per ES経路はESI Filtering引数を広告する。引数を持つBehaviorなので、双方がSRv6 SID Structure Sub-Sub-TLVを伴う。

Structureは説明用の飾りではない。Locator Block Length、Locator Node Length、Function Lengthから引数開始位置が決まり、Argument Lengthから許容サイズが決まる。LOC:FUNCを所有するエンドポイントがその構造を広告し、SR Sourceが完全なLOC:FUNC:ARGをIPv6宛先またはSRH Segmentとして構成する。

RFC 9819の複数ブロードキャストドメインの例では、引数はいずれも16ビットだが、一方のType 3 Service SIDのFunction Lengthは32ビット、もう一方は16ビットである。同じ引数でも挿入オフセットが異なる。したがって盲目的なORは中立な操作ではなく、オフセット一致を暗黙に仮定する操作である。

緑色のパーサーより判断分岐を見る

Type 3がAL=0を広告する場合、そのService SIDはESI Filtering引数を期待しない。Ingressは後続ビットをゼロとしてLOC:FUNCを作り、Type 1のSID値と構造を無視する。画面に引数が見えていても、転送判断には使ってはならない。

Type 3のALが非ゼロなら、Ingressは対応するEthernet A-D per ES経路を探し、End.DT2Mを確認する。経路がない、またはType 1のAL=0なら利用可能な引数はなく、LOC:FUNCのみへフォールバックする。Filteringが期待されていた場合はログに残すべきだ。

双方のALが非ゼロで異なるなら構成不整合である。引数は利用できず、ループの危険があるため、そのEthernet SegmentからのBUMトラフィックを転送してはならない。一致する場合は、Type 3構造が示すオフセットへType 1引数を挿入し、宣言されたSIDの後ろをゼロにする。

AL一致はゲートであって、万能な互換証明書ではない。引数が所有者の広告したフィールドに収まることを示すだけで、全レイアウトの同一性、目的のEthernet Segmentとの対応、完成アドレスのエンドポイントへの導入は証明しない。

合成より先に同一性と時刻がある

RFC 7432は、Route Distinguisher、Route Target、Ethernet Tag、ESI、発信PE、WithdrawといったEVPNの文脈を定める。これらは管理上の付記ではない。新しいLOC:FUNCを、別セグメント、別ブロードキャストドメイン、別世代の引数と結び付けないための境界である。

合成証跡には、受信した2経路と採用した関連付けを記録する必要がある。「Type 1とType 3がある」だけでは弱い。どのOriginatorが、どのEVIとEthernet Segmentについて、どのBest Pathを、いつ、どのWithdraw後に、どのEnd.DT2M Flavorで広告したかを残す。経路受信は鮮度ではなく、現在のRIBも下流キャッシュやプログラム済みオブジェクトが同じ世代を使った証明にはならない。

RFC 9800は圧縮SIDリストのBehaviorを定める。RFC 9819はAL検査に通る限り、圧縮型と非圧縮型のEnd.DT2M Flavorが関連広告に現れることを許すが、FlavorやStructureを証跡から消してよいとは言わない。RFC 9252のTransposition Schemeも変わらず、MPLS Labelフィールドで可変ビットを運ぶ場合には、Offset、Length、Field Limitが独立した検証入力である。

構成済みSIDはネットワーク結果の手前で止まる

RFC 9819が直接規定するのは、シグナリング、整合性検査、構成である。正しい計算がPolicyに選ばれ、Hardwareへ書かれ、Packetに実行されたとは主張しない。それぞれは後段の権威である。

Ingress側には、対応Behavior、Feature Version、選択した構成方法、Path Eligibility、完成した128ビット宛先とProgramming Generationの記録が要る。Egress側には、該当Local SIDが意図したEnd.DT2M Flavor、L2 Table、現在のArg.FE2対応を呼び出す記録が要る。その後で初めてPacket証跡が、デカプセル化と正しい出力インターフェースの除外を示せる。さらに結果層では、期待する受信者への到達、発信Segmentへの逆流がないこと、同じ観測期間に重複やループがないことを確認する。

この境界は隣接標準との混同も防ぐ。RFC 9819は、RFC 9830のBGPからSR Policy ManagerへのCandidate選択、RFC 9863のPCEP Color、RFC 10039のInterdomain D-PATH、RFC 10018のP2MP TreeとLeaf配信Lifecycleを扱わない。それより前の狭い問い、すなわち共有構造を捏造せずに二つの広告成分を目的のService SIDへできるかを扱う。

Heng LuのMinimum Initial Specificationは、共通ルールを決定的かつローカル検証可能にし、その先の運用判断は当事者へ残すという編集上の規律を与える。Running-Code Primacyは公開仕様と稼働状態の境界を示し、Reality Layersは記号上の合意を物理的な作用と取り違えないよう促す。これは筆者の分析枠組みであり、IETFの意図についての主張ではない。

防御可能な証拠列は八段階になる。経路の同一性と鮮度、BehaviorとStructure、経路間対応、正確な構成、ローカル受理と選択、IngressとEgressのプログラム状態、Packet実行、観測されたService結果。RFC 9819はこの中段をビット演算だけで装うことを難しくした。一個の緑ランプに短縮したわけではない。

出典