要約

  • RFC 9736 は Peer Up と Initiation の TLV 名前空間を分け、反復する String TLV の順序保持を明記した。修復されるのは拡張番号の所有権であり、製品の実装や運用結果ではない。
  • 判断には、レジストリと送信側の版、実際のバイト列、パーサの処理、保存記録、peer/session の照合、経路、転送、サービス、対応結果をつなぐ受領証が必要である。

同じ番号表を二つの文脈で使った代償

BMP の Initiation は監視対象システムを説明し、Peer Up は個々の BGP セッションを説明する。ところが RFC 7854 では両者が Information TLV の番号空間を共有していた。拡張が進むと、番号の意味と将来の割当責任がメッセージ文脈に依存し、独立した進化を妨げる。

RFC 9736 はこの問題を小さく、明確に直した。従来の表を BMP Initiation Information TLVs と改称し、BMP Peer Up Message TLVs を新設する。Initiation 側では Type 0 が String、1 が sysDescr、2 が sysName。Peer Up 側では Type 0 が String、3 が VRF/Table Name、4 が Admin Label である。Peer Up の 1 と 2、Initiation の 3 と 4 は予約され、同じ番号を別用途へ不用意に広げる余地を閉じた。

String は Length が示すバイト数の UTF-8 列で、null 終端ではない。Peer Up Information 全体は任意であり、存在は共通ヘッダの Message Length から判別する。String は複数回現れてよく、報告時には順序を保持しなければならない。小さな規則に見えるが、保存系が配列を集合や単一列へ変換すれば意味の手掛かりを失う。

後方互換の文言を実装証明にしない

RFC 9736 は、RFC 7854、8671、9069 に準拠する実装は本仕様にも準拠すると述べる。これは既存割当を新しい台帳へ移す仕様上の互換性である。特定ベンダーの特定リリースが新しい表を搭載したこと、未知 TLV を安全に扱うこと、順序を保存することまで認証してはいない。

失敗は静かに起きる。パーサが反復 String の最後だけを残しても、画面には一つのもっともらしい値が表示される。Type 3 を認識しても、peer distinguisher、BGP ID、OPEN capability の照合がなければ別の仮想 Loc-RIB peer に名前を付けかねない。将来の未知タイプを黙って捨てれば、運用者は送信側が何も送らなかったと誤解する。

したがって検証は decode 後ではなく、wire bytes から始める。Peer Up の原文、BMP セッション、送信側バージョン、Message Length、TLV の並びを保存する。その記録をコレクタの build、parser schema、長さ検査、未知タイプ方針へ結び付ける。raw ingest と decoded record を突き合わせて初めて、欠落が送信側の不在なのか収集系の損失なのかを区別できる。

Peer Up の次に残る問い

RFC 7854 の Peer Up は、監視対象 BGP セッションが Established へ移ったという報告であり、双方の OPEN と TCP 情報を含む。ただし BMP セッション開始時には、すでに Established の peer に対しても Peer Up が送られる。到着時刻を BGP セッション成立時刻と同一視できない。

さらに RFC 8671 は、Peer Up/Down の状態と Adj-RIB-In、Adj-RIB-Out の Route Monitoring / Mirroring の有無は独立だとする。Initiation、Peer Up、初期 RIB dump、End-of-RIB、増分更新は別々の証拠である。一通の Peer Up から feed の完全性を推論してはならない。

Loc-RIB では RFC 9069 の仮想 peer が使われ、一つの table に複数 address family の peer が存在し得る。VRF/Table Name は便利だが、それだけで一意な身份にはならない。ヘッダと capability を含めた照合が必要である。

運用上の受領証

事故記録は順番に問うべきだ。どのレジストリ版か。送信側の版は何か。どの BMP セッションと peer epoch か。実際のバイト列は何か。どのパーサ版がどう処理したか。未知値は保持・隔離・破棄のどれか。raw と decoded の保存記録は一致するか。BGP セッションは別の観測でも確認できるか。主張対象の route feed は完了・継続しているか。RIB、FIB、probe は何を示すか。誰が対応を承認し、その後の結果は何か。

途中で「不明」と止まることは失敗ではない。Peer Up はセッション報告まで、route feed は経路可視性まで、FIB 観測は転送設定までを支える。サービス効果はさらに別である。RFC 9736 の価値は最初の境界を明瞭にしたことにあり、後段を省略することにはない。