Summary

  • IESGは9月21日、draft-ietf-bier-ping-29をProposed Standardとして承認した。RFCの刊行が終わったという意味ではない。
  • 監視対象のフローと同じBIFT-id、BSL、Entropy、DSCPをEcho Requestに使う点が、診断結果の射程を決める。本草案のtracerouteはBIER over MPLSに限られる。
  • 9月24日の確認時点でIANAの処理は進行中、RFC Editorは著者の入力待ち。実装についての公式な記述は「一部」にとどまる。

BIERは一つのパケットを、ビット列で指定された複数の出口ルータへ転送する。入口からの試験が成功しても、全ての枝が同じ状態とは限らない。だからこそ今回の草案は、IP層の試験に頼り切らず、BIERのデータプレーンで故障を発見し、場所を絞るためのOAMメッセージを定める。

IESGが承認したのは、この問い方についての共通仕様である。装置の全機能、全経路、全受信者を承認したわけではない。草案はEcho Requestに、監視するフローと同じBIFT-id、ビット列長、Entropy、DSCPを使うよう求める。値を変えれば転送表、経路選択や処理クラスが変わり得る。応答を保存するなら、成功フラグだけでなく、その四つの条件も保存しなければ後で意味を確かめられない。

一つの題名に二つの適用範囲

草案の題名にはPingとTraceが並ぶ。しかし、ここで規定するtracerouteの範囲はBIER over MPLSであり、pingには同じ制約がない。販売資料や運用手順が両者を一括して「対応済み」と書くと、導入時に最も必要な差が見えなくなる。装置ごとに封装方式、要求と応答の形式、対象BFER、対応する返信モードを列挙するほうが確実だ。

返信が来なかった場合も解釈には注意がいる。対象の枝に障害があるのか、戻り道が使えないのか、応答が制限されたのか、機能が実装されていないのかは別問題である。逆に返信が来ても、アプリケーションの配信品質や全受信先の到達を直接測ったことにはならない。RFC 9974の最高CoSプローブを扱った従来記事と異なり、ここで問うのは新たに承認された診断手順そのものの完成と利用条件だ。

公開手続きにも同じ区別がある。草案はIP/UDPで運ぶEcho ReplyのUDPポートやBIER OAMの識別値、登録簿を求める。IANAの専門家コメントは、要求するポートが管理された環境でのユニキャスト返信用であり、マルチキャストのデータを運ぶ一般ポートではないと明確にしている。ファイアウォール設計にも関係する境界だが、最終的な番号が付いたと先走ってはならない。

Datatrackerでは、IESG状態はRFC Editorの待ち行列、IANAの作業は進行中、RFC Editorの表示は著者入力待ちとなっている。IESGの発表も、著者がIANAの質問に答える必要を記す。承認の取り消しではなく、承認から刊行までに別の担当者と作業があるということだ。実装についても、公式文書はBIER対応ベンダーが「一部」を実装したとだけ述べ、相互運用の組合せを示さない。

手続き上の判断を稼働中のネットワークで確かめるというLu Hengのrunning-codeの視点を借りれば、標準の価値は肩書ではなく再現可能な観測にある。今必要なのは、承認、番号割当て、刊行、装置の応答を一つずつ照合することだ。

Sources