RFC 10016: System-Defined Configurationの通信シーケンスとデータ構造を整理する

ネットワーク・RFCカテゴリを表すパンダのイラスト ネットワーク・RFC

本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。 、RFC 10016で規定された「System-Defined Configuration」の概念と、ネットワーク管理データストアアーキテクチャ(NMDA)における位置づけを安全かつ実用的に読み解きます。デバイス自身が提供する構成データストアの仕組みや、クライアント管理下のデータストアとの統合モデルを仕様に基づいて整理します。


目的

RFC 10016(System-Defined Configuration)の仕様書をもとに、システム構成データストア(<system>)の定義、従来のコンフィギュレーションデータストアとの関係性、およびデータマージの概念を明らかにすることを目的とします。

前提・注意点

  • 本記事はインターネット標準トラック文書である RFC 10016 の公開情報に基づいています。

  • クライアントからの直接的な書き込みが禁止されている読み取り専用データストアの挙動を対象とします。

  • 【Windows環境で確認予定】の実機検証を行う場合は、対応するNETCONF/RESTCONFサーバー環境およびYANGモジュール(ietf-system-datastore)の導入状況に依存します。

システム構成データストア(<system>)の概要

Network Management Datastore Architecture (NMDA) を定義した RFC 8342 では、デバイス自体が供給し運用状態に現れるシステム構成の概念が存在していました。しかし、稼働中であるかどうかにかかわらず、サーバーがシステム構成をより明確に公開する標準的な仕組みが求められていました。

RFC 10016 は、この要求に応えるため読み取り専用のコンフィギュレーションデータストアである <system> を導入します。これにより、NETCONFやRESTCONFクライアントはサーバー上で利用可能なシステム構成を標準的な手法で取得できるようになります。

flowchart TD
    Candidate["<candidate> (rw)"] --> Running["<running> (rw)"]
    Startup["<startup> (rw)"] --> Running
    System["<system> (ro)"] --> Intended["<intended> (ro)"]
    Running --> Intended
    Factory["<factory-default> (ro)"] --> Running
    Intended --> Operational["<operational> (ro)"]

システム構成の種類

一次情報では、システム構成は大きく分けて以下の2種類が存在すると説明されています。

  1. Always Present(常時存在する構成)

    • デバイスの電源が投入された際に、物理リソースの有無や特定機能の有効・無効にかかわらず生成される構成です。例として、常に存在するループバックインターフェイスなどが挙げられます。
  2. Conditionally Present(条件付きで存在する構成)

    • 特定の条件が満たされた場合にのみ生成される構成です。例えば、インターフェイスカードなどの物理リソースが挿入された際に自動検出されて読み込まれる構成や、特定のライセンス・機能が有効化された際に作成される構成が含まれます。

データストアの概念モデルとマージ処理

クライアントは、<running>内で<system>で定義されたノードを参照したり、システム提供の値を上書きしたり、システム定義構成の子ノードを設定したりできます。

<intended>の有効性を保証するため、<running>の構成は<system>とマージされます。このプロセスでは、<running>に現れる構成が<system>の同じノードよりも優先されます。また、テンプレートの展開や非アクティブな構成の削除といった構成変換が必要な場合、それらの変換は各データストアに対して独立して実行された後にマージが行われます。

クライアントからの操作に関する制限事項

<system>データストアは読み取り専用であり、クライアントからの直接的な編集要求は拒否されなければなりません(MUST)。また、<system>内の構成はリプロート(再起動)をまたいで永続化されるものではなく、クライアントがプロトコル操作を通じて削除することもできません。

リソースの消失などによりシステム構成からデータが消去された場合でも、未適用の構成として<running><intended>に残る場合がありますが、実効状態を示す<operational>には現れません。

まとめ

  • RFC 10016で追加された<system>データストアは、デバイス自身が提供する読み取り専用の構成データストアです。

  • クライアントは直接書き込みを行えませんが、<running>側で値を上書きしたり参照したりすることが可能です。

  • 実行前に確認すべき点として、対象機器のNMDA対応状況、ietf-system-datastore YANGモジュールの実装有無、およびプロトコル(NETCONF/RESTCONF)の仕様適合性を検証環境ごとに確認する必要があります。

参考情報

文書情報

記事タイトル
RFC 10016: System-Defined Configurationの通信シーケンスとデータ構造を整理する
作成日
更新日
Source URL
https://papanda925.com/?p=17147

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

タイトルとURLをコピーしました