要約

  • RFC 10018では、MVPNまたはEVPNのA-Dルートが<Root, Tree-ID>でSR P2MP P-tunnelを広告し、リーフ集合を更新できる。これは制御面の所属証拠であり、同じPTIが全ノードに実装され、正しいサービスのペイロードが各リーフへ届いたことまでは証明しない。
  • 完了判定は、candidate pathとInstance-IDを固定したうえで、サービス上の予定、A-D、コントローラ受理、Replication segment実装、FIB、OAM、MVPN/EVI別の実ペイロードをリーフ単位で一致させる必要がある。離脱時には撤回・削除・静穏化までを逆向きに証明する。

最後のリーフから逆算する

P2MPサービスを評価するとき、Rootから順に見るのは自然だ。広告が出た。コントローラが計算した。Rootがパケットを投入した。多くのリーフでカウンタが増えた。そこまで揃うと、変更は成功したように見える。

ところが、運用上の契約は最後のリーフにある。十二番目の拠点が無受信なら、十一拠点の成功でその事実は消えない。集約トラフィックが正常でも、欠けた一拠点がバックアップ、規制対象地域、重要顧客であれば影響は非対称だ。

したがって調査は、最後の受信結果から逆算した方がよい。このリーフは正しいMVPNまたはEVIでペイロードを受けたか。そのPTIに対するOAMは応答したか。FIBは同じInstance-IDを指していたか。必要なReplication segmentはすべて成功していたか。コントローラの葉集合に入っていたか。A-Dの所属は現行だったか。そもそもサービスの予定集合に含まれていたか。

RFC 10018は、この逆算に必要な共通語彙を与える。MVPNとEVPNがSR-MPLSまたはSRv6のP2MP P-tunnelを使う方法、Auto-DiscoveryルートとSR P2MP Policyの関係、サービス文脈、そして別方式であるingress replicationを規定する。

規格が与えるのは相互運用可能な状態遷移であって、配信の自動保証ではない。この区別を守るほど、どこで証拠が途切れたかを明確にできる。

PTAが表すものは「政策の宛名」である

SR P2MP P-tunnelのPMSI Tunnel Attributeは、<Root, Tree-ID>でSR P2MP Policyを識別する。RFC 10018では、32ビットのTree-IDを先に、その後にRootのIPアドレスを符号化する。Tree-IDはRootの文脈で一意である。IANAはSR-MPLS P2MP Treeに0x0C、SRv6 P2MP Treeに0x0Dを割り当てている。

これは相互運用上きわめて重要だが、PTIそのものの稼働履歴ではない。RFC 9960では、一つのPolicyが複数のcandidate pathを持ち、各candidateはゼロ個以上のP2MP Tree Instanceを持つ。制約を満たすツリーを計算できなければゼロである。make-before-breakでは複数PTIが共存し得るが、アクティブなのは一つだけでなければならない。二つが同時にアクティブなら、リーフへの重複配信が起こり得る。

PTIは16ビットのInstance-IDで区別される。各ノードのReplication segmentは、制御面ではRoot、Tree-ID、Instance-ID、Node-IDを含む識別子に結び付く。つまり、Tree-IDは「どのPolicyか」を示し、Instance-IDは「そのPolicyのどの実体か」を示す。

監視がTree-IDだけを保存すると、古いPTIのping応答が新しいPTIの健康証明に化ける。遅延した実装応答が別の変更に混入する。撤回後の識別子再利用では、過去のパケットと現行状態の境目を失う。宛名が同じでも、配達便は同じではない。

リーフの所属はBGPで変わり、転送は別の場所で変わる

MVPNでは、入口PEが該当するIntra-AS I-PMSIまたはLeaf A-Dを取り込むと、出口PEをSR P2MP Policyのリーフ集合へ加える。ルートがwithdrawされれば除く。出口PEはRoot側の広告を取り込んだ後、LeafまたはBudとして参加し、Leaf Information Requiredが設定されていればLeaf A-Dを広告する。

EVPNではIMET、S-PMSI、Leaf A-Dが対応する役割を持つ。加入と離脱がプロトコルイベントとして表現されるため、「コントローラの中にいつの間にか存在した受信先」よりはるかに監査しやすい。

ただし、A-Dルートが直接FIBを書き換えるわけではない。入口のMVPN／EVPNモジュールはcandidate pathとリーフ集合をSR P2MP Policyモジュールへ渡し、そこからコントローラへ通知する。RFC 10018はPCEP、BGP、NETCONFなどを例示しながら、その具体的な仕組みを範囲外としている。

この境界で版ずれが生じる。BGPでは新しいリーフが見えているが、コントローラは旧集合を計算中かもしれない。withdrawは届いたが、既存PTIの枝は残っているかもしれない。出口自身はLeafとして参加したが、途中のノードがReplication-SIDを拒否しているかもしれない。

必要なのは数ではなく集合と版である。サービス意図版、A-D版、コントローラが消費した版、PTIのInstance-IDを関連付ける。「リーフ数12」では、古い一つと新しい一つの入れ替わりを検出できない。

部分実装を見えない状態にしてはならない

RFC 9960は、Replication segmentの実装が失敗し得ることを明記する。例えばローカルのSID衝突がある。ノードは成功を報告すべきであり、失敗も理由とともに報告することが望ましい。コントローラは上限付きで再試行し、最終失敗では通知すべきである。一部セグメントが失敗したPTIを削除するかはローカル判断で、Rootのセグメントが失敗した場合は削除が推奨される。

したがって「計算済み」「要求送信済み」「一部受理」「全ノード受理」「Root活性化済み」「実転送確認済み」は別の状態だ。単一のACTIVEでは、どこまで進んだか分からない。

RFC 9960が例示する実装順序は示唆的である。リーフと中間ノードを先に実装し、成功後にRootを実装する。Rootを最後の開閉弁にすることで、下流未完成のツリーへの早期投入を抑えられる。ただし、これは特定製品の動作証明ではない。調達時に「何を満たすとactiveになるのか」を問うための基準である。

コントローラはNode-IDごとの要求版、Replication-SID、応答、失敗理由、再試行回数、終端状態、時刻を外部化すべきだ。集約表示は、その明細から説明可能な規則で導かれる必要がある。

正しい枝を通っても、誤ったサービスへ着地できる

Tree-SIDはPTIのデータ面識別子である。RootはペイロードをTree-SIDへ封入し、中間ノードがReplication segmentに従って複製し、リーフがTree-SIDを除いて配送する。

しかし、配送先サービスの識別は別である場合がある。P-tunnelを一つのMVPNだけが使うならTree-SIDで十分な場合がある。複数MVPNで共有するなら、upstream-assigned MPLS labelまたはSRv6 Multicast Service SIDが文脈を提供する。RFC 10018はEnd.DTMC4、End.DTMC6、End.DTMC46を定義し、IANAは76、77、78を割り当てた。SRv6のtranspositionにも条件がある。

よって、パケットが正しいリーフPEまで到達しても、誤ったMVPNへ入る、正しいmulticast table lookupが行われない、service SIDの組み立てを誤る、という失敗があり得る。ツリーの到達性とテナントの正しさは同義ではない。

EVPNのEthernet Segment multihomingではsplit horizonも独立した条件だ。BUMの重複を防ぐため、SR-MPLSではESI label、SRv6ではEnd.DT2MのArg.FE2を使う。リーフで受信したという事実だけでは、本来捨てるべき複製まで受けたかどうか分からない。

最終記録にはPTI、リーフ、MVPN/EVI、サービス識別子、split-horizon状態、想定コピー数、ペイロード結果が必要である。Tree-SIDはツリーへの転送権限を持つが、テナント認可やアプリケーション受領まで代理しない。

Ingress replicationでは証拠の経路が変わる

Ingress replicationは、入口PEが出口ごとにコピーを作り、unicastで送る方式である。RFC 10018ではSR P2MP Policyモジュールとコントローラが関与しない。

このため、同じ監視モデルを流用できない。IRでは、出口の所属、出口が示すサービス識別子、選択されたunicastまたはSR-TE policy、個別コピーと受信を追う。P2MPでは、コントローラ、PTI、縫い合わされたReplication segment、active instance、ツリーOAMを追う。

トラフィックエンジニアリングも異なる。IRは規定された場合に出口ごとの扱いを選べる。P2MPはPTI内で複製されるため、入口はツリー全体に一つの扱いを指定し、各リーフへ別々の扱いを与えられない。

障害時にP2MPからIRへ退避するなら、旧Rootの投入停止、個別コピー開始、重複期間、旧PTI削除を一つの切替記録にする必要がある。「届くようになった」だけでは、二重送信を隠し得る。

OAMの対象名を省略しない

RFC 9961は、SR P2MP Policyのpingとtracerouteを定める。プローブは特定candidate pathとPTIを対象とし、そのReplication segmentを通り、リーフから応答を得る。非activeのPTIも個別に試験できることが望ましい。

make-before-breakでは、旧PTIの成功は新PTIの証明ではない。結果にはInstance-ID、実行時刻、期待リーフ、リーフ別応答を残す。

非隣接Replication segmentでは、P2MP OAMが複製構造を検証し、二つのセグメントをつなぐunicast経路はunicast OAMが検証する。RFC 9961は後者の障害検出を自分の範囲に含めない。一方の成功で他方の未検査を埋めてはならない。

さらにOAMは業務ペイロードではない。プローブ処理は、正しいservice SID、許容損失、split horizon、受信アプリケーションまで証明しない。リーフごとに、連番フレーム、検証可能なコンテンツ印、サービス文脈付き受信カウンタ、またはアプリケーション確認を用意し、同じPTI世代に結び付ける必要がある。

差集合は障害担当を教える

運用では次の集合を分けるとよい。

  • E：サービス契約上の予定出口
  • A：A-D／Leaf A-Dに現れる出口
  • C：現行candidateについてコントローラが受理したリーフ
  • I：同一PTIの必要Replication segmentが成功したリーフ
  • F：active PTIの現行forwardingに含まれるリーフ
  • O：正確なcandidateとInstance-IDのOAMに応答するリーフ
  • D：正しいMVPN／EVIで期待ペイロードを受けたリーフ
  • W：離脱後のwithdraw、削除、静穏化を証明したリーフ

厳格なサービスならactivate前にE = A = C = I = F = O = Dを求める。部分運用を認める場合も、例外対象、理由、影響、責任者、期限、復旧条件を明示する。離脱はactive集合から消え、Wに入って初めて完了する。

E − Aはサービス／A-D、A − Cはコントローラ取込み、C − Iは実装、I − Fは応答とFIB、F − Oは転送または診断、O − Dはサービス文脈またはアプリケーションの問題を示す。

個数の一致だけでは足りない。十二の応答に旧リーフが一つ混ざれば、十二の現行予定を満たしていない。

公開資料から言えないこと

引用したRFCとIANAレジストリは、識別子、手順、失敗の表現方法を裏付ける。特定事業者の採用、製品対応、現在の普及率、障害頻度、実在する「十二番目のリーフ」は裏付けない。

コードポイントの登録は、実装やFIBへの投入を証明しない。Standards Trackは導入命令ではない。IETFは共通意味を定めるが、各社のRootをactivateしない。

この境界はLu HengのRunning-Code Primacyと整合する。文書上の効果は、稼働系の観測で反証可能でなければならない。また、Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionが示すように、共通の初期仕様を保ちながら、導入、例外、失敗予算はローカルに決められる。

ただし稼働状態が正しいとは限らない。離脱済みリーフへ届き続けることも「現実」であり、その現実こそ契約違反を発見する証拠になる。

出典