要約

  • IESG は 2026 年 8 月 13 日、draft-ietf-opsawg-discardmodel-16 を Proposed Standard として承認した。情報モデルと YANG データモデルにより、インターフェース、装置、制御プレーンの破棄を共通の語彙で報告できる。
  • 文書は、分類だけでは破棄が意図的か否か決められないと明記する。カウンターは装置内の観測条件を示し、ローカル方針、設定意図、基準値、継続時間、サービス文脈、実装上の優先順位、周辺証拠が意味を決める。

同じ分類が反対の対応を求める

冒頭は仮想事例であり、実在する製品やネットワークの障害ではない。どちらも policy discard として正しく数えられる。共通する事実は、パケットが実行中の規則に一致したことだけだ。その規則が現在のサービス意図を表すかは含まれない。

一方で ACL を外せば正しい境界を壊し、もう一方で残せば停止を長引かせる。「policy なら正常」または「policy なら規則を削除」と直結する自動化は、どちらかを必ず誤る。

標準化の役割は、装置がどこで最終的に転送またはローカル配送を断念し、どの会計分岐へ入れたかを比較可能にすることだ。調査範囲は狭まるが、テレメトリーが意図の所有者になるわけではない。

共通化されるのは観測の文法である

承認された文書は “Information and Data Models for Packet Discard Reporting” の第 16 版である。RFC Editor が発行するまでは Internet-Draft で、Operations and Management Area Working Group の成果だ。

実装非依存の情報モデルと、インターフェース、装置、制御プレーンを中心にした YANG データモデルを定義する。shepherd の資料には、四社九つのハードウェア・プラットフォームでのマッピングまたは実装と、部分的なオープンソース実装が報告されている。これは running code の証拠だが、全装置への普及やシリコン内部の同一処理を証明しない。

分類は component、direction、traffic/discard、layer、subtype、さらに詳細な理由と metric へ降りる。component は制御プレーン、インターフェース、フロー、装置。direction は ingress と egress。Layer 2 と Layer 3、error、policy、no-buffer は別々に扱う。

これにより粗い総数よりも調査しやすくなる。しかし装置が公開するのは自装置の運用状態であり、上流の全事象、パケットの全経路、顧客の期待、承認記録ではない。

破棄した装置が証明できる狭い事実

パケットを破棄として数えるのは、転送もローカル配送もしないと最終決定した装置だけである。制御プレーンへの punt など、装置内の別経路へ渡した時点では破棄ではない。後で落ちたなら、その場所のクラスで数える。

可能なら物理または論理インターフェースへ帰属させ、不可能なら装置へ帰属させる。この規則は内部ハンドオフの二重計数を抑え、観測責任を明確にする。

観測場所と原因の発生場所は同じとは限らない。受信 L2 エラーは、リンクまたは上流送信機で壊れたフレームを装置が正しく拒否した結果かもしれない。L3 外部ヘッダーの不正も上流由来になり得る。no-route はローカル表、設定ミス、収束中の状態に由来し、TTL expiry は通常の診断、低い初期値、収束、ループのいずれでも起こる。

カウンターは「この装置がこのクラスで最終破棄した」と言える。それだけで「この装置が障害を起こした」「ここが最初の故障」「装置を外すべき」とは言えない。

一度だけ数えることは、一つだけが原因という意味ではない

同じ方向・文脈では、パケットは traffic か discard の一方、Layer 2 か Layer 3 の一方に属する。個々の破棄は error、policy、no-buffer の一つにだけ入り、詳細な no-buffer type は上位集計にも含める。

この単一計数は合計を照合するための規則で、寄与条件が一つだったという主張ではない。あるパケットが規則に一致し、浅いバッファに遭遇し、不正ヘッダーも持つ場合でも、パイプラインは一つの報告理由を選ぶ。

複数理由が成立するとき、優先順位は曖昧なく説明されなければならない。実装は高い順の discard-order-capability を公開すべきで、制約があれば別の文書化された方法も使える。評価順が違えば、同じパケットでも準拠した二機種が異なるクラスを選び得る。

したがって、葉名だけを比較してはならない。機能、優先順位、ソフトウェア版を一緒に扱う必要がある。更新によって、トラフィックが同じまま勝つ理由だけが変わることもある。

カウンターには証拠の期間がある

集計値は詳細クラスを含むのが原則だが、細かなカウンターが別の discontinuity time を持つ例外はある。ラインカード、プロセス、機能の再起動は、直接比較できない新しい期間を始める。

期間と中断点を無視した差分は、存在しないレートを作る。長寿命の集計と初期化直後の葉を比較すれば、正しい値が欠落に見える。リセットを回復と読めば、破棄が続いていても事案を閉じてしまう。

実装は機能の一部だけをサポートでき、YANG Library で公開する。機能を持っていても全カウンターを埋めない場合があり、その範囲は文書または機械的手段で示すべきだ。

モデルに定義があること、装置が機能を広告すること、現在の期間に値を埋めることは別状態である。欠損はゼロではなく、ゼロも観測範囲外の無損失を証明しない。

意図は運用者のローカル判断である

文書は、クラスだけで意図的・非意図的を決めない。ローカル方針、設定意図、基準挙動、継続時間、影響範囲、サービス文脈、他の運用証拠を合わせて運用者が判断する。

ACL、policer、uRPF、保護規則、明示的 null route のカウンターは、規則への一致を示す。規則は正しく守っているかもしれず、古い prefix、誤った顧客プロファイル、変更後の相互作用かもしれない。カウンターは承認記録を持たない。

no-buffer もサービス別だ。best effort の小さな損失が合意指標内なら許容され、持続的な超過なら容量や経路変更が必要になる。Lower Effort には別基準がある。低率の TTL expiry は traceroute、継続的な増加は収束障害やループを示し得る。

標準分類は良い信号である。解釈と変更権限は、結果を負うローカル所有者に残る。

自動化は証拠を結合する

装置を外す、戻す、トラフィックを移す、変更を戻す、担当者へ上げるという対処は互換ではない。孤立した葉から一つを起動すれば、障害を広げたり正しい制御を外したりする。

必要な記録は、装置とソフトウェア、component、interface、direction、layer、class、subtype、機能広告、値の提供範囲、優先順位、値、時刻、中断点、基準値である。関連設定と所有者、経路、隣接、キュー、ハードウェア、フロー、パケット試験も結ぶ。

policy なら規則と一致トラフィック、受信 error ならリンクと上流、no-buffer なら制約資源とサービスクラス、no-route と TTL なら経路状態と時間を調べる。

カウンターは、この証拠結合の型付きキーとして強い。単独のトリガーにすれば、不十分な推論を精密な語彙で自動化するだけだ。

出典