Summary

  • OGIDの個人提出草案は、リンク情報のTLVがF1からF2へ移る例を示す。新F1だけを先に受け取った側は、古いF2と合わせてリンク情報がないと判断しかねない。
  • 提案は論理更新にOGIDを付ける。Fragment Countが1を超えれば、受信側はLSPを通常通り保存・洪水送信しつつ、必要な断片がそろうか制限時間が切れるまでTEDとSPFへの反映を待つ。

TLVが大きくなりF1に収まらなくなる。送信側はF2へ移し、F1とF2の新版を流す。受信側に新F1が先着すると、手元の旧F2にもそのTLVはない。11月2日の文書は、この混在状態がリンク削除と誤認され、経路やトンネルが不必要に動く可能性を描く。実際の障害を報告した文書ではない。

提案では、送信元が論理更新ごとに16ビットのOGIDを割り当てる。複数の断片を一緒に扱う必要があれば、Fragment Countを1より大きくし、待つべき異なる断片の数を示す。受信側は届いたLSPをリンク状態データベースに入れ、通常通り隣へ流す。止めるのは上位の判断、つまりトラフィックエンジニアリング用データベースの更新とSPF計算だ。必要数がそろえばまとめて処理する。Fragment Countが1なら直ちに処理できるが、実際に変更された断片が一つとは限らない。

待ち時間には上限がある。最初の断片でタイマーが始まり、後続の到着では延長しない。そろわなければ保持分を通常のIS-IS手順で処理する。LRGIDはその断片が関わった直近の複数断片取引を指し、遅れて届く断片を結び付ける。しかし短時間に何度も更新すれば一つの参照では古い取引を救えず、タイマーが切れる。実装を評価する際にはこの失敗経路まで必要だ。

旧装置はRFC 8918の規則で未知のTLVを無視し、有効なLSPを受け取れる。旧来の部分状態による計算も続く。IETFの状態記録はこの文書を個人提出のInternet-Draftとし、IANAの登録簿にはOGIDの確定番号がない。装置を特定した到着順、タイマー、SPF結果、実際の転送記録が、提案の効き目を示す材料になる。