要約

  • RFC 9617 の YANG モデルは IOAM の有効化、フローへのプロファイル適用、キャリアプロトコル、対応オプションを共通化するが、終端までの観測結果を生成するものではない。
  • パケットは accept 動作を持つ ACE に実際に一致し、意図したオプションを付与され、参加ノードを通過し、容量境界を越えず、帯域内または直接エクスポートの証拠として届く必要がある。
  • active datastore、選択、挿入、ノード寄与、エクスポート列、収集保管、分析、認可された動作、サービス結果は別々の受領証である。

設定画面だけが緑だった

運用者が active datastore を読むと、admin-config/enabled は true、対象プロファイルは存在し、フィルターは想定した ACE を参照し、プロトコルは IPv6 だった。必要な trace feature も実装から通知されている。設定画面が緑を表示するのは妥当である。

それでも業務パケットの記録が現れないことはある。パケットが ACE に一致しなかった、より前の規則に処理された、別インターフェースから入った、挿入が行われなかった、途中のノードが feature を持たなかった、割当領域が足りなかった、またはエクスポートが収集前に失われた可能性がある。

RFC 9617 は設定を読みやすくする。その成果を観測の成果にすり替えないことが重要だ。モデルは何を行うよう命じたかを示す。データプレーンは何が起きたかを示す。

YANG ツリーは制御契約である

ietf-ioam は NMDA に従い、読み取り専用情報、管理上の有効化、名前付きプロファイルを持つ。各プロファイルはフィルター、キャリアプロトコル、増分 trace、事前割当 trace、直接エクスポート、Proof of Transit、edge-to-edge の下位設定を組み合わせる。

型、identity、インターフェース参照、ACL 参照、feature は不正な値を拒む。schema validation はモデルへの適合を、feature は実装が告知する能力を、readback は値が datastore に存在することを証明する。

どれもパケットキャプチャではない。ノードが情報を書いたことも、記録が収集器に届いたことも含まない。構造の厳密さは、実行の受領証を不要にしない。

enabled=true は可能性を開くが、過去を証明しない

管理パラメータを true にすると IOAM 設定とデータプレーン機能が有効になる。だが全パケットが対象になるわけではない。プロファイル、フィルター、インターフェース、プロトコル、ノードの役割が範囲を決める。

現在の値は、過去のパケット到着時にも true だったことを自動的に証明しない。設定 epoch を保持し、挿入時刻やエクスポート時刻と結合して初めて歴史的主張になる。

従って enable は前提条件である。どのフローが、どの revision の下で、どの機能を実際に使用したかは別の記録を要する。

ACE で意図がパケットに接触する

プロファイルのフィルターは ACL の ACE を参照できる。RFC 9617 では、実際に一致した ACE の forwarding action が accept のとき、受理されたパケットが IOAM action を駆動する。

参照があることと一致したことは異なる。ACL の順序、方向、インターフェース、アドレスファミリー、実装挙動が結果を左右する。先行規則がパケットを決定する場合も、まったく一致しない場合もある。

調査には active ACL revision、ACE、方向、パケット選択値、match 結果、forwarding action、設定 epoch が必要だ。「ACE-7 を参照」は設計であり、「このパケットが revision X の ACE-7 に一致して IOAM を起動」は実行である。

protocol-type は実物の包みを示さない

protocol-type は IPv6 や NSH など、IOAM データを埋め込む層を示す。共通モデルで適用先を表すための重要な抽象である。

しかし datastore の IPv6 は、特定のパケットに IPv6 IOAM option が入った証拠ではない。別 ingress、トンネル変更、サイズ制約、下流の未対応があり得る。

入力パケット、match した profile、encapsulation action、生成 option、サイズ、namespace、trace-type、相関値を同じ受領証に結ぶ必要がある。設定値だけでは「どこに証拠が現れるべきか」までしか分からない。

feature があっても trace は欠け得る

増分と事前割当のプロファイルは node action、namespace、trace type、max-length を選ぶ。配分方式は違うが、実経路の各ノードが参加して初めて情報が積み上がる。

feature はローカル能力である。一台の対応は経路全体の対応ではない。要求フィールドを提供できないノードもあり、事前領域はエントリ数を制限する。記録が四ノード分だからといって、経路が四ホップだったとは限らない。

欠落は、別経路、能力不足、不参加、領域枯渇、option 除去、export loss、decode failure のいずれでも起きる。設定モデルは原因の自動判定器ではない。

直接エクスポートには別の欠落点がある

直接エクスポートでは flow-id と sequence number を使える。前者は同一フローの記録を関連付け、後者は一部の欠落を見えるようにする。

それでも完全性は証明されない。収集器の開始前に失われた先頭部分には番号の飛びが見えない。再起動と rollover には epoch が要る。生成後、転送前の損失もある。複数 export 元の番号空間も区別しなければならない。

exporter identity、boot/config epoch、flow-id scope、sequence rule、送信、輸送、受信、decode、retention を保存して、初めて欠番に限定した意味を与えられる。

POT という名前は証明書ではない

RFC 9617 が定義するのは POT の基底型で、具体的な方式は augment を必要とする。ツリーに POT profile があるだけで、暗号学的または運用上の証明が生まれるわけではない。

edge-to-edge profile も、encapsulation node が加え、decapsulation node が解釈するデータを設定する。両者が同じパケットを処理したことやサービス成功は別の観測である。

既存の IOAM integrity 論点とも境界は明確だ。ICV は宣言された保護範囲の改変検出を扱う。RFC 9617 は設定を扱う。片方の成功はもう片方の完成を意味しない。

失敗を隠さない受領証の階段

第一段は active configuration、第二段は packet selection、第三段は option insertion または trigger である。その後に node contribution、capacity limit、direct export、collector receive、decode、retention が続く。

分析結果はさらに別の段で、制御動作には認可、installation、outcome が必要だ。一つの緑表示に全段を代表させてはならない。

RFC 9617 は最初の段を相互運用可能にした。運用上の真実は、その後の段が独立して残す記録から成立する。

情報源