During the Campus Evolution with Cat9K presentation (I hope I got it right - the whole event was an absolute overload) the presenter mentioned the benefits of brand-new model-driven telemetry, which immediately caused me to put my academic hat on and state that we had model-driven telemetry for at least 30 years.
Don’t believe me? Have you ever looked at an SNMP MIB description? Did it look like random prose to you or did it seem to have some internal structure?
As I explained in the Data Models and Data Stores part of Building Network Automation Solutions online course and in Intent-Driven Networking and Data Models part of Network Automation Use Cases webinar (included in ipSpace.net webinar subscription), data model is nothing more (and nothing less) than a description of a data structure, and the first data models we had in networking were SNMP MIBs, currently described in a data description language called SMIv2.
Long story short: please stop talking about the beauties of model-driven telemetry in 2017. It makes you look silly to anyone who actually understands what you’re talking about.
So what was the presenter trying to tell us? The real change from the days of SNMP is the delivery paradigm - we moved from polling to streaming. Sounds like Latin? It’s really easy:
Polling - the network management system wants to know a value of one or more variables (example: interface counters) known to the networking device. It sends a request listing the variables it’s interested in, the device parses the request, collects the values, and returns them in a reply. The whole process is repeated every time the network management system feels it’s time to get a new set of values.
Streaming - the network management system knows it periodically needs values of a set of variables, so it tells the device what it needs, and the device sends the values without being asked (the streaming part) either when the variables change or at regular intervals.
Streaming telemetry reduces the load on both network management system (because the periodic polling is gone) and the network device (because it doesn't have to parse the same request for the same set of variables every few seconds).
Other fringe benefits: YANG has richer data structures than SMIv2 (not everything is a tree), making a few things a bit easier.
Which standards do you want to use today?
- The data model describing the telemetry data is usually described in a YANG data model. In the ideal world that model would be defined by an independent organization (where you can choose between IETF and OpenConfig). In reality, a lot of stuff uses vendor data models (think vendor-specific MIBs);
- The encoding of data could be done using JSON, XML (both are text formats) or Protocol Buffers (a binary format);
- The data could be sent over NETCONF, RESTCONF or gRPC transport.
Sounds like another incarnation of SIP? You’re not exactly wrong ;)
Does it matter? Absolutely. More about that in another blog post. In the meantime (as I started with a Cisco Live presentation), it’s worth noting that Cisco IOS XE supports NETCONF now, RESTCONF soon, and gRPC sometime in the future.