Network automation is important, as I’ve been stressing for years. See for example this blog: “Automation is as good as your data models, their related metadata, your toolchain, and what you can do with them“. Specifying those building blocks, in a standard way, can help operators reducing the cost of managing their networks.
Today, let me show some new capabilities, recently published as IETF RFCs.
The first building block is the “YANG Modules Describing Capabilities for Systems and Datastore Update Notifications” [RFC 9196]. Well, you’re going to tell me that a mechanism for exchanging capabilities between the Network Management System (the “client” in YANG terms) and the routers (the “server” in YANG terms) exists already with the “YANG library” (RFC 8525). And you would be right: a client can query the server capabilities from a live server, determining this way the API contract between the two entities.
The “from a live server”, so at runtime, sure! However, the NMS implementors, system integrators, and in the end operators would also benefit from the same information at the implementation-time (or even at design time), as stressed in the RFC 9196:
If the information is not documented in a way that is readily available to the NMS designer, but only as instance data from the network node once it is deployed, the NMS implementation will be delayed because it has to wait for the network node to be ready. In addition, the assumption that all NMS implementers will have a correctly configured network node available from which to retrieve data is an expensive proposition and may not always hold. (An NMS may need to be able to handle many dozens of network node types.) Often, a fully functional NMS is a requirement for introducing a new network node type into a network, so delaying NMS readiness effectively also delays the time at which a new network node type can be introduced into the network.
Focusing on this implementation time use case, the question is how to “expose” those server capabilities in a way that :
- is vendor independent
- is machine readable
- is available in an identical format both at implementation time and at runtime
This is where a companion RFC, “A File Format for YANG Instance Data” [RFC9195], comes into play. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. From a high level, you can see this as an instance data of the IETF YANG Library YANG module, available for consumption even when the server is not online … or not even implemented yet.
As a concrete example, the need to specify capabilities in the YANG-Push functionality [RFC8641]. These includes: supported (reporting) periods for “periodic” subscriptions, the maximum number of objects that can be sent in an update, the set of datastores or data nodes for which “periodic” notification is supported. Additional capabilities if the optional “on-change” feature is supported include: supported dampening periods for “on-change” subscriptions, the set of datastores or data nodes for which “on-change” notification is supported.
The module “ietf-system-capabilities” [RFC 9196] is defined to provide a structure that can be used to discover (as a read-only operational state) any of those YANG-related system capabilities.
You can expect some more example in the future. Here is another one, “Per-Node Capabilities for Optimum Operational Data Collection” (still an individual IETF draft).
Summarizing the ways of exposing these capabilities for the two different use cases, implementation-time and runtime, the RFC mentions:
For the implementation-time use case: Capabilities SHOULD be provided by the implementer as YANG instance data files complying with [RFC9195]. When provided, the file MUST already be available at implementation time and retrievable in a way that does not depend on a live network node, e.g., downloading from a product website.
For the runtime use case: Capabilities SHOULD be available via NETCONF [RFC6241] or RESTCONF [RFC8040] from the live server (implementing the publisher) during runtime. Implementations that support changing these capabilities at runtime SHOULD support “on-change” notifications about the system-capabilities container.
That way, once the server is eventually online, the current capabilities may be retrieved via NETCONF/RESTCONF, with the same format as during the implementation-time.