I recently came across a TechfieldDay video from the IOS-XR team at Cisco discussing model driven programmability and manageability on IOS-XR based devices.

This approach is intended to replace how we currently management network devices.

Programmability

There appears to be two main ways of interacting with the IOS-XR devices programmatically.

• Model-driven approach
• Service-layer API approach

In the context of this post when the word ‘model’ is mentioned this is primarily referring to YANG which stands for Yet Another Next Generation. YANG is a data modelling language developed by the IETF and published under RFC6020. YANG is intended to model configuration and state data of a network device.

The data model specifies the syntax and semantics behind the data is being modelled. An example of what this model looks like is below.

     container interfaces {
         list ifEntry {
             key "ifIndex";

             leaf ifIndex {
                 type uint32;
             }
             leaf ifDescr {
                 type string;
             }
             leaf ifType {
                 type iana:IfType;
             }
             leaf ifMtu {
                 type int32;
             }
         }
     }

Types of Models

There are different types of YANG based models out there in the industry.

• Native models

  • These are vendor specific models that expose specific data that is unique to the vendor device.

• OpenConfig

  • OpenConfig models are driven by a working group of network operators with the aim of having models that are vendor neutral. The idea is that irrespective of what vendor is of the device is there will be a consistent way of configuring and gathering the state from the network devices.

• IETF

  • IEFT models are similar to OpenConfig models but the initiative is driven by the IETF working groups.

Model-driven APIs

Model driven APIs allows the network operator to build applications that are part of their build and provisioning systems to provision new services or make changes to existing services. For example a network operator can use the YANG Development Kit (ydk.io) to write applications that interact with the network devices. These applications can be integrated to provisioning and build systems of a network operator, thus reducing potential error-prone CLI configuration changes to enable new services.

Whilst this capability is powerful and it does rely on the network operator building applications to enable this network programmability.

There are not many off the shelf network automation platforms that are leveraging the model driven programmability, but hopefully as the technology begins to mature and standardise there is possibility to see a wide adoption model driven automation system.

One of the interesting things I gathered from watching the video is the difference between standard APIs and model driven APIs. Model driven APIs not only generate the actual APIs but they also generate the associated documentation and bindings for different languages (Python, Go etc).

Service-Layer APIs

Unlike the model driven approach service-layer APIs will allow you to interact with lower layer of the device in order to achieve higher performance and closer control of the device