要約

  • 2026年9月10日付のdraft-claise-green-capability-discovery-01は、電力状態の能力モデルに最大電力と、状態へ入る時間・戻る時間の標準値および最大値を加えた。
  • 能力は導入前のインスタンスデータでも、稼働装置の読み取り専用データでも提供できる。電力値、遷移時間、部品の網羅性はいずれも欠ける場合がある。
  • 草案は許される遷移を定めず、書き込み操作も提供しない。公称電力は計画値であり、現実の消費量、節電実績、その時点で休止してよいという許可ではない。
  • 文書はまだ個人Internet-Draftで、ワーキンググループ採用は記録されていない。運用には、能力、権限、装置応答、実測電力、サービス結果を結ぶ別の証跡が要る。

起こしてよいかは復帰時間だけでは決まらない

ラインカードの通常運転が200ワット、休止時が15ワットなら、差は185ワットになる。標準的な復帰が800ミリ秒、最悪でも2秒という値もあれば、休止候補を選ぶ材料はかなり増える。

それでも、そのカードが単一経路を支えているか、迂回先に余裕があるか、2秒が契約上許されるかは分からない。現在の負荷や温度による実消費も見えない。まして、誰が変更を承認し、装置が要求を受け入れるかは能力欄の仕事ではない。

今回の改訂が浮かび上がらせるのは、この役割分担である。共通形式は比較を助ける。だが、比較可能であることと、操作可能であることは同じではない。

改訂01が増やしたもの

Datatrackerは、A YANG Data Model for Power State Capability Discoveryを有効な個人Internet-Draftとして表示している。履歴では、00版が8月25日、01版が9月10日に登録された。RFCストリームもワーキンググループ状態もない。本文の表紙にStandards Trackとあっても、それは目標であって、GREENによる採用、IETF合意、IESG承認、RFC化を意味しない。

00版と01版の差分を見ると、変更は単なる整理ではない。状態ごとのmax-power、入出それぞれの標準時間と最大時間、部品単位の不完全な網羅を扱う規則、具体例が追加された。

同時に、未決事項も明記された。装置全体の能力欄を部品欄とは別に持つべきか、メーカーが遷移時間を提供できるか、Nameplate Powerを「通常値」と「最大設計値」のどちらで使うかは確定していない。未決の定義を残すことは、偽の精密さを避けるための統治でもある。

能力、制御、結果の三つを混ぜない

提案モジュールはRFC 9196のシステム能力モデルを拡張する。装置全体の既定値か、RFC 8348のハードウェア台帳にあるシャーシ、ラインカード、ポート、光モジュールなどを指定できる。GREENの電力・エネルギーYANG草案は、同じ部品名に現在の管理状態、実動状態、瞬時電力を結び付ける。

能力情報は静的である。メーカーはRFC 9195のインスタンスデータとして電源投入前に配布できる。稼働中なら、RFC 8342の運用datastoreから同じ形で読める。どちらも「何をサポートすると宣言しているか」を扱う。

制御は別である。この草案のノードはすべてconfig falseで、書き込みデータ、RPC、アクション、通知を持たない。どの状態間の遷移が許されるかも範囲外だ。別のGREENモデルに要求を書いても、装置には受理または拒否する余地がある。

結果はさらに後に生じる。到達状態、実電力、退避したトラフィック、復帰遅延、サービス影響は測らなければならない。要求が通ったという記録だけで、節電成功とは言えない。

未掲載の部品をゼロとして足さない

電力の値は任意であり、対応状態だけを報告する装置も認められる。段階導入では一部部品だけに能力欄があってよい。欄のない部品は「不明」であって、消費ゼロでも休止不能でもない。

合計にも条件がある。各部品の値はその部品だけを表し、ハードウェア階層の子部品を自動では含まない。関係するサブツリー全体を照合し、一度ずつ数えた場合だけ合計は完全になる。それ以外は下限値にすぎない。

公称値も実測値ではない。負荷、温度、設置条件で消費は動くため、01版はnominal-powerを計画基準として扱うよう求める。省電力経路配置の草案が緩やかな値を配布する場合と、中央制御がリアルタイムのテレメトリーを集める場合では用途が違う。

遷移時間も任意の定格値である。30秒かけて戻る省電力状態は、遅延に敏感な回線には使えないかもしれない。最悪時間と対象サービスの予算を照合して初めて、利用可能性を判断できる。

読み取り専用でも機微情報になる

長い復帰時間と大きな削減余地は、繰り返し起こす、眠らせない、容量を揺さぶるといった妨害の狙い目も示す。草案は安全な管理通信と相互認証に加え、RFC 8341のNACMで読み取りを制限するよう促す。

導入前ファイルには、メーカー、製品、ハードウェア版、作成時刻、ハッシュ、対象範囲を残すべきだ。実機からの取得には、装置ID、ソフトウェア版、台帳版、取得時刻、経路が要る。同じスキーマを使っていても、出所と鮮度は同じにならない。

実行時の遷移証跡を残す

影響のある操作では、対象部品と台帳版、能力の出所と経過時間、サブツリーの完全性、電力値の前提、標準・最大遷移時間、現在の実測値、負荷と通信上の役割、サービス目標、承認した主体、要求内容、装置の受理・拒否、到達状態、実測のエネルギー差、サービス影響、戻し条件を一つの証跡に結ぶべきだ。

これはDaniel Kadeの編集上の提案であり、草案やGREENの要件ではない。Heng Luの最小初期仕様論が示すように、共有層は比較に必要な最小限にとどめ、将来の判断は現場に残せる。The Policy Mirrorは制御面ごとの主体を問い、Reality, Not Advocacyは提案と観測済みの結果を区別する。

GREENの憲章は活動領域を示すが、この個人草案を採用した証拠ではない。IANAへの登録要求も現在の登録ではない。01版の前進は、能力を詳しくしたことだ。運用権限まで先取りしてはいない。

情報源