要約

  • RFC 9634は、OAMセッションを監視対象のDetNet IPフローに関連付け、同じ経路と転送処理を受けさせるよう求める。
  • BFD、STAMP、ICMPはアプリケーションと異なるヘッダーを持つ。UDP送信元ポートはハッシュを誘導できても、異種装置で同一メンバーを保証しない。
  • 証拠にはフロー選択、対応規則、実経路、キューやpolicing、予約資源、サービス層、計測範囲、アプリケーション判断が必要である。

運用者が最初に問うべきなのは「成功したか」ではない。「そのパケットは本当に同じサービスの一員だったか」である。

RFC 9634は、ICMP、BFD、STAMPなど既存のIP OAMをDetNetで使う条件を示す。DetNetフローはプロトコル、アドレス、ポート、DSCPなどで分類される一方、試験プロトコルには固有のヘッダーがある。同じ端点だけでは同一性を作れない。

本番フローとOAMセッションの二つの選択子、その間の対応規則、設定世代と有効期間を残す必要がある。RFC 9633のYANGは対応を記述できるが、実行された経路を観測したことにはならない。

ECMPの同じ箱に入ったという仮説

UDP送信元ポートを選べば、ECMPやLAGで本番と同じハッシュ結果を狙える。しかしRFC 9634は、異種装置が一貫した判断をするとは限らないと明記する。フィールド、seed、メンバー、ソフトウェアが変われば結果も変わる。

送信ヘッダー、観測メンバー、設定世代、期間中の変更を保存して初めて検証できる。応答は試験の往復を示すだけで、本番パケットの道を証明しない。

同じリンクでも同じサービスではない

OAMはshaping、filtering、policing、事前割当資源も共有しなければならない。同じノードを通っても別キュー、ACL例外、優先度なら別の処理である。低率プローブが本番のburstを再現しないこともある。

IP-in-UDPは対応を簡単にする反面、DetNet域を一つのIPリンクに見せ、通常のtracerouteから中継点を隠す。DetNet-in-UDPやGRE-in-UDPはより強い対応を可能にするが、利用可能な機構と実測記録は別物である。

計測値にも独立した契約が要る

BFDはそのセッション状態機械の範囲で連続性障害を検出する。STAMPは定義されたテストセッションの範囲で遅延や損失の観測を作る。ICMPは特定の障害検出や局所化を助ける。いずれも、対象アプリケーションの全パケットと期限を自動的に代表するわけではない。

方向、観測点、期間、パケット母集団、sampling、sequenceの意味、時計の関係、duplicateとlate packetの扱い、counter discontinuityを残す必要がある。「異常を検出しなかった」は、別のmember、時間帯、queueに存在した異常を否定しない。

ドメイン境界で証拠をつなぎ直す

サービスがIP、MPLS、TSNの各ドメインを横断する場合、個々のドメインで正しいテストが行われても、境界で分類と資源契約が保存されたとは限らない。peeringとtunnelingでは観測できる範囲が異なる。どこで計測を終え、どこで新しい対応を確立したかを明示する。

複数の緑の結果を足してもend-to-endの証明にはならない。各区間のサービスID、handoff時刻、mapping、clock、未観測部分を接続した記録が必要である。一つの区間がreachabilityしか示さないなら、全体もdeadlineを証明できない。

六つの記録を分離する

第一は本番フローで、選択フィールド、方向、traffic profile、service/forwarding sub-layer、設定世代を含む。第二はOAMセッションで、protocol、実送信header、source-port選択、認証、interval、観測点を含む。

第三はassociation proofで、同一member、期間、安定した規則を示す。第四はtreatmentで、queue、filter、policer、shaper、reservation、service functionを示す。第五はraw observation、clock、population、loss/delay計算、discontinuity、不確実性である。第六はapplication ownerのaccept、limit、rollback、waiverという決定である。

障害時は修復より先に証拠を保存する

本番が失敗しプローブだけ正常な場合、source port変更、member切替、session再起動を急ぐと差の原因を消してしまう。先に二つのselector、送信header、ECMP/LAG member、queue/policy hit、resource binding、counter discontinuity、topology eventを凍結する。その後で影響範囲を限定した回復を行う。

回復後の緑の結果は旧windowを遡って証明しない。新しいconfiguration generationとobservation intervalに属する。記録には、旧結果がなぜproductionを代表できなかったか、新結果がどの条件で権限を取り戻したかの両方を残す。

片方向と双方向も分ける。requestとreplyは異なるhash、member、混雑を経験し得る。round-trip成功を二つの証明済みone-way pathへ分解してはならず、one-way deadlineを平均RTTで代用してはならない。

自動化の安全なgate

自動化はassociation proofを満たした結果を、限定トラフィックの拡大や追加観測へ進む条件にできる。しかし一回の応答をdelivery completeへ直結させない。generation不変、member観測、treatment一致、window完全、application authorityの署名を確認する。

rollbackも影響範囲に限定する。一つのmemberの不明点で無関係なserviceを再起動せず、一つのdomainの対応失敗で他domainの有効な証拠を消さない。これはproductionとevidence chainの双方を守る。

Heng Luのいう最小仕様は異なる実装の協調を可能にする。running codeと観測されたpacket historyは、その仕様が現実になったかを決める。設定の署名、測定の署名、アプリケーションの署名を一つの緑表示へ圧縮してはならない。

情報源