要約

  • revision 19 は、短い変化を遅延させる link-flap-suppression と、反復障害を指数減衰する penalty で記憶する dampening を別々の feature として定義する。
  • down timer 中は基礎リンクが down でも oper-status が up のままになり得る。状態が変わらないことは、何も起きなかった証拠ではない。
  • feature 宣言、設定、適用値、timer/penalty、インターフェース、プロトコル隣接、RIB/FIB、パケット、業務結果、再発期間を一つの時系列に結ぶ必要がある。

二つの時計を一つに見せない

draft-ietf-netmod-intf-ext-yang-19 の timer-running は、管理画面が見落としやすい事実を明示する。値が down なら、下位のリンクは実際には down だが、インターフェースはまだ up と報告される。up なら、キャリアは戻ったが、上位層への up 通知はまだ保留されている。

草案上の正式名は link-flap-suppression であり、carrier-delay という container は存在しない。down と up はミリ秒単位で、状態が連続して維持されるべき最小時間を定める。down 側の遅延は光保護に時間を与えられる一方、草案自身が、その間にトラフィックが black hole へ入り再収束が遅れる可能性を記す。up 側は信号が継続し error free であることを待つ debounce で、瞬間的な復帰を即時のサービス復旧に昇格させない。

短い変化が時間窓の中で元へ戻れば、oper-status と last-change は動かない。しかし carrier-transitions は、上位状態が抑制されても下位の変化を数えるべきだとされる。したがって「状態変更なし」と「物理信号が複数回変化した」は矛盾しない。timer の方向、開始時刻、transition の増分を失った監視は、フィルター後の結果しか保存していない。

Dampening は履歴に判決を与える

長い揺らぎに対する dampening は、単なる長い delay ではない。up→down が起きるたびに penalty が 1000 増え、half-life ごとに指数的に半減する。値が suppress 以上になればインターフェースは operationally down に保持される。下位リンクが up で penalty が reuse 未満に落ちれば解除できる。新しい penalty がなければ max-suppress-time が最長期間を区切る。

長い half-life は広い制御面を反復障害から守るが、過去を長く現在へ持ち込む。低い suppress は早く隔離するが、回復可能な回線を長く外す危険がある。低い reuse は長い静穏を要求する。草案例の 60 秒、750、2000、240 秒、penalty 2480 は推奨値ではない。presence container だけで有効化すると、default は vendor/device specific であるため、実際に適用された値を別に取得しなければならない。

penalty が下がったことは原因が消えたことではない。suppressed=false はローカルな門が開いたこと、time-remaining の終了は抑制時間が終わったことを示すだけだ。アラーム件数の減少も同様である。光モジュール、ファイバー、電源、対向ポートのどれが変化したか、再発しないか、転送が戻ったかは別の問いとして残る。

Schema の自己申告から実行へ

YANG 1.1 の feature は schema の条件分岐である。この草案の二つの container は別々の if-feature を持つため、実装は一方だけを提供できる。RFC 8525 の YANG Library は、サーバーが実装すると表明する module と feature を列挙する。そこに link-flap-suppression があることは schema の可用性を示すが、特定ポートへの設定受理、実値への反映、ハードウェアイベントの処理を証明しない。

NMDA では intended configuration と operational state が分かれる。値がハードウェアへ伝播する時間、ローカル制約、動的状態との相互作用により、意図と使用中の値は異なり得る。候補設定、応答、後から operational で得た適用値を保存して初めて、設定面の鎖になる。validator の合格、IESG の進行、commit 応答を実行結果へ拡張してはならない。

Datatracker の文書記録 と履歴 は、revision 19 が NETMOD の active Internet-Draft で Proposed Standard として提出されていることを示す。これは実装や配備の記録ではない。security considerations は安全な transport、相互認証、NACM を求める。個別に「特に sensitive」な writable node を挙げない定型文があっても、black hole と再収束遅延という本文上の影響は消えない。

Up の後に必要な八つの確認

RFC 8343 は oper-status=up を packet を通せる状態と定義するが、revision 19 の timer は報告と下位状態を意図的にずらす。timer 終了後も、それはローカルな interface object の状態であり、隣接プロトコル、経路、転送、利用者結果を代弁しない。

まず transition と timer/penalty を確認する。次に、必要な protocol adjacency が peer ごとに再確立し、期待した epoch に属するかを見る。その後に RIB を確認する。RFC 8349 の active route は同一 RIB 内の同一宛先について preferred であることを示すが、forwarding hardware への install そのものではない。FIB、next hop、policy、queue の状態は別に読む必要がある。

最後に packets と service を観測する。RFC 7799 は active、passive、hybrid measurement を区別する。方向、アドレス、traffic class、packet 特性、観測点、期間を記録しなければ、成功の範囲は定まらない。一つの ping は全 LAG/ECMP member、逆方向、全 packet class、業務処理を証明しない。BFD も、使われていれば高速な path-liveness evidence になるが、application の完了証明ではない。

回復は三段階で書くべきだ。物理的安定は対象部品が十分な観測期間に再発しないこと。forwarding recovery は対象 treatment の packets が通ったこと。business recovery は application または customer acceptance が成立したこと。root cause の解消には、保守、光レイヤー、電源などの因果資料がさらに要る。