要約

  • FXCでは複数回線がサービスラベルを共有できるが、ラベル削減と回線ごとのBGP通知の削減は別の選択である。
  • デフォルト方式は個別ACの障害を通知しない。VLAN通知方式は正規化VIDとESの対応を残し、対象トラフィックの経路変更を可能にする。
  • 復旧は顧客回線への実際の配送と、影響を受けない回線の継続で確認すべきであり、共用トンネルの稼働だけでは判断できない。

試験で何を壊したか

冗長構成の試験結果に「切り替え成功」と記載されていても、切断したものがポートなのか、一本の接続回線なのかで意味は変わる。多数のサービスを共用トンネルに載せると、この違いを見落としやすい。大きな障害を処理できたことは、小さな障害を識別できたことの証明ではない。

2025年3月に公開された RFC 9744 は、EVPN-VPWSにFlexible Cross-Connect、FXCを追加する。ACは顧客側の接続回線で、ポート、ポート上のVLAN、VLAN群などを指す。PEは事業者のエッジ装置、ESはEthernet Segmentである。RFC 8214を基礎に、異なる物理インターフェースやES上のACを共用サービス・トンネルへ多重化する。目的はサービスラベルと関連OAMの削減、そして可能な限りのBGP通知削減だが、両者を同時に最大化する保証ではない。

障害通知が持つ範囲

第5節では、サービス、AC、PEポート、PEノードの障害を区別する。デフォルトFXCは個々のVLANまたはACの障害を通知しない。そのため遠端は、出口で破棄されるトラフィックを送り続ける可能性がある。VLAN通知方式では、該当する正規化VIDの経路撤回により、そのトラフィックの隣接先を変更する。

ポート障害なら対象は広がり、該当する束のトンネル、または関係するVIDとESの経路を撤回する。PE障害ではさらに広い撤回となり、記載された手順ではルートリフレクターが実施する。サービス自体の障害検知にはBFD/VCCVなどのOAMを使える。この四つを一回の試験で代表させるべきではない。

また、RFC 5885第3.3節は、擬似回線の障害検知とAC/PW状態通知の能力を区別している。「BFDあり」という記録では、個別回線が監視対象に入っているかを判断できない。選択した能力と観測対象を確認する必要がある。

ラベルを共用しても経路は残せる

VLAN通知FXCは、正規化VIDとESごとのEthernet A-D per-EVI経路を持ちながら、複数ACのサービスラベルを共用する。一方、デフォルト多重帰属方式では同じESから同じ宛先へ向かうACを束にする。PEの組ごとに複数トンネルが必要になる場合がある。第2節と第3節のこの区別を無視し、任意のインターフェースを一括したときにも同じ復旧粒度を期待することはできない。

単一帰属には代替のPEがないため個別通知を省略できるが、失敗した出口までコアを通過してから破棄される可能性は残る。アプリケーションが送信を止める場合はあっても、全サービス共通の保証ではない。無効な転送量は流量と継続時間から現場で評価できるが、本稿には一律の損失額や復旧時間の測定値はない。

配送までたどれる対応表

異なるポートで同じローカルVIDが使われることがある。入口はMPLS封装の前にVIDを正規化し、出口はラベルでVID-VRFを選んだ後、正規化VIDで出口を特定する。従って、ラベル検索が成功しても最終回線の対応が正しいとは限らない。

受入確認では、顧客AC、ローカルポートとVID、正規化VID、サービスラベル、遠端ES、隣接先、配送結果を結び付けるとよい。これは本稿の運用提案であり、RFCが新設した必須の管理APIではない。第3.3.1節のローカル交換優先も別途確認すべきだ。記載されたケースでは宛先ACまたはESに対応するラベルが必要で、すべてを共通VID-VRFとみなすと曖昧さを残す。

任意のMフィールドは受信時の転送判断に用いず、エラー通知に利用される。Vの指示が単一タグと二重タグの不一致を示す場合、第3.4節ではトンネルを成立させない。通知、成立、配送は別の証拠である。

公式の状態は Proposed Standard で、2026年9月13日の正誤表検索では該当なしだった。これは文書の確認であり、製品の認証でも事故報告でもない。削減したラベルの数とともに、残した回線識別情報がどの復旧に使えるかを示してこそ、FXCの効率を評価できる。