要約

  • 新しい個人Internet-Draftは、PCEPで通常のSRv6 SIDと圧縮SIDの内部フィールドを照合する二種類のFlowSpec TLVを提案した。双方がS能力ビットを広告して初めて使える。
  • PCCは未交渉または不正なTLVを受け取ると、Type 30のPCErrを送らなければならない。指定された値は TBD_EV で、IANA申請にも載らない。現行の登録簿は「非対応」と「不正形式」に別の値を用意している。

送る命令は細かい。断る返事は決まっていない

PCEPのFlowSpecでは、PCEが条件を示し、PCCがトラフィックに適用する。今回の草案は条件の粒度をさらに細かくする。通常のSRv6 SIDならlocator、function、argument。圧縮SIDのコンテナならlocator block、locator node、function。IPv6宛先アドレスを一塊で見る代わりに、制御側がアドレス内の区切り方まで指定する。

この権限は無条件ではない。PCEとPCCはセッション開始時に新しいSビットをそれぞれ広告し、両方が対応している場合にだけ新しいTLVを送れる。PCCは受け取った各フィールドの長さの合計が128ビットを超えないかも確認する。超えれば不正だ。受け手が自分で検証できる境界が、仕様の中に確かにある。

ところが拒否の電文に穴がある。第5.2節は、Sビットを交渉していない場合とTLVが不正な場合、PCCにError-Type 30、Error-Value TBD_EV のPCErrを義務付ける。第7節のIANA申請にはSビットと二つのTLV種別が並ぶが、エラー値の申請はない。IANAのPCEP番号簿ではType 30の1から5が登録済み、6から255は未割り当てだ。TBD_EV は実際の電文に載せられる番号ではない。

土台となるRFC 9168は、非対応のFlowSpecに値1、不正なFlowSpecに値2を使い分けている。新草案はその二つを「非対応または不正なSRv6部品」という一つの仮の値にまとめた。既存の1と2を使うのか、SRv6専用の値を新たに登録するのか。ここには実装上の選択があり、現稿には答えがない。

受理できる規則だけで相互接続を試せば、この欠落は見えにくい。片方の製品が規則を拒否した瞬間に、もう片方は番号を頼りに理由を読む。各社が別の値を仮置きすれば、制御装置が最も知りたい失敗の場面で会話が割れる。アドレスの128ビットを詳しく読ませる提案なら、拒否の一バイトも詳しく決めるべきだ。

Datatrackerの正式な分類は個人Internet-Draftである。次の版で既存値を明記するか、新しい値をIANAに求めれば、この問題は解ける。読むべき箇所は機能一覧よりも、拒否を義務付けた一文と番号の申請欄だ。

出典