Extensible YANG Model for Network Telemetry Notifications

Introduction Nowadays network operators are using machine and human readable YANG to model their configurations and obtain YANG modelled operational data from their networks. Network operators organize their data in a Data Mesh where a message broker such as Apache Kafka or RabbitMQ facilitates the exchange of messages among data processing components. Today, subscribing to a YANG datastore, publishing a YANG modeled notifications message from the network and viewing the data in a time series database, manual labor is needed to perform data transformation to make a message broker and its data processing components with YANG notifications interoperable. Even though YANG is intented to ease data management, this promise has not yet been fulfilled for Network Telemetry. An Architecture for YANG-Push to Message Broker Integration defined an architecture for integrating YANG-Push with message brokers for a Data Mesh architecture. How the notification messages at a YANG-Push receiver is being transformed to the message broker is being described in Section , however the produced message format left unspecified. The message could be published as it was received from the network to their organization's message broker. However, this approach is insufficient for correct human and automated understanding of the data generated by the network. This insufficiency stems from not presenting a holistic picture along with the data generated by the network. In particular, when a data consumer in the data mesh consumes a YANG message from their organization's message broker, they cannot answer simple questions such as:

Which network operating system collected the data?
To which network platform belongs the network node?
What is the subscribed xpath, sub-tree filter and its schema reference?
When did the data collection received the data?
What additional metadata is necessary for a consumer to make sense of the data?

This document defines a standard YANG envelope message to carry with the collected Network Telemetry notifications the provenance and metadata information for a YANG data exchanged in message brokers for a Data Mesh architecture.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The terms "subscriber", "publisher", and "receiver" are used as defined in . In addition, this document reuses the terms defined in for the use in message broker enviroment: Notification Metadata: Additional data describing the context of a notification that is sent in each message, e.g. which node generated the messsage or at which time the notification was published. Notification Envelope: YANG structure encapsulating the payload of a notification, allowing the inclusion of metadata.

YANG Module The extensible YANG module for Network Telemetry notifications defines an envelope message schema which adds four metadata categories to the collected Network Telemetry notifications.

Network Node Provenance:: Is the provenance information about the network node that published YANG notifications to the receiver. This category adds metadata such as the node name, address, and software version to the message.

Data Collection Provenance:: Is the provenance information about the data collection. The data type is the same as the first category but specific to the collector node.

Data Collection Protocol Provenance:: Is the session information about the session between the collector and the network node. This category adds fields such as the session protocol and the time the event was generated in the network node. Moreover, this document defines an extension specific to YANG-Push that includes YANG-Push subscription information.

Network Operator Provenance:: Is the operator specific metadata. Some operators enrich the collected data with specific information. For instance: type of the network node (MPLS provider or provider edge node) or which operational unit the node is operated by. For this purpose the document defines a generic metadata map with key/values that can be used freely by the network operator.

Telemetry message YANG Module

Telemetry message YANG Module module ietf-yang-push-telemetry-message { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:yang-push-telemetry-message"; prefix yptm; import ietf-subscribed-notifications { prefix sn; reference "RFC 8639: Subscription to YANG Notifications"; } import ietf-telemetry-message { prefix tm; reference "XXX"; } import ietf-yang-push-revision { prefix ypr; reference "XXX"; } organization "IETF Draft"; contact "Author: Ahmed Elhassany <mailto:ahmed.elhassany@swisscom.com>"; description "Augments the ietf-telemetry-message with YANG Push specific fields. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2024-02-20 { description "Initial revision."; reference "RFC XXXX"; } augment "/tm:message/tm:session-metadata" { container yang-push-subscription { config false; leaf id { type sn:subscription-id; mandatory true; description "This references the affected subscription."; } container filters { description "Contains a list of configurable filters that can be applied to subscriptions. This facilitates the reuse of complex filters once defined."; list stream-filter { key "name"; description "A list of preconfigured filters that can be applied to subscriptions."; leaf name { type string; description "A name to differentiate between filters."; } uses sn:stream-filter-elements; } } uses ypr:yang-push-module-version-list; } } } ]]>

IANA Considerations TODO

Security Considerations TODO

References Normative References Informative References Data Mesh O'Reilly Media RabbitMQ Mozilla Public License Apache Kafka Apache Software Foundation

Acknowledgements TODO