要約

  • draft-dikshit-netconf-yang-push-causal-ordering-00 は、公開者ごとの連番では比較できない複数の通知を、物理成分と論理成分からなる HLC で並べる案を示す。
  • HLC が守るのは、因果的に先行する事象の時計が小さくなるという一方向の性質である。小さい時計から因果を逆算することはできず、独立した公開者は同じ二成分を生成することもある。
  • 再起動をまたぐ判断には、認証された公開者、プロセス世代、連番、時計復元、同値の決着、欠落、明示的依存、データ状態、実行権限、適用結果、独立観測が必要になる。

名前は時計の世代ではない

公開者単位の連番には明確な役割がある。同じ公開者と同じ稼働世代で 88 の次に 90 が届けば、89 の欠落を調べられる。90 の後で 89 が届けば、遅延、順序逆転、重複を区別する材料になる。しかし公開者 A の 90 と公開者 B の 14 は比較できない。それぞれが別の履歴を数えているからだ。

草案はこの不足と、有限カウンターが再利用される回り込みの問題を挙げる。提案される HLC は、物理時刻に近い成分と、同じ物理値の中で順序を進める論理成分を通知へ持たせる。受信者は二成分を辞書順で比較する。多数の公開者から届く記録を小さな固定形式でまとめるには魅力的だ。

ところが、公開者の名前が同じだからといって、時計を生成したプロセスが同じとは限らない。再起動、仮想機械の巻き戻し、装置交換、クローン、フェイルオーバーは、見慣れた名前の下へ新しい時計状態を置く。世代を持たずに系列を連結すると、復元前後の値を一つの連続した主体の発言として扱ってしまう。

HLCの保証は片方向である

HLC の原論文は、分散システムの happened-before を基準にする。同一プロセス内の順序、送信と対応する受信、そしてそれらの推移関係が因果の道を作る。その道が存在するとき、前の事象の HLC は後の事象より小さい。既知の因果を時計が逆転しないことが目的である。

逆は保証されない。相互に通信していない二つのプロセスが別々の状態を観測し、物理時計の差によって異なる HLC を付けることがある。数値上の先頭は、情報が伝わった方向ではない。運用画面で上に並ぶこと、保存時に先のキーを持つこと、分析窓へ早く入ることは、因果の証明にはならない。

ベクトル時計は参加者ごとの成分を持つため、成分比較で因果的先行を示し、比較不能なら並行性を表せる。参加者が増えるほど状態も増える。HLC は一定の大きさと物理時刻への近さを選ぶ。これは合理的な設計交換だが、受信側が失われた情報を推測で補ってよい理由にはならない。

再起動には明示的な境界が要る

受信側が必要とするのはホスト名だけではない。通信相手として認証された主体、公開者 ID、起動世代、時計状態を永続化したか、どこから復元したか、旧世代と新世代が重なったかを記録する。ローカル連番と HLC は併存させる。連番はその公開者の流の連続性を、HLC は規則に基づく順序を説明し、世代は両者の有効範囲を区切る。

再起動後に物理成分が後退した場合、論理成分で単調性を保つ実装もあれば、状態をリセットする実装もあり得る。草案の二フィールドだけから、どちらが起きたかは分からない。復元規約とその版が必要である。異常値を修正した中継者がいるなら、受信値と修正値を分けて残す。

二つの独立公開者が同じ物理値と論理値を出す場合もある。総順序を望むなら、公開者 ID やイベント ID を追加して同値を決着できる。その規則で得た順序は決定的だが、ID の文字順が因果を作るわけではない。決着キーを根本原因やロールバック順へ流用してはならない。

進んだ時計も受信者を支配する

物理時計が大きく先行した公開者は、その通知を並びの後方へ押し続けられる。草案は、受信側時計より設定した epsilon を超えて先の物理成分を疑わしいものとして扱うよう求める。これは異常封じ込めとして有用であり、時刻の正しさを保証する印ではない。

受信側も同期を失い得る。NTP のソース選択、オフセット、分散、ホールドオーバー、補正履歴は別の証拠である。RFC 5905 は時刻同期の仕組みを定め、RFC 9581 は時間情報と品質表現を扱うが、どちらも通知内容や発生原因を認証しない。

疑わしい記録を捨てれば完全性が失われる。隔離すれば判断が遅れる。値を書き換えれば公開者の主張と収集者の判断が混ざる。受理すれば時間窓や最終値判断をゆがめる可能性がある。どの選択も、閾値、時計状態、処置、後日の再計算とともに記録すべきである。

整列しても同じ状態を見たとは限らない

HLC は届いた通知しか並べない。公開者の停止、アクセス制御、購読終了、転送障害、デコード失敗、更新の集約、収集者の輻輳は、残りの流をきれいなままにして情報を消せる。一つの系列に欠番がないことは、必要な全公開者が観測された証明ではない。

また、インターフェース処理とルーティング処理が別の時点で状態を読むと、二つの正しい通知が同時には存在しなかった組合せを作る。HLC 順に置いても原子的なスナップショットにはならない。共通障壁、トランザクション版、または不整合を明示する観測窓が必要になる。

実務の証拠鎖は、公開者と世代、ローカル連番、HLC、時計品質、購読、スキーマ、アクセス範囲、イベント時刻、観測時刻、送信時刻、受信時刻、欠落処置を分ける。因果を主張するならメッセージや処理依存を追加する。変更へ進むなら、責任主体、権限、対象、引数、応答、適用状態の再読出し、転送やサービスの独立観測を追加する。

現在は個人提案である

修訂 00 は 2026 年 8 月 30 日付、Informational を意図し、2027 年 3 月 1 日に失効する個人 Internet-Draft である。Datatracker は、IETF の承認を受けず標準化過程で正式な地位を持たないと説明している。NETCONF WG 文書、RFC、実装試験、配備報告ではない。

それでも問いは有益だ。分散した YANG-Push の記録を比較する規則は必要である。HLC は候補になり得る。ただし、既存の因果を守ること、あらゆる比較から因果を発見すること、再起動をまたぐ主体を証明すること、完全な状態と運用結果を証明することは、それぞれ別の仕事である。

出典