要約

  • 受信済み修復LSPへの受領確認と、追加の照合要求を同じPSNP送信機構で扱う場合、rev05は受領確認を先に送るべきだとする。
  • 照合はpeer・IS-IS levelごとに一件に限定される。約6,700 fragment、40 nodeの実験では、重複する試行が全fragment数のおよそ5倍に当たるPSNP要求を生み、なお増え続けた。

修復中という表示だけでは足りない

CASHは広いnode rangeを要約し、差があればPASHが範囲を狭める。最後は通常のSNP交換やfloodingが不足LSPを運ぶ。ここで受信側には、まだ欲しいものを要求する仕事と、すでに届いたものを確認する仕事が同時に発生する。

同じPSNPキューで要求ばかりを優先すると、送信側は受領を確認できない。再送タイマーが満了し、届いていたLSPまで再び送る。その複製がキューをさらに圧迫し、次の確認を遅らせる。修復処理が故障を直すのではなく、自分の未処理量を増幅し始める。

2026年9月26日付のrev05本文は、この経路を明示した。一方、Datatracker上では個人提出のInternet-Draftで、RFC streamもIETFでの正式な地位もない。ヘッダーのExperimentalは意図であり、実装や採用の証拠ではない。

完了条件は再送の終わりまで含む

rev04の時点で、peerとlevelごとに同時に一つのreconciliation attemptしか許さない規則が入っていた。PASHやPSNPの送信待ち、またはその試行から生じたLSP送信・再送が残る間、新しい定期CASHを始めてはならない。

草案の実験では、約6,700 fragmentと40 nodeに対して試行を重ねた結果、PSNP要求がfragment総数の約5倍になり、観測終了時にも増加していた。原因はハッシュ関数でも単なる規模でもなく、終わっていない修復に次の修復を重ねたことだと説明される。

rev05の追加は、その知見を送信順序へ落とし込む。LSP受領確認と照合エントリーが同じ仕組みを使うなら、まず確認を送り、残った空間に要求を入れる。要求は新しい作業を追加する。確認は相手側の作業を消す。負荷時にどちらを先にするかが、ループを収束させるか増幅させるかを決める。

一致、受領、疎通は別の記録である

BTWの既報ハッシュが一致しても、ネットワークが正しいとは限らないはrev01を扱い、summaryの一致が物理トポロジーやforwardingを保証しないと論じた。本稿の対象はその後である。不一致を発見した修復処理が、どの時点で終わったと言えるかを問う。

PSNPの受領確認は、あるLSPを受け取ったという限定的なreceiptであり、LSDB全体の一致証明ではない。ASHの試行は、関係するPASH、PSNP、LSP送信と再送がすべて終わって初めて閉じる。それでもSPF、FIB、実トラフィックは別に確認しなければならない。

運用記録は三段に分けるべきだ。reconciliation receiptにはpeer、level、attempt、開始理由、range、要求深度、確認待ち時間、未完了LSP、再送回数、延期CASH、終了遷移を残す。次にLSDB・SPF・FIBを記録し、最後に対象パスのパケットを検証する。一段の緑色を次段へコピーしてはならない。

能力通知も範囲を越えない。Hello Capability draftのASH_RXとASH_TXは方向別・adjacency別である。RFC 1195は統合IS-ISの文脈を与え、RFC 5304とRFC 5310はPDU完全性を守るが現場の正しさまでは証明しない。RFC 9681の高速化も完了receiptの代わりではない。

Running-Code Primacyに従えば、確認が出たか、再送が止まったか、試行が閉じたか、通信が戻ったかを観測する。Minimum Initial Specificationは「一試行、確認優先、終了明示」だけを共通化し、実装のschedulerを現場に残せる。Reality Layersは能力、制御状態、配送結果の権威を分離する。

情報源