要約

  • 9月28日付のOPSAWG作業部会Internet-Draftは、PSIDを処理する収集装置や中間システムが識別可能な範囲を把握すべきだと追記した。
  • 範囲を伝える方式までは定めていない。審議中の文書であり、RFCの成立や実ネットワークの障害を示すものではない。

観測データを一か所に集めると、同じ識別子を持つ行を結び付けたくなる。ところが、送信元が別々のSegment Routing領域なら、同じPSIDというだけで同じ経路とは言えない。第07版が新たに指摘したのは、値を採番する側だけでなく、結合を実行する側にもこの境界が見えていなければならないという点だ。

draft-ietf-opsawg-ipfix-path-segment-06はすでにMPLS用のpsidMplsLabelStackSectionとSRv6用のsrhPsidIPv6を提案し、PSIDと経路の対応や、想定した範囲外で同じ値を再利用しても相関の意味は定義されないことを記していた。今回新しい情報要素が増えたわけではない。要素番号も依然としてTBDで、IANAが値を割り当てたと読むべきではない。

第07版の4.1.3節は、IPFIXのフローレコードを扱うCollectorまたは中間処理系が、PSIDの区別可能な範囲を知らないままでは、曖昧な、あるいは誤った相関に至ると明記する。同時に、その範囲をどう知らせて守らせるかは導入環境ごとの課題として残す。仕様案が示すのは問題の位置であって、完成した配布手順ではない。

さらに、一つのPSIDが表す粒度は固定されない。単一のセグメントリストにも、複数のリストや候補経路にも対応し得る。Collectorの後段にある分析系は、管理者が持つ最新の対応表を参照して初めて値を経路文脈に置ける。草案はコントローラやBGP-LSを情報源の例に挙げる一方、対応表の取得・更新手順を規定しない。古い表との結合も、別の領域との結合も、同じ数字だけでは正当化できない。

経路を特定できても、品質までは分からない。草案はPSIDが経路の品質指標ではなく、劣化や局所的な高速迂回で値が変わらない場合があると区別する。SRv6のG-Flagに応じた末尾エントリの扱いも従来からある規則で、今回の改訂点ではない。PSIDの輸出が通常の五要素フローより経路トポロジーを露出し得るという安全上の注意も残る。

Datatracker上の状態は作業部会文書、IESGではI-D Exists。導入済みの標準でも、特定事業者の誤相関を立証する報告でもない。

出典