What’s NEW in NETWORK PROGRAMMABILITY Section | CCIE Evolving Technologies V1.1 Blueprint

Back to Posts
CCIE Evolving Technologies V1.1 Blueprint network programmability and automation

Share this post

What’s NEW in NETWORK PROGRAMMABILITY Section | CCIE Evolving Technologies V1.1 Blueprint

In this article, you will learn about changes that are coming into Evolving Technologies V1.1. If you recall, Cisco published an update to Evolving Technologies section dubbed as V1.1 which will go into effect starting Aug 30 2018. For the uninitiated, Evolving Technologies consists of three sub-sections or topics, i.e.

  1. Cloud (cloud deployment and service models etc.)
  2. Network Programmability (SDN/NFV, Infrastructure as Code which includes CICD and DevOps tools etc.). BTW, you can also refer to Full Stack Networker, if you prefer to deep dive into Infrastructure as Code.
  3. Internet of Things (or IoT)

Now, we’ve already covered Cloud topic, so let’s get right into network programmability.

Unfortunately, Evolving Technologies V1.0 did nothing more than hand waving for network programmability section. Now, that changes with V1.1 as Cisco seemed to have made it much more specific and pretty much all about the real network programmability and not just SDN.


Topics Added to V1.1

  • data modeling languages (YANG etc.)
  • data encoding formats (JSON which is pronounced as Jay-sun and XML)
  • configuration management protocols (NETCONF, RESTCONF, REST, gRPC)
  • configuration management tools (Git, SVN etc.)
  • policy-driven configuration (Cisco APIC etc.)

Topics Removed in V1.1

  • Service function chaining
  • Performance, availability, and scaling considerations (around virtualization and automation)

IMO, Cisco deserves some kudos for spelling out network programmability by being more specific, i.e. configuration management and DevOps and Software Configuration Management (or SCM) tools such as Git and SVN. I wish they had also added CICD and DevOps pipeline as well to the list, but oh well, perhaps we shall see that in V1.2.

Now, let me breakdown each of the newly added topics.

SNMP has been around for over 30 years. Over this time, it has been the de-facto way to monitor networks. It worked great when networks were small and polling a device every 15-30 minutes met operational requirements. SNMP MIBs are a type of data model defining a collection of information that is organized in a hierarchical format that is used along with SNMP. Anyhow, SNMP did work great for monitoring devices every few minutes, but it never caught on for configuration management purposes due to custom or proprietary MIBs.

In addition to SNMP, there has always been the network command line interface or CLI. Access to the CLI happens via console, Telnet, or SSH, and it has been the de-facto way of managing configuration of networking devices for the past 20+ years. If you tally up the way devices have been managed for 20 years, you can see that there has been no good way to handle machine to machine mechanism i.e. using software to configure network devices.

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (or NETCONF), NETCONF remote procedure calls, and NETCONF notifications.YANG is used to model the operations and content layers of NETCONF. YANG along with NETCONF allows you to move away from SNMP and CLI, and to programmatic network management. YANG can also use RESTCONF as a configuration management protocol.

RESTCONF is nothing but an addition of REST API, which is very popular, to NETCONF. YANG models are used as when you use RESTCONF, and thus the URLs, HTTP verbs, and Request bodies are automatically derived from the associated YANG model.

There are two main data encoding formats that are commonly used in APIs. JavaScript Object Notation (or JSON) and XML are well known data encoding formats in the web programming world. JSON is both human and machine readable encoding format, whereas XML is not so much. Visually, XML formatting is similar to HTML

gRPC is a modern API originally developed by Google but eventually contributed into open source much like what happened with Kubernetes. Cisco includes support for gRPC on IOS-XR devices running IOS XR v6.1 or later.

Network Programmability and Configuration Stack

In a policy-driven configuration mode, policy describes the desired network state in a declarative way, abstracted from the actions that lead to that state. This is in sharp contrast to OpenFlow based SDN model, where controller directly controls forwarding decision-making by way of flow entries in each device within the given topology.

Configuration management is about automating the provisioning and deployment of applications and infrastructure. It leverages some of the following software development practices for deployments.

  • Version control
  • Design patterns
  • Testing

Configuration management tools include Puppet, Chef and Ansible and they are well known in the DevOps circles. Version control systems enable efficient collaboration for developer contributing to a software project.

Git is a distributed version control software that keeps track of every modification to the code. If a mistake is made, developers can look back and compare earlier versions of code to help fix the mistake minimizing disruption to all team members. If you want to see a real life Git and CICD example, check out this network programmability and automation example.

When will CCIEin8Weeks release new course material?

We already did! All of our CCIE study guides and practice quizzes now include Evolving Technologies V1.1 material.

Please feel free to post your comments and questions, I will be responding to them over the next few days and weeks.

We hate spam as much as you do.

Leave a Reply

Back to Posts
Did you know
Evolving Technologies V1.1 is now part of all CCIE/CCDE Written exams.
All of our study material is already updated with V1.1 material!
We hate spam as much as you do.