要約

  • RFC 9815では、Node SPF Status TLVのStatus 2はノードとそのプレフィックスの到達可能性を残したまま、そのノードから外向きのLink NLRIをSPFで展開しない意味を持つ。再起動後にTLV自体が省略されると、以前のStatus 2は暗黙に撤回され、デフォルトのトランジット適格性が戻る。
  • したがって「サービスに到達できる」と「非トランジット意図が保存された」は別々の受け入れ条件である。省略だけで実トラフィックがそのノードを通るとは言えず、実際の利用にはトポロジー、メトリック、SPF結果、転送状態、対象フローの検証が関わる。

復旧の引き継ぎで、二つの承認を一つにしない

ここで考えるのは、実在する障害報告ではなく、明示的に仮定したコールドリスタート後の引き継ぎである。

サービス担当者は、対象ホストやサーバー上のサービスプレフィックスへの到達性を確認した。ヘルスチェックも応答し、その担当範囲では復旧と判断できる。一方、ルーティング担当者は、再生成された広告に以前の Node SPF Status 2 が含まれていることをまだ確立していない。

この二人は、同じものを二重に確認しているのではない。

RFC 9815 は Standards Track であり、BGP-SPFのノード、リンク、プレフィックスからSPFを実行する規則を定める。その利用と適用上の考察を補うのが RFC 9816 である。RFC 9815では、すべてのBGP-SPFルーターがNode NLRIを無条件に広告する一方、Node SPF Status TLVは任意である。RFC 9815 第5.2.1.1節 が重要なのは、その任意性が単なる記述上の違いではなく、SPF上の意味を持つからだ。

TLVがない場合、ノードは「up」で、トランジットに利用可能として扱われる。以前にStatus値が広告されていて、その後の更新でStatus TLVが省略されれば、以前の値は暗黙に撤回される。

したがって、再起動後にNode NLRIが戻り、サービス到達性も戻ったからといって、以前の非トランジット制約まで戻ったとは限らない。

ここが責任境界である。サービス担当者が確認したのは正の到達性であり、ルーティング担当者が確認すべきなのは負の制約の保存である。どちらか一方をもう一方の代理にしてはいけない。

Status 2は「到達不能」ではない

Node SPF Statusの意味を正確に分ける必要がある。

Status 1はunreachableである。RFC 9815 第6.3節 のSPF手順では、step 3でStatus 1のノードを無視する。一方、現在到達可能と判断されているノードについては、step 4でそのプレフィックスを考慮する。

Status 2は異なる。ノード自身やそのプレフィックスを到達不能にするのではない。step 5で、その現在ノードの外向きLink NLRIを展開しない。

つまりStatus 2は、「このノードには到達してよいが、このノードから先へSPFを広げ、トランジットの中継点として使うな」という限定を表す。

この差は運用上大きい。サービス監視が成功しても、Status 2が保存された証拠にはならない。むしろStatus 2の設計上、サービス自体が到達可能なままであることは矛盾ではない。

Status 2が消えた場合にも、逆方向の飛躍を避ける必要がある。TLVの省略によって戻るのは、トランジット候補としての適格性だ。それだけで実際にSPFがそのノードを通る経路を選択したとは言えない。

経路選択には、その時点のトポロジーとメトリックがある。SPF計算結果があり、その結果が実際の転送状態としてインストールされたかという別の段階もある。そして特定の通信が本当にそのノードを通ったかを確認するには、対象を定義したデータパス検証が必要になる。

したがって、「Status 2がなくなった」は「必ずトラフィックが流れた」と同義ではない。正確には、「以前は明示的に閉じていたトランジット適格性が再び開いた」である。

省略は中立ではなく、意味を持つ

オプションのTLVを見ると、実装や運用側が「なくても構文上は成立する属性」と扱いたくなることがある。しかしRFC 9815の場合、省略には定義済みの動作がある。

Status TLVがなければ、ノードはupかつトランジット可能として扱われる。したがって、以前の設定からStatus 2だけが失われた広告は、「情報が少なくなっただけ」ではない。SPFで許される振る舞いの範囲が変化する。

これは、設定生成や再起動手順を考えるときに重要な性質である。

たとえば、ある設定システムが任意フィールドを正規化し、「明示値がなくても動く」ものとして落としたとする。それ自体を特定製品の欠陥だと決めつける根拠はない。しかしRFCの意味論だけを見れば、Status 2の消失は動作上無意味ではない。

このため受け入れ試験は、単にNode NLRIが存在するか、サービスが返答するかだけでは足りない。負の制約を意図しているなら、その制約が広告状態に残っていることも別に確認する必要がある。

値の違いは、失敗処理まで異なる

Node SPF Statusの値空間も、運用判断を単純な真偽値に還元できないことを示す。

IANAのBGP SPF登録表 と RFC 9815 第8.3節 では、Node値は0がreserved、1がunreachable、2がnon-transit、3から254がunassigned、255がreservedとされる。

3から254までの未割り当て値は、SPFでは無視されるが伝播される。実装はそれを記録してもよい。つまり未知の将来値を見たからといって、それをStatus 1や2として扱う規則ではない。

一方、reservedである0または255は別である。RFC 9815 第7.1節 に従えば、その値を持つNode NLRIはmalformedとなり、treat-as-withdrawの処理対象になる。

ここでも、単純に「Statusが異常だった」という一括りでは足りない。Status 2の省略、未割り当て値の受信、予約値の受信では、プロトコル上の意味が異なる。

また、TLVのコードポイントについても出典を混同すべきではない。RFC 9815 第8.2節 と IANAのBGP-LS Parameters登録表 は、1184をSPF Statusとして示す。Nodeの値割り当ては、前述のRFC 9815第8.3節とIANA BGP SPFの登録表にある。これらを一般的なBGP Parameters表へ置き換えて引用すると、確認対象そのものが変わってしまう。

RFC 9816が示す非トランジット用途は二つだけ

Status 2の意味を運用上拡張しすぎないことも重要である。

RFC 9816 第7節 が明示する非トランジットの適用例は二つである。

一つは、アプリケーションサーバーを到達可能にしつつ、ルーターとしてトランジットを担わせない用途。もう一つは、サーバー上のコントローラーへ直接到達できるようにしながら、そのノードにトランジットを担わせない用途である。

この二例はStatus 2の性質を具体化するが、現実のネットワークでどれほど使われているかを証明するものではない。またStatus 2を「保守モード」や「過負荷」の一般的な標識として定義しているわけでもない。

したがって、Status 2が消えたときに「保守状態が解除された」と自動的に説明するのは広げすぎである。RFCから確実に言えるのは、SPF上の非トランジット制約がなくなり、デフォルトのトランジット適格性へ戻ることだ。

可視性とデータパス確認は同じ証拠ではない

到達性の監視だけではStatus 2の保存を確認できないのと同様に、制御プレーン上の状態だけで全ての実フローを証明することもできない。

この区別は RFC 9816 第5.5.2節 が扱っている。ここで述べられているのは、トポロジーの可視性と、任意に行うデータパス検証の分離である。この点をRFC 9815へ誤って帰属させるべきではない。

Status 2が存在することを制御プレーンで確認できれば、「そのノードから外向きリンクをSPFで展開しない」という規則が適用される根拠になる。しかし特定の送信元と宛先の通信について、実際の転送経路を確認したいなら、別途そのフローを定義して確認する必要がある。

逆に、ある負のテストで特定のフローが対象ノードを通らなかったとしても、それは定義したフローと確認時点についての証拠である。あらゆるフロー、あらゆる将来時点についての普遍的な不存在証明にはならない。

この限定は、検証を弱くするためではない。証拠が何を示し、何を示していないかを明確にするためである。

受け入れ条件を「到達」と「制約保存」に分ける

この責任境界から導ける実務的な結論は単純である。

再起動やソフトウェア更新後の受け入れ条件に、少なくとも二種類の確認を置く。

第一は正の確認だ。意図したノードやプレフィックスへ到達できることを確認する。

第二は負の制約の確認だ。Status 2を意図しているノードについて、Node SPF Status TLVが存在し、値2が広告されていることを確認する。

その後、必要性とリスクに応じて、SPF結果、インストール済み転送状態、定義済みフローのデータパス検証を追加できる。

重要なのは、これらを一つの「復旧済み」という判定に押し込めないことである。サービス到達性が戻った瞬間と、非トランジット意図の保存が確認された瞬間は、同じ時刻である必要も、同じ担当者の責任である必要もない。

RFC 9815の情報ページ が示す規格上の位置づけと、RFC 9816の情報ページ が示す補完文書としての位置づけを踏まえると、この分離は独自のプロトコル拡張ではなく、既存仕様の意味を運用判定へ正確に写すための整理である。