In my last blog post, I talked about being able to see both sides of the equation and that knowledge of the device is equally important as knowledge of orchestration. This may be an oversimplification as this isn’t all there is in the full equation. There are a couple more elements that must be addressed: observability and controllability.
Observability is an important topic with regards to having insight into how systems are running and are they doing what is expected. Or if they are not doing what is expected, then why are they not? Observability has become a buzzword over the past year and something that everyone is taking notice of with regards to applications and end-user experiences. This is great but not everyone has it right, at least in my opinion, as it has a strong, if not stronger, importance in the networking side as well. It’s also important to note that without observability, you can’t have controllability.
Observability provides a feedback loop for controllability. In a feedback loop, you feedback the outputs of a system as new inputs in order to determine future results. Observability is the feedback into controllability. I should note that older names for network observability included monitoring and telemetry. By analyzing this data, you can make or even better, automate decisions on how to change the future state of the system through the control plane. By automating those decisions, you are moving towards Intent-Based Networking (IBN).
In the area of gathering observability data, there are some interesting things happening in the world of programmability. For example, there are new standards in the NETCONF world that we are supporting in ConfD. One example is Network Management Datastore Architecture (NMDA) that was designed based on real-world use of NETCONF and YANG. Part of NMDA is based on architecting the datastores in the devices with the goal of being able to set intended configurations and observe actual running configurations. NMDA helps to increase observability of the network and implement Intent-Based Networking (IBN). With an intent-based approach, you can look at the data and use automation to act based on the intent.
Another way that supports observability is happening today in the NETCONF worlds is YANG Push. Based on the approach of subscribing to YANG notifications, devices can supply observability data using a push mode notifications from the device rather than the traditional pull mode polls. These subscriptions are modeled in YANG and provide support for periodic pushes of data or on-change notifications based on trigger criteria. For example, you might have a physical device with a temperature probe, so you could use YANG Push to send a notification if the temperature goes past a configured high watermark.
These examples highlight how it is possible to set up feedback data for observability through programmability. The good news, support for NMDA and YANG Push has been added to recent ConfD releases. YANG Push, as of ConfD 7.5, has some experimental features around on-change subscriptions that we would love to get customer feedback on. If you have done some experimenting with YANG Push, let us know how it is going and if you have any suggestions for improvement.
The point of all of this is that having the right approach creates better observability in your network. If you want to read a bit more on this topic, we have a couple of application notes that might be of interest to you: