Continuing the Streaming Telemetry saga, let’s focus on presentation formats and transport mechanisms.

I already mentioned three presentation formats: XML (used by NETCONF), JSON (used by RESTCONF) and Protocol Buffers (used by gRPC). Two of them are text-based, the third one (Protocol Buffers) is binary encoding not unlike ASN.1 BER used by SNMP. That can’t be good in a JSON-hyped world, right?

Well, it depends. If you want to use a text editor (or tcpdump) to view the data sent by streaming telemetry, then you might prefer XML or JSON, if you want to parse it in your network management system then a binary encoding might be a bit faster. 

Is that difference worth the effort? After all, CPU cores aren’t exactly expensive these days. It depends on how much data you want to process. Interface counters every 30 seconds? Who cares. Real-time telemetry data sent every 100 msec? Yep, saving CPU cycles might make sense. Even more importantly, telemetry packets using binary data could be generated on (some, higher-end) ASICs while the text-based format usually implies using the central CPU. 

Remember the Modular QoS counters on Cisco IOS that were updated every 10 seconds no matter how often you wanted to read them? Maybe it’s not such a good idea to insert the bottleneck in form of underpowered CPU into the streaming path.

Also, if the vendors design the data structures within their network operating system the right way, the device could just dump the internal data structures (in Protocol Buffers format) instead of doing tedious translation into SNMP variables or XML/JSON format, saving tons of CPU cycles. Obviously, if those data structures were designed before considering the IETF (or OpenConfig) YANG data models, you'll still get the performance hit when asking for data that conforms to standard YANG data models.

The same argument applies to transport protocol. If the streaming telemetry uses datagram (UDP-based) protocol the telemetry packets could be generated on ASICs; if the transport protocol runs on top of TCP, it’s almost unavoidable to get the CPU involved.

Does anyone support streaming telemetry straight off ASICs? It was implemented in Junos a while ago; not sure about other vendors - if you know of anyone else, please write a comment including a link to publicly-available documentation.