SDN, NFV and Skill Development for Network Engineers

I came to Cisco Brussels 14 years ago to take my first CCIE lab. I didn’t pass that time. I went to Tokyo a month later and got my number there. Several years later I kept coming back to Brussels to pass my two other CCIEs.

Many people say there is no value anymore in taking CCIE these days. With SDN and NFV, everything will be done "auto-magically". We don’t even need network engineers anymore! Yeah, right. Last week I went back in Brussels to work on Network Control System, multi-vendor network device management tool from Tail-F that was acquired by Cisco June last year. NCS is the cornerstone of Cisco Network Service Orchestration framework for Cisco SDN and NFV solution offering. And I’m here to tell you that the world still need lots of network engineers, and CCIEs, or those who have CCIE-level skill set.

But first, let me talk more about NCS, a service orchestration for real-time service provisioning across multivendor networks.

Network devices were, and are still, configured using CLI. Then SNMP was created to help. Soon, we realized SNMP is great to monitor the network but it fails to become configuration management, as stated by RFC 3535. So more than 70% networks today are still managed by CLI. Arista Networks CEO Jayshree Ullal once said “it’s the way real men build real networks today.” And when we need automation, we create script to send sequential CLI command to devices.

When we use CLI, or Web interface, or SNMP, or send the command over REST API or Netconf to the device directly, this is called Stove Pipe approach. Tail-F NCS puts itself in the middle of the communication between all those protocols with the network devices or Managed Objects (MO). Think its function as mechanism to “normalize” devices configuration into one standard data model then push that configuration into devices using one standard protocol. NCS supports multiprotocol and multivendor by design.

NCS uses YANG, a data modeling language that represents data structures in Extensible Markup Language (XML) tree format. The data modeling language can be used to model both configuration data as well as state data of network devices. YANG can be used to define the format of event notifications emitted by network devices and it allows us to define the signature of remote procedure calls that can be invoked on network devices via the Netconf protocol. Network Configuration Protocol (Netconf) provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer. YANG was published by IETF as RFC 6020, and Netconf was published as RFC 4741 and later revised and published as RFC 6241.

In short: The Netconf protocol allows a manager to set configuration, query configuration and state and execute actions on the device (much like SNMP). The YANG models describe everything there is to configure, monitor, admin actions, notifications for each device type and version (much like a MIB).

Many network management tools are misleading since they are actually only device management. What we really need is a service management. When we want to enable service, let’s say MPLS L3VPN, we may have to configure multiple devices. So it’s a network wide transactions based tool that we need. NCS acts as central repository to store network services logically using YANG data model for data structure. The structure represents service instance, and network configuration and state. It then maps between service operation to network configuration changes. NCS has transactional integrity. The service configuration is pushed using Netconf to all relevant network devices as one transaction. So it has to be successful in all, or nothing at all. If one device is failed to accept the configuration change, then all devices must be rolled back to its previous state. And there is no internal order inside a transaction, it is a set of changes, not a sequence. And any parallel transactions do not interfere with each other.

So what’s the relationship between NCS and SDN/NFV?

Cisco has been talking about Evolved Services Platform (ESP), that uses software-defined networking (SDN), Network Functions Virtualization (NFV), Open APIs, and advanced orchestration capabilities to forge a flexible and modular platform. With the Cisco ESP, and the physical and virtual infrastructure service delivery capabilities of the Cisco Evolved Programmable Network (EPN), service providers can quickly deploy new personalized offerings through integrated services modules. Imagine offering prepackaged tiers of enterprise services with default features, security, and service-level agreements (SLAs), that customers can select from an online portal and activate with a click of a mouse.

So the network operator can create a catalog of customized service offers that they make available through the active service catalog. The operator uses the business logic of the network service and resource orchestration modules to start up the virtual machines, activate the Virtualized Network Functions (VNFs), and dynamically create the specific service function chain, which creates appropriate linkages that support the service profile and steer the customer traffic through them. That is the idea behind Virtualized Managed Services solution, Cisco ESP services modules that may be deployed today.

And NCS plays important role as the Orchestration Engine in the solution.

Skill Development for Network Engineers

With the long explanation above, if you are a network engineer, what should you do now? What should you learn? How to develop skills to be able to work with the new networking paradigm like SDN and NFV?

As I wrote in my last blog post, someone needs to translate business requirement into technical requirement. That someone needs to understand business language as well as the technical solutions. Then the same person or someone else needs to create end-to-end architecture just like Virtualized Managed Services. Another person needs to design the service profile and create service catalog. Tool like NCS still requires input from someone to make those services into YANG model. And even if all physical and virtual infrastructure will be provisioned and managed using tool, we still need people who are proficient with network, compute, storage as well as various virtualized network functions. There are still many network protocols today such as OSPF, ISIS, BGP, overlay like MPLS or IPSec tunnel, that will continue to be used in the solution. So you still need to know networking technology in details. We still need many network engineers.

Any SDN/NFV solution and implementation will have so many components connected to each other using different types of API. There are lots of moving parts. Lots of complexity. We still need CCIEs, or rather those who possess CCIE skill set to handle the complexity. Then they have to adapt and to learn something beyond networking.

We need those who want to go up, to get closer to the business, and those who want to have the wide and broad knowledge beyond networking: hypervisor, OS, programming logic, scripting, API and so on. Dave Tucker suggested the transition from NetOps to DevOps, and he would predict that the Network DevOps engineer will need:

• Strong Networking Skills
• Knowledge of Linux System Administration
• Experience with Puppet/Chef/Ansible/CFEngine/SaltStack would be desirable
• Scripting skills in Bash, PHP, Ruby or Python
• Ability to work under Source Control (git)
• Experience in consuming (REST) APIs
• Experience with OpenStack and OpenStack Networking
• Appreciation of Software Defined Networking (SDN)
• Knowledge of Agile Methodologies
• Knowledge of Test-Driven Development
• Ability to write Unit and Integration Tests

With so many things to learn, where and how to start?

Introduce tree-traversal. It is a form of graph traversal and refers to the process of visiting each node in a tree data structure in a systematic way. Basically in the example above there are two ways to traverse a tree: Depth-first, go down first e.g. first child, then grandchild before second child, and Breadth-first, go across first e.g. first child, then second child before grandchildren.

Let’s look at my tree-traversal above. I used Depth-first approach. So I spent my time to learn Networking technology first, in Routing & Switching, then Service Provider and Security. Then I spent time to learn Compute with various Linux OS distributions. And these days I put my focus on SDN/NFV technology from Cloud, Virtualization and network programmability.

So which way is the best for you? It depends.

You may go with Depth-first like me: learn networking until CCIE level, then go deep with Linux, before moving to scripting, API, orchestration and so on. Or you may go with Breadth-first: learning networking to mid level, then switch to Linux, then try scripting a bit, then get some hands on with OpenStack, then coming back to learn networking in more detail, Linux in more detail, and so on. Both ways have pros and cons.

And you may use certification program to help you to learn. For networking, Cisco certification program is still the gold standard. For linux OS you may go with RedHat or Linux Foundation. Even OpenStack has certification program from company like Mirantis or RedHat.

If you do use certification program to learn, please remember one thing: in learning, process matters. At work, obviously outcome or result matters. But when you learn something, don’t focus on the outcome or to get the certification, but focus on the process to gain the knowledge. So you will always be ready to learn any new skills and technology.

And that, I believe, is the only way to become the next generation network engineers.

So stop reading now. And start planning for your skill development.
Good luck.

“Plans are nothing; planning is everything.”
-- Dwight D. Eisenhower