OpenConfig on Cisco Platforms

There’s a lot of buzz around just now when it comes to supporting vendor-neutral data models at the device layer, so it’s a good time to talk about what Cisco is doing to support open models, and OpenConfig models in particular.

Customers have been rapidly adopting automation techniques to reduce the costs and increase reliability of the day-to-day operations of the network, and we have a whole sub-industry built up around the growing number of data model-based interfaces presented by network devices, Slack rooms devoted to discussing network automation (consider signing up to networktocode if you haven’t already!), etc. Equipment vendors are waking up to this new emphasis on automation, but are we just building the XML/JSON/GPB equivalent of our multiple CLI dialects? Or are we really getting to grips with model-driven manageability and programmability?

Cisco has a growing commitment to models, and developers can look at the models we are publishing for IOS-XR, IOS-XE and NX-OS. More, developers can also se the shift of emphasis towards open models, be they from the OpenConfig Group, the IETF or any other body that helps design and publish vendor-neutral data models that address customer/operator requirements. And, as part of that commitment, we’re baking open models into the core of our manageability infrastructure across our platforms, so it’s useful to look how and what Cisco is doing, and what developers can already use to ease network automation day-to-day.

The reference architecture across our core IOS-XR, IOS-XE and NX-OS platforms looks something like:

The overlay models Cisco is focusing on today are those from the OpenConfig Group, and in the most recent release of IOS-XR, 6.1.2, we have support for:

• openconfig-bgp.yang:
  • openconfig-bgp-multiprotocol.yang
  • openconfig-bgp-operational.yang
  • openconfig-bgp-policy.yang
• openconfig-interfaces.yang:
  • openconfig-if-aggregate.yang
  • openconfig-if-ethernet.yang
  • openconfig-if-ip.yang
• openconfig-mpls.yang:
  • openconfig-mpls-igp.yang
  • openconfig-mpls-ldp.yang
  • openconfig-mpls-rsvp.yang
  • openconfig-mpls-sr.yang
  • openconfig-mpls-static.yang
  • openconfig-mpls-te.yang
• openconfig-routing-policy.yang
• openconfig-telemetry.yang
• openconfig-vlan.yang

These models address both configuration and operational state, incredibly important as automation transitions from being mainly about configuring the network to actually operating the network. So, the same models will be used to describe the data traversing telemetry feeds relating to performance, routing changes, etc.

While coverage isn’t yet complete for these models, each new release broadens coverage, and, as we move into 2017, developers will also begin to see support for OpenConfig models on IOS-XE and NX-OS platforms, starting with the core set of models already supported on IOS-XR. Looking a little further ahead, Cisco is also looking at support for the expanding OpenConfig ecosystem, including openconfig-platform, openconfig-acl, openconfig-network-instance, openconfig-fib, openconfig-isis, and more over time.

We also realize that open models, by their very nature, represent commonality across multiple vendors and a focus on the use cases of the model authors, which the OpenConfig Group spells out on their home page:

“OpenConfig’s initial focus is on compiling a consistent set of vendor-neutral data models (written in YANG) based on actual operational needs from use cases and requirements from multiple network operators.”

You can listen to a deep-dive presentation on Open Network Management by Anees Shaikh, from Google, delivered at a Tech Field Day event Cisco sponsored last year.

So, while the current scope of OpenConfig models may address the needs of some customers, others have learned that these models do not yet express the entirety of their configurations. To address this, Cisco is evaluating how to provide augmentations to OpenConfig models, which will cover features that maybe not all customers use, but which are, nonetheless, important. These augmentations would allow customers to work inside a single frame of reference as coverage is built out, rather than having to deal with a mix of OpenConfig models, native models and CLI.

With the growing support across the industry for open models and with their expanding coverage, we are lowering barriers to entry for those who wish to automate their networks. We are making it simpler to roll out config, to figure out what your devices are doing, and to collect data for analytics. While screen scraping is still a day-to-day reality, models are coming, and they are starting to make it easier to automate day-to-day operations!

To follow up on network automation, programmability, telemetry and more with XR and other Cisco platforms, take a look at the resources you can find on @xrdocs and Cisco’s Open Device Programmability site.

 

Save