In 2014, work on “Requirements for Subscription to YANG Datastores” started at the IETF, eventually finalized as RFC 7923. This document provides the telemetry foundational set of requirements for a service that can be summarized as a “pub/sub” service for YANG datastore updates. Based on criteria negotiated as part of a subscription, updates are pushed to targeted recipients, which eliminates the need for periodic polling of YANG datastores by applications. The document also includes some refinements: the periodicity of object updates, the filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. “Requirements for Subscription to YANG Datastores” is a quick and easy read, providing the right terminology, offering the business drivers for a push solution, comparing (quickly) the pub/sub mechanism to SNMP, describing some use cases, and providing a series of requirements. Reading this document and specifically those requirements can help you understand the goals behind YANG subscription, which is the basis for model-driven telemetry.

The second half of 2019 finally saw the publications of 4 IETF RFCs, resulting from these requirements:
– Subscription to YANG Notifications, RFC 8639
– Dynamic Subscription to YANG Events and Datastores over NETCONF,
RFC 8640
– Dynamic Subscription to YANG Events and Datastores over RESTCONF,
RFC 8650
– Subscription to YANG Notifications for Datastore Updates, RFC 8641

The main building block is the first document: “Subscription to YANG Notifications” document. Basically, this enables a “subscribe, then publish” capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed. The receiver then gets a continuous, customized feed of publisher-generated information. This new specifications provides a superset of the subscription capabilities initially defined within “NETCONF Event Notifications” (RFC 5277), taking into account its limitations. It specifies a transport-independent capability (the old 2008 RFC 5277 is specific to NETCONF), a new data model, and a remote procedure call (RPC) operation to replace the operation “create-subscription,” and it enables a single transport session to intermix notification messages and RPCs for different subscriptions. What is identical between the old and new specifications is the message and the contents of the “NETCONF” event stream. Note that a publisher may implement both specifications concurrently. Let’s list the key capabilities, as taken from the “Subscription to YANG Notifications” document.

Various limitations to subscriptions as described in [RFC5277] were alleviated to some extent by the requirements provided in [RFC7923]. Resolving any remaining issues is the primary motivation for this work. Key capabilities supported by this document include:

– multiple subscriptions on a single transport session

– support for dynamic and configured subscriptions

– modification of an existing subscription in progress

– per-subscription operational counters

– negotiation of subscription parameters (through the use of hints returned as part of declined subscription requests)

– subscription state change notifications (e.g., publisher-driven suspension, parameter modification)

– independence from transport

The specification is transport agnostic, therefore transports like NETCONF or RESTCONF can be used to configure or dynamically request subscriptions. Note that the lifetime of a dynamic subscription is bound by the transport session used to establish it:

• loss of the stateful connection-oriented transport in NETCONF
• lack of receipt acknowledgment of a sequential set of notification message and/or keep-alives for the stateless HTTP transport in RESTCONF)

Bindings for subscribed event record delivery for NETCONF and RESTCONF are defined in Dynamic Subscription to YANG Events and Datastores over NETCONF, RFC 8640 and Dynamic Subscription to YANG Events and Datastores over RESTCONF, RFC 8650 , respectively the second and third in the set of published documents mentioned above.

The last document in the set, Subscription to YANG Notifications for Datastore Updates, RFC 8641, specifies a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore.

Next to the IETF track, let’s look at Openconfig, along with the timeline!

The IETF started from the requirements, with a complete model-driven telemetry solution. About two years later, in 2016, OpenConfig started to focus on streaming telemetry: it started small, from an opensource point of view, with iterations. In the meantime, it took quite some time for the IETF to publish their specifications: from the start of the requirements to the RFC specifications, about 5 years.

While there were initially some fundamental differences between the two solutions: Initially, the Openconfig streaming telemetry solution did not cover all the functionality foreseen by the IETF. However, along the time, more and more functionality has been added implemented in Openconfig streaming telemetry, while gaining experience and facing new requirements. In the end, they became almost identical, with the few exceptions:

• Openconfig streaming telemetry focuses on protobuf as encoding with gRPC protocol
• For the IETF solution, even the dynamic subscriptions use the YANG model for configuration: this is a key difference with the Openconfig dial-in feature, which doesn’t require the openconfig-telemetry YANG model for configuration.

The next figure compares the capabilities of the two solutions.

gNMI

The OpenConfig streaming telemetry, with its YANG module, was the first OpenConfig evolution. gNMI, as a second evolution of streaming telemetry. gNMI telemetry makes use of the SubscribeRequest for dial-in, as opposed to use the telemetry YANG model as a first configuration step. The collector dials into the publisher and specifies the objects it wants to monitor. More on gNMI in a future blog.

In the end, the market will decide!

Looking at the model-driven telemetry figure, it’s clear that the IETF effort started the initiative. However, taking about 5 years for the specifications is way too long in a networking world that requires fast innovation. In the meantime, the OpenConfig streaming telemetry approach gained traction, mainly thanks to its open source code and tooling approaches. Now that the IETF specifications are finally published, the market will decide which approach will survive between … if not both. Or maybe the market has already decided?