SDN in the Management Plane: OpenConfig and Streaming Telemetry

SDN in the Management Plane: OpenConfig and Streaming Telemetry

See more at: https://www.nanog.org/meetings/abstract?id=2573#sthash.y5xYlSmA.dpuf 

The networking industry has made good progress in the last few years on developing programmable interfaces and protocols for the control plane to enable a more dynamic and efficient infrastructure. Despite this progress, some parts of networking risk being left behind, most notably network management and configuration. The state-of-the-art in network management remains relegated to proprietary device interfaces (e.g., CLIs), imperative, incremental configuration, and lack of meaningful abstractions.

We propose a framework for network configuration guided by software-defined networking principles, with a focus on developing common models of network devices, and common languages to describe network structure and policies. We also propose a publish/subscribe framework for next generation network telemetry, focused on streaming structured data from network elements themselves.

All the usual problems: CLIs are proprietary, scaling sucks, screen-scrape sucks, etc.

However, these are SDN shops, so they can change stuff in software and stop waiting for vendors to never fix things. New world order. But wait! Didn't they hear that Cisco is a software oriented company?!

Propose: "model-driven network management"
1. topology
2. configuration
3. telemetry

Telemetry:
SNMP default choice. Old protocol, choices were made to conserve limited resources of the time.
Asking for requirements on a new telemetry protocol to replace SNMP.
gRPC, Thrift, or transport buffers over UDP (sounds like SNMP)
streaming telemetry is the goal, ask you vendors

Config:
OpenConfig effort - informal industry collaboration (operators, not vendors). Motivated by lack of abstractions and programmability, all the usual litany of complaints people have been repeating for years and vendors have not been addressing.
Focus on vendor-neutral configuraiton and operational state models - adopted YANG DML (rfc 6020)
Weekly meetings, github repository
No legal structure to this group, nothing formal, trying to avoid that overhead (and political layer)
Their approach is operations specific, don't want to care about standards politics
Looks like the IETF and other groups are now being ignored when people need to get work done. Yet another new world order.

"It's time for the management plane to join the age of SDN"

They do not intend to play game according to vendor's rules. "The fact that there is a different set of commands for BGP across vendors and devices is ridiculous and there is no reason for it that we can see."

Q: Why don't vendors adopt approaches used by server admins, puppet, chef, etc. Why not use the same technology? A. tools for server management may not apply across the board to more complex pieces of network gear with complex configs. However, the models are key, and models can use JSON encoding and with puppet/chef.

Q. Why push this in this way? There are a number of repositories for YANG stuff. Why is what you are doing is different? A. we are publishing models into some of the same repositories, We are also working with IETF, however this is consumer view and operators view so our perspective is different.

Q. are you positing to say IETF is not effective forum for operators to work with? A. we are trying hard to work with ietf and it hasn't been easy.

Q. how can we avoid doing MIBs all over again in new formats? A. operator-based view, pushing vendors to support a base model, trying to keep lean. vendors should be able to add their own stuff, but should be programmable unlike past. Q. when dealing with vendors if you give them an inch and they will take a mile. A. we are trying to make base model as complete as possible, so challenge to vendor is what do you need that isn't in base?

Q. Igor response - IETF moves very slowly. IETF structured into very different hierarchies. Creates one guidance for structure for every hierarchy.  "make everything look the same" and so we are avoiding that, and we will be feeding this back to ietf with information drafts. Basic answer: ietf is too slow and their org is not helpful.