When it comes to the management & configuration of network devices, the traditional approach has been to rely on the CLI. But that’s not a very scalable approach. Today, a complex network environment can have thousands of devices with even higher number of critical applications dependent on them. The requirement to have a stable solution that is scalable, reliable, secure and has a modern programming (NETCONF/RESTCONF/YANG) based approach to network management has been there for quite a long time. In fact, SNMP was once thought of as a potential solution to handle the requirements listed earlier. But, SNMP had its own problems vis-a-vis security and lack of writable MIBs. That’s why it remained limited to just the monitoring side of the operations and was not seriously considered as a contender for the “writable” part of the solution. This void which SNMP couldn’t fill was eventually filled by Model Driven Programmability (MDP).

This series on Network Management is going to be quite different from the previous one in which we had explored different ways to automate network management through Ansible. If you haven’t checked it out yet, then I’d highly suggest you do. It’s a three part series that you can access here – Part 1 , Part 2, Part 3.

What is Model Driven Programmability (MDP) ?

MDP relies on the usage of data models to represent network elements. According to Wikipedia,

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.

Wikipedia

In the context of Computer Networks, Data models provide a structured base that can be utilized to programmatically interact with network devices.

In simple terms, a data model is a well documented and agreed upon method to describe “something”. For example, if one were to describe a network device or create its data model then one could use the following data points to build the model. These data points can be specific to a particular vendor or remain completely vendor agnostic.

• Interface : Type, Speed, State, Number etc.
• Data format : Datagrams, packets etc.
• Supported protocols : BGP, OSPF, MPLS etc.

Using the data model, we can describe an entity in a way which is easy for others to understand. For example, in order to describe a router, we could build a model using data points like the following.

• Interface :
  • Type : GigabitEthernet
  • State : Down
  • Speed : Auto
• Data format : Packets
• Supported protocols : OSPF

Additionally, choosing a standard based model also unshackles us from the obligation of being tied to a specific vendor. In todays age & world, it is imperative that we build solutions that can work across different vendor offerings. I’ve deliberately provided an overtly simplified example so that we are clear about what a model looks like in its most basic form. Having said that, the kind of data models we will be working with during this journey are quite different.

Building Blocks

In the context of computer networks, data models and protocols are often mentioned in the same breath. While data models help us structure the data in a coherent and easy to process manner, we still need to transport that data over the traditional network which means that the data has to adhere to some protocols like NETCONF or RESTCONF and also use different mediums like SSH or HTTP to connect to the device. The following diagram gives a basic overview of different blocks that constitute a Model Driven Programmability based solution. We will explore these in detail in the next few posts.

Types of Network Data Models

There are primarily 3 different offerings of Data Models in the networking context that form the core of Model Driven Programmability approach. All of them are written in the YANG language. You can write your own models or modify the existing ones as well. One also has an option to go for either a standardized model from IETF and Open Config or a vendor specific model depending upon their requirements.

The following link contains a list of different YANG models

https://github.com/YangModels/yang

YANG Language

YANG is a language for describing data models. Although it is capable of describing any data model, it’s root lies in the networking world. Some of its salient features are given below.

• Every data model is a module, a self-contained top-level hierarchy of nodes.
• Data types can be imported from another YANG module or defined within a module.
• It uses containers to group related nodes.
• It uses lists to identify nodes that are stored in sequence.
• A leaf represents each individual attribute of a node.
• Every leaf must have an associated type.

– YANG Nodes

YANG defines four types of Nodes for data modeling. Every YANG data model is basically a collection of the following nodes.

• Container Nodes : A container node is used to group related nodes in a subtree. It has only child nodes and no value and may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists).
• List Nodes : A list defines a sequence of list entries. Each entry is like a structure or a record instance, and is uniquely identified by the values of its key leafs. A list can define multiple keys and may contain any number of child nodes of any type (including leafs, lists, containers etc.).
• Leaf Nodes : A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type, and no child nodes. Every leaf must have an associated type.
• Leaf-list Nodes : A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf.

Learning with an example

If the above definition sounds confusing then don’t worry. We will go through each one of them with the help of a real example. Let’s have a look at a YANG model for Cisco IOS XE 17.6. We are specifically looking at the Cisco-IOS-XE-voice-oper.yang model. This model can be used to capture live operational data on Voice traffic.

I’ve copied a snippet of the aforementioned YANG model here for explanation purposes. You can check out the complete model here. Let’s correlate the actual data with the definition given above.

• Container : The section highlighted in this color represents a Container. As per the definition, a Container is a collection of related nodes and it can contain child nodes in the form of leafs, lists or even other containers within it. In the example below, We have a container called “voice-oper-data” and it has 2 lists contained within it.
• List : The section highlighted in this color represents a List. As per the definition, a List is like a record and is identified by its unique Key leaf. In the example below, we have 2 lists – “dspfarm-dsp” and “sccp-connection”. Both of them have their own unique “Key” leaf values. DSPFARM List has a key leaf value of “bridge-id” and SCCP-CONNECTION List has a key leaf value of “conn-id”.
• Leaf : The section highlighted in this color represents a Leaf. As per the definition, a Leaf can contain only simple data like an integer or string. It doesn’t have child nodes. In the example below, we have 5 Leaf nodes and each of them can have a value of one particular type. The first Leaf “conn-id” can have an “integer/number” value because the data type is “uint32”.

container voice-oper-data {
    config false;
    description
      "Voice operational data";
    list dspfarm-dsp {
      key "bridge-id";
      description
        "DSPFARM DSP details";
      uses voice-ios-xe-oper:dspfarm-dsp;
    }
    list sccp-connection {
      key "conn-id";
      description
        "SCCP Connection details";
      uses voice-ios-xe-oper:sccp-connection;
    }
}

grouping sccp-connection {
    description
      "SCCP Connection";
    leaf conn-id {
      type uint32;
      description
        "SCCP connection ID";
    }
    leaf rmt-ipaddr {
      type inet:ip-address;
      description
        "SCCP connection remote IP address";
    }
    leaf rmt-port {
      type uint16;
      description
        "SCCP connection remote port";
    }
    leaf src-port {
      type uint16;
      description
        "SCCP connection source port";
    }
    leaf dtmf-method {
      type voice-ios-xe-oper:dtmf-method-type;
      description
        "SCCP connection DTMF method";
    }
  }

---

I hope this post was successful in clearing out some of the haze that surrounds this concept of model based networking. In the coming posts, we will be exploring this topic in much detail through YANG models and NETCONF/RESTCONF protocols and also go through some practical use cases. So, stay tuned.

Please feel free to provide your feedback/suggestions, if any.

Let’s connect on LinkedIn