Model-Driven Telemetry Isn’t as New as Some People Think
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 streaming telemetry is becoming standardized and as is often the case, the beauty of having standards is that there are so many to choose from:
- 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.
There are reasons this happens and there are also reasons it should not happen.
http://blog.ipspace.net/2017/04/netconf-agents-on-cisco-ios-xe-16x.html
Still not much better than lipstick on a pig; for example, there's no candidate config and commit because you cannot get that done on IOS at all.
http://blog.ipspace.net/2017/03/netconf-transactional-consistency-on.html
I'd also point out that the server and platform SaaS vendors have been doing telemetry for years...nee gRPC Openconfig. The network industry is in catch-up mode and not really seeing customers flex their muscle with requests to conform to more generic telemetry capture tools and standards.
The gNMI spec covers a standard encoding method, at least when using GPB for telemetry data. Vendors are working on implementing that now and at least we may have a key/value format that is standard across vendors even if the paths and values are not. Standard models like OC or IETF solve some of those issues where possible.
https://dictionary.cambridge.org/dictionary/english/telemetry
Not sure everyone would understand that to imply push or streaming.
it needs to define more comparison between two protocol types rather than push versus poll.
SNMP trap is pushing mechansim so really it confuses people this way.