Open Source Model Driven Network Programmability

Imagine being able to use a single API to communicate with any piece of network equipment regardless of vendor. Imagine if this API used standards-based YANG models and even permitted the use of custom YANG models. Imagine if this API was open source.

Within the next few months, you won’t have to imagine anymore. Network to Code has been working hard to make this a reality.

The Problem Statement

Before we look at the solution, let’s level-set the problem.

While many of the modern network operating systems (NOSs) offer APIs nowadays, many of them are unique per vendor, or worse, they are unique per platform. Of course, there are still even more legacy platforms in production without API support. Those devices offer SSH access to the device’s command line interface (CLI). In both of these use cases, the data returned from a command or API call is vendor-specific.

Note: While we know a few vendors have added support for vendor-neutral data models, they are few and far between, are often buggy, and often lack parity with other platforms and vendors.

If the data returned is vendor-specific, it means that to consume the data and streamline network automation activities, there needs to be some level of data normalization. The act of normalization needs to consider both text parsing for legacy devices and transforming already structured data such as JSON/XML into the normalized and desired-state structured data. Moreover, for a comprehensive solution that also includes configuration management, the normalization process needs to have ways to translate the normalized data back into the vendor’s native configuration (specific CLI commands or structured data).

The Solution

The easy response to this is that all vendors and devices should support the same models and APIs (and we agree!). However, it’ll be a while. The industry moves slowly. While progress is being made in the industry on routers and switches, consider different device types like firewalls and load balancers. There is still much work to be done here (more vendor support and demand from buyers is needed).

Network to Code to Open Source Model Driven Programmability API Framework

In order to mitigate the problem at hand and move the industry forward, Network to Code will be open sourcing four different projects creating a vendor-neutral and extensible RESTCONF API. This API will be able to talk to any device with any OS including legacy devices that only support SSH.

The four projects we’ll be releasing, in the order of which they’ll be released:

Yangify

Yangify is an engine that focuses on parsing and translating native configuration into JSON-encoded YANG data using native Python in contrast to a domain specific language (DSL). It takes native configuration from the likes of show commands and creates a structured and methodical approach to create JSON data that adheres to YANG models. It also translates YANGify’d JSON into the native configuration (CLI commands or native JSON/XML). For anyone that has been doing any text parsing on their journey already, Yangify is analogous to TextFSM, although Yangify parses and translates, not just parses.

Rosetta

Rosetta provides two core functions. First, the Rosetta project will store all Yangify parsers and translators. Second, it’ll provide an intuitive Python interface to consume all of the parsers and translators. Rosetta is analogous to ntc-templates with the TextFSM analogy.

NTC YANG Models

Standards-based YANG models are actually quite complex and nested and usually have a steep learning curve. These models need to account for nearly every use case a feature may have. In order to obtain the benefits model-driven APIs, but make them easier to consume and practical for most Enterprises, this project will contain a combination of stripped down standards-based YANG models and extremely simplified models focused on the core feature sets often found in Enterprise networks.

Rosetta RESTCONF API

The capstone to all of this is a lightweight RESTCONF API that brings together all of the aforementioned functionality, but also integrates southbound connectivity to network devices making this a complete multi-vendor API. The API will communicate with network devices while parsing and translating native configurations in real-time. The Rosetta RESTCONF API will also support candidate configurations and the ability to hook into other systems using the Python API, configurable and triggered on any incoming API call. In order to achieve device connectivity, NAPALM will be used within the Rosett RESTCONF API.

Bringing everything that will be open sourced and combining it with NAPALM, the following is a visual representation of what the full stack looks like for the Rosetta RESTCONF API.

The Rosetta RESTCONF API

I’d also like to extend a huge thanks to David Barroso for the core development of these projects and helping make them a reality.

Interested to hear more? Feel free to reach out! Otherwise, come back next week to hear more about Yangify, when it gets released.

Happy Automating!

Jason