要約

  • RFC 9516 の Active OAM は、指定した SFC の連続性、追跡、故障切り分けを調べるための限定された観測であり、顧客向けサービスの完了証明ではない。
  • Echo Reply の経路、戻り方、返却コードを分けて記録し、分類規則、実際の RSP、選択された SF 実体、実流量の結果を別に確かめる必要がある。

障害会議では、戻ってきた一つのパケットが急に重い意味を帯びることがある。監視画面は緑、追跡表には SFF の名前、最後には End of the SFP。そこで誰かが「サービスは戻った」と書く。だが、観測したのが構成済み Echo Request なら、その文は観測よりも広い。

RFC 9516 が与えるのは、NSH を使うサービス機能連鎖のための fault-management の道具である。オンデマンドの連続性確認、接続性の検証、故障位置の絞り込み、SFP/RSP の追跡、整合性確認を行える。性能監視はこの RFC が満たす対象ではなく、範囲外である。遅延、損失、処理品質、顧客の取引結果を、到達確認の一行に折り畳む理由はここにはない。

まず、試験の入口と顧客の入口は同じではない。RFC 7665 では、トラフィックはローカルな分類によってサービス機能連鎖に入る。分類ポリシーは顧客、ネットワーク、サービス、セッションその他の条件に依存し得る。「この SFP は正常」という表示は、あるテスト要求に付けた識別子であって、ある顧客のフローが今もその分類に一致している証明ではない。規則の版が変わった、条件付きの例外が加わった、特定テナントだけが別扱いになった、という事実は Echo の応答欄には現れない。

次に、論理的な経路と実際の経路を混同してはならない。SFP は論理的なインスタンスであり、RSP は具体的な SFF と SF の識別子から成る実現である。SFP は意図を保つ層、RSP はその時点の実体を示す層だ。同じ SFP に複数の RSP があり得る。さらに一つの SFF に複数の同種 SF が接続され、負荷分散される場合、個別の実フローが通るのは一つの実体だけである。

整合性確認で候補の SF 一覧を得ても、それは生産パケットの処理履歴ではない。ハッシュ入力、セッション固定、フェイルオーバー状態、混雑、容量制御が、試験要求と実際の取引で同じになる保証はない。Probe が RSP A を通ったからといって、顧客フローも RSP A を通ったとは限らない。候補を数えたことと、選択された一つを立証したことは別の作業である。

RFC 9516 はその差を無視しているわけではない。Echo Request は監視対象 SFP に適切な underlay encapsulation を用い、NSH の O bit を設定し、NSH の直後に SFC Active OAM Header を置く。この構成は、前方向で監視対象の SFC データと fate sharing する検査を意図する。意図的に近づけた試験だから、経路の異常を見つける力がある。

しかし fate sharing は同一性の宣誓ではない。合成パケットは、実パケットの長さ、五つ組、暗号化状態、メタデータ、アプリケーション内容、輻輳の時点、テナント固有の条件を必ずしも持たない。SF が実セッションの状態を参照したり、特定プロトコルを解釈したり、契約や権限で判断を変えたりするなら、検査要求を通した結果からその判断を逆算することはできない。RFC 7799 がいう active measurement は、測定のために生成する、しばしば synthetic と呼ばれるパケット列である。合成であることは欠点ではないが、代表する母集団を明示せずに本番全体の代替にすることは欠点になる。

返信も、前方向の証拠に静かに合算してはならない。RFC 9516 では Echo Request の Reply Mode に、返信なし、IPv4/IPv6 UDP による帯域外返信、指定 return path などがある。通常、Echo Reply は NSH を持たずに戻る。指定 SFP を戻り経路に求めることはできるが、それでも報告では要求と返信の構成、方向、経路を別々に書くべきだ。前方向が確認されたこと、制御者が返信を受け取れたこと、そして顧客が双方向サービスを利用できたことは、同じ命題ではない。

返却コードも小さく読む必要がある。有効な要求が SFP の終端に到達した場合、終端 SFF は End of the SFP を返す。中間 SFF の No Error も、その要求の処理についての答えである。コードは、顧客の HTTP 要求が認可されたこと、セキュリティ検査が期待通りの内容で実行されたこと、外部依存先から結果が返ったことを確認する印鑑ではない。受信側が試験要求をどう扱ったかと、サービス機能が本番データに何をしたかは別の対象である。

この違いを運用記録に戻すと、緑色はより有用になる。試験には、対象とした分類規則、表すフロー群、SFC/SFP/RSP と underlay の時点の版、送信元、構成、スケジュール、欠測、返信方式、時刻基準を結び付ける。同時に、入口と出口での実流量観測、実際に選ばれた SF 実体の処理証跡、機能に応じた結果観測を保つ。情報の保存には秘匿や保持期間の制約がある。それでも、何を持たないかを残さない限り、Echo の成功は必要以上の意味を負う。

RFC 9516 の想定範囲も単一 provider operational domain である。そこでは一つの運用者が要素を識別し、試験を作り、ローカルな返答を解釈できる。境界を越えれば、分類責任、経路の可視性、サービスの約束、観測者が変わる。あるドメインの Echo Reply を、他者の提供分まで含むエンドツーエンドの受領書として移植してはいけない。

良い障害対応は、Echo を軽く扱うことではない。正確な限定を残し、その限定が次に必要な観測を指すようにすることだ。Probe は「どこを調べるか」を狭められる。顧客が何を受け取ったかは、別の証拠で答えなければならない。

Sources