Simplifying Network Programmability with Model-Driven APIs

Data Models provide a clear representation of the capabilities of a networking device with a definition that is structured, well defined and computer friendly. But, how does a programmer use models to control a networking device? The process can be a little bit involved. A client application and a network device need to agree on a protocol, encoding, transport and data structure. Traditionally, programmers require a set of libraries for the specific combination of protocol, encoding and transport that they intent to use. Furthermore, the application needs to be able to generate and handle configuration and operational data in compliance with the model implemented by the network device. As it should be obvious, there are several pieces to figure out before an automation application can take advantage of data models.

We have created the YANG Development Kit (YDK) to facilitate network programmability using data models. YDK can generate APIs in a variety of programming languages using YANG models. These APIs can then be used to simplify the implementation of applications for network automation. YDK has two main components: an API generator (YDK-gen) and a set of generated APIs. Today, YDK-gen takes YANG models as input and produces APIs that mirror the structure of the models. Why YANG? The choice of modeling language was obvious. YANG is the lingua franca for data modeling in networking. A growing number of devices and controllers support a growing number of YANG data models. For the generated APIs, we have initially targeted Python (YDK-Py) and C++ (YDK-Cpp). We expect the choices of the language to grow over time.

The generated APIs have three main components:

• Models: Class hierarchies that mirror the hierarchies that the YANG models specify. We bundle models (e.g. Cisco IOS XR, OpenConfig, IETF, etc) in separate packages, so users can have granular control of the model families that they install.

• Services: Classes that perform an action on model objects. They include a CRUD (create, read, update, delete) service that abstracts management protocols, services that provide direct access to protocols (e.g. NETCONF and RESTCONF), a service to encode and decode (serialize and deserialze) data, plus others.

• Providers: Classes that implement a service. A provider can implement multiple services and multiple providers can implement a service.

How these abstractions help the developer? They isolate developers from the protocol, transport and encoding specifics and allow them to focus on what is most important, the data structures and the automation logic. No need to code protocol specifics (e.g. NETCONF, RESTCONF) or manipulate serialized data (e.g. XML or JSON) directly. Furthermore, the APIs perform thorough local validation (e.g. type, value, config/oper, semantics, deviations, etc.) based on information embedded in the YANG model. This means that most errors are caught locally without having to communicate with the networking device. Last, the abstractions also make the automation applications more portable. An application could change providers (e.g. NETCONF with RESTCONF) with minimal changes to the code when using a service that supports multiple providers (e.g. CRUD service).

We open sourced YDK to help the industry reap the benefits of data models and facilitate the implementation of network automation. We encourage contributions. We would like to see an increasing number of models, services and providers, plus support for more programming languages. We have published APIs for Cisco IOS XR, OpenConfig and IETF data models. You can find the Python APIs in the YDK-Py repository and C++ APIs in the YDK-Cpp repository. In addition, we have made available hundreds of examples in the ydk-py-samples and ydk-cpp-samples repositories.

Join the discussion in the YDK community!