要約

  • MPLS WGは2026年9月22日、draft-ietf-mpls-on-path-telemetry-flag-05をIESGへ送った。Publication Requestedは手続き上の状態で、IESG承認、RFC発行、IANA割当、実装や導入の証拠ではない。
  • PフラグはMNA対応かつ収集有効のノードにポストカード生成を求める。共通データセットを指定せず、全ホップが輸出したことを単独では示せない。
  • 運用上の主張には、印付け、想定経路、ノード能力と有効状態、テンプレート版、ポストカード識別、輸送損失、収集側の相関、欠落ホップを結ぶ「trigger-to-export receipt」が必要になる。

ポストカード型テレメトリーの利点は、ラベルスタックを見ると分かりやすい。ヘッドエンドは選んだパケットにMPLS Network Actionsのサブスタックを加え、Format Dの一つのPフラグで、ラベル交換経路上のノードに観測を依頼する。各ノードが持つ豊富な測定値を元のパケットへ詰め込む必要はない。

しかし、小さくなったのはパケット内の表現であり、証明責任ではない。Pフラグは依頼であって、依頼後の出来事を封印した記録ではない。

Publication Requestedが示すのは引き継ぎ

Datatrackerではrevision 05が9月21日付で、翌日にWG状態がSubmitted to IESG for Publication、IESG状態がPublication Requestedへ移った。担当ADとaction holderはJim Guichardである。

この表示は次の判断主体を特定する。本文の承認を意味しない。草案はRFCになっておらず、証拠を固定した時点のIANA Network Action Flags Without Ancillary Data表には登録がない。shepherd write-upはProposed Standardを求め、WG内の広い支持と異論なしを記す一方、既知の実装はないとしている。IPR開示も二件ある。

RFC 9994に基づくMNA Sub-Stack Opcode 1はすでに存在する。ただし草案が求めるのは、その動作で使う新しいフラグである。既存opcodeと未割当のPフラグは同じ事実ではない。

一つのビットの後ろに多数のローカル判断がある

revision 05はaction LSEの後ろにFormat D LSEを置く。Pはhop-by-hopで、ancillary-data LSEを持たず、U=0なので理解しないノードは処理を飛ばす。理解するノードも、データ収集が有効なときだけマーク済みパケットにつき一枚のポストカードを生成し、内容はローカルな制御プレーン設定に従う。

ヘッドエンドは観測対象を決めるが、完全な測定契約を運ばない。未対応ノード、対応済みだが無効のノード、異なるテンプレート版を使うノード、生成上限で輸出を抑えるノードがあり得る。その場合でもユーザーパケットは転送され続ける。

草案は全パケットをマークせず、ごく一部に限るとして、フローごとに1,000分の1以下を既定値にする。ノード当たりの生成上限は平均毎秒1,000、burst 2,000である。超過パケットはポストカードなしで転送され、超過はカウンターに残る。

従って、パケットが届いたことと、ポストカード集合が完全であることは別の結果だ。

一枚のポストカードは一ノードの主張

各ポストカードは、一つの輸出ノードが自身の設定下で何を見たかを述べる。収集器は、どのカードが同じユーザーパケットに属し、どの順序の通過を表すかを決めなければならない。

ポストカードは順不同で届き、失われることもある。ラベルのpushとpopがあれば単一TTLでは足りないことがあり、草案はLSEごとのTTL vector、node ID、flow ID、timestampを相関材料として挙げる。同じ相関キーを共有し得る二つのパケットが同時に飛んでいれば曖昧さが生まれる。曖昧な相関は推測で補わず、破棄しなければならない。

欠落は空白ではなく、分類すべき結果になる。未対応、収集無効、異なるテンプレート、rate limitによる抑制、輸出経路や収集器での損失、捉えられなかった経路変更、相関失敗のいずれでも起こる。Pフラグ単独では区別できない。

印付けから輸出までの証跡

有用な最小記録は、観測開始の判断と収集結果を次のように結ぶ。

証跡の項目 保持する証拠
Trigger Pフラグ、入口、marking policy、sampler版、sampling rate
Scope trust domain、想定LSP、観測時間帯
Node readiness node ID、PBT-M能力、有効状態、software/configuration版
Semantics ローカルtemplate、版、選択したdata type
Identity packet/flow相関キー、sequence材料、export時刻
Delivery export先、transport、送信数、損失、抑制、rate-limit counter
Reconstruction 相関規則、受信順、破棄した曖昧さ、時間境界
Completeness 想定ノード、受信ノード、欠落hop、partial-path表示
Safety ノード上限、例外、超過counter、trust-boundary処理

これは新しいパケット形式ではない。制御プレーン、exporter、collectorから組み立てる運用上のreceiptである。データプレーンを小さく保ちながら、経路結果の意味を再現可能にする。

完全性にも信頼境界がある

草案ではPフラグは変更可能で認証されない。trust domainの境界では、外部から来たPを消すかパケットを落とす。内部では侵害または誤設定されたノードがPを立てたり消したりできる。rate limitは負荷を抑えるが、観測の完全性を認証せず、低頻度の改変も止めない。

YANG modelも定義されていない。これは欠陥だという意味ではない。能力発見、有効化、template identity、export health、収集policyをデータプレーンの一ビットから推定せず、運用面で明示する必要があるという境界である。

PBT-Mは固定12 byteのラベルスタック命令で、豊富なデータをout-of-bandへ移せる。正確な説明はこうなる。パケットが運ぶのは安価なtriggerで、証明を運ぶのはネットワークとcollectorである。

出典

  1. IETF Datatracker：MPLS Network ActionsによるPostcard-Based Telemetry
  2. Datatracker文書履歴
  3. WG shepherd write-up
  4. revision 05テキスト
  5. IANA MPLS Network Actions registry
  6. RFC 9994：MPLS Network Actions Framework