{ “source”: “IETF Draft (draft-ietf-netconf-notification-messages / draft-ietf-netconf-distributed-notif)”, “status”: “Active Internet-Draft (In-progress)”, “category”: “Network Management / YANG Push Telemetry”, “technical_keywords”: [“YANG-Push”, “Message Broker”, “Kafka”, “MQTT”, “Binary Encapsulation”, “CBOR”], “engineer_level”: “Senior Network Engineer / Architect” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Draft: Notification Messages over Message Brokers (draft-ietf-netconf-notification-messages)

【背景と設計目標】

従来のNETCONF/RESTCONFセッションに依存しない、スケーラブルなメッセージブローカー経由のテレメトリ配信標準化を目指す。RFC 8639/8641のサブスクリプションモデルを拡張し、KafkaやMQTT等の外部ミドルウェアとの統合を可能にする新規設計である。

【通信シーケンスと動作】

本ドラフトでは、Publisher（ネットワーク機器）が直接Receiverにデータを送るのではなく、Message Brokerを介して非同期に配信する構造を定義している。

sequenceDiagram
    participant "P as Publisher (Router/Switch)"
    participant "B as Message Broker (Kafka/MQTT)"
    participant "R as Receiver (Collector/Controller)"

    Note over P, R: 制御プレーンでのSubscription確立 (NETCONF/RESTCONF)
    R ->> P: Establish Subscription (YANG-Push)
    P -->> R: 200 OK (Subscription ID assigned)

    Note over P, B: データプレーンでの配信
    loop Telemetry Export
        P ->> B: Encapsulated Notification Message (Header + Payload)
        B ->> R: Distribute to Topic/Subject
    end

    Note over R, B: 動的なスケールアウト
    R ->> B: Subscribe to Topic
    B -->> R: Push Stream

【データ構造 / パケットフォーマット】

ブローカーへ送信されるメッセージは、共通ヘッダーとシリアライズされたYANGデータ（JSON/CBOR/Protobuf）で構成される。以下はカプセル化ヘッダーの概念構造である。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V (4bit) | Type (4bit) | Reserved (8bit) |   Header Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Subscription ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Message Epoch                         |
|                      (Timestamp 64-bit)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq No|              Optional Metadata...             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Payload (CBOR / JSON / XML / Protobuf)            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

【技術的な特徴と比較】

• Decoupling: PublisherはReceiverのIPアドレスや負荷状態を意識せず、Brokerに対してのみ送信を行う。

• Binary Support: JSONだけでなくCBOR等のバイナリ形式を標準化し、高頻度な更新におけるペイロードサイズを削減。

【セキュリティ考慮事項】

• エンドツーエンドの機密性: Brokerが信頼できない環境（パブリッククラウド等）にある場合、メッセージレベルの暗号化が必要となる。本ドラフトでは、ヘッダーに暗号化フラグやKey IDを含める検討が進んでいる。

• 認証と認可: PublisherとBroker間、BrokerとReceiver間の相互認証（mTLS推奨）が必須。また、特定のTopicに対するPublish権限をRBACで制限する必要がある。

• リプレイ攻撃耐性: 64-bitのTimestamp（Epoch）とSequence Numberの組み合わせにより、順序逆転や重複メッセージの検知を可能にする。

【まとめと実装への影響】

1. スケーラビリティの劇的向上: ネットワーク機器が数千台規模の環境において、各デバイスがコレクタとの直接セッションを維持する負荷から解放される。

2. エコシステムの統合: Kafka等、ITインフラで一般的なメッセージバスにネットワークテレメトリが直接統合され、AI/MLパイプラインへの投入が容易になる。

3. 実装の複雑化: 従来のNETCONFスタックに加え、Broker固有のクライアントプロトコル（librdkafka等）やバイナリシリアライザの組み込みが必要となり、デバイスのリソース設計に影響を与える。