"SDN makes the knowledge of traditional networking is not relevant anymore. We need more people who can write code instead." Wow.
"SDN with Openflow removes all the current routing protocols. So why wasting your time to study CCIE?" Speechless.
Let's start with definition.
According to Wikipedia, SDN is "...an approach to building computer networks that separates and abstracts elements of these systems..." There are two important keywords there: separate, and abstraction. Separate means decouple Control Plane and Data/Forwarding Plane function. If in 'traditional networking' both Contol and Data functions are contained within a single device, SDN makes the separation so the Control plane can be moved to a device or system that is located at the central of the network. More intelligent control function that can see the whole network end-to-end.
And the Control plane can be customized, manipulated, re-programmed and so on, regardless the state of the Data plane. This is the first level of the abstraction.
Why is abstraction important? Because we want to separate the complexity. Think about building multiple layers that separate the function of whole networking components from Data Plane, Control Plane, and even beyond. Imagine if user only needs to deal with a GUI-based tool to manage and operate the network. He doesn't need to know about the complexity of how the GUI-based tool interprets his request and push it to the layer below. Imagine if programmer can build this network management tool without any need of knowledge how her code can connect to the network device to push the instruction. Imagine if researcher can develop new control function and create new rule what to do with the packet at Control Plane, without having to worry about how the device really forwards the packet at Data Plane. You get the idea.
And is Openflow really the Holy Grail for SDN?
Using the same Wikipedia, OpenFlow is "...a communications protocol that gives access to the forwarding plane of a network switch or router over the network..." So it's just the communication protocol between one system, that most likely has the control plane function, with a switch or router over the network.
Hey, I thought we were talking about abstraction, how user can deal with only one layer, programmer deals with another layer, other programer deals with another layer, researcher deals with another layer, and so on. How OpenFlow can help with that?
Exactly.
Because OpenFlow is only one piece of the puzzle.
The above figure shows the big picture of something that we call Full Network Programmability. Beyond SDN. And definitely beyond OpenFlow, since OpenFlow is only one part that connect us to the network devices that do the actual forwarding of the packet. And OpenFlow is not the only protocol to do that.
And is that true we will completely remove the intelligence part from network device? Is that true we can use central Control function to manage those cheap dumb switches that only do the forwarding?
If you believe this separation of Control Plane and Data Plane is the only way. Some of us believe we still need to leave some control plane function in the device, even we have already had more intelligent control function at the central location of the network. A model we call 'Hybrid' SDN.
Why? So this 'distributed' control plane in network device can run basic function that doesn't require consultation to the central control plane. Because today's distributed control plane in network device has reached the stage of "self healing". It means if there is any failure with the link or neighbor device, it can find alternative way automatically. And these days it can find that alternative way in even much faster (Fast Convergence). Or it can pre-compute the alternative way and prepare the forwarding plane before the failure happens (Fast Re-route). Today's network with distributed control plane has become so resilient, closing the milisecond time gap between the start of the failure until the traffic forwarding is normal again.
The distributed control plane model has also reached a very high performance in a very high scale. It has intelligent security function and other features. In fact, it has a very rich feature-set. Those are the results of more than 25 years research by networking industry. And I personally won't believe all will be thrown away overnight.
So preserve what's working, and program the network when required.
That's what some people, including myself, believe.
This means we still need the CCIEs then.
Because they understand how traditional networking technologies work in detail.
But CCIE can't write code! And we need programmers to run the new network!
We need programmer to build network application indeed. But we need CCIEs to handle the complexity in lower layer. To handle how the application can interact with the network devices. To tell the programmer how they can leverage the current networking protocols to achieve the objective.
And what is the objective, by the way?
To solve customer's business problem.
What's the point to have a very sophisticated network infrastructure, with either traditional networking technologies or the new emerging SDN, if it doesn't help the customers with their business?
It's all about solving customer's business problem.
Always has, always will.
The problem can be: how to simplify the operation? That's why we develop tools for orchestration, to manage and monitor the whole systems. The problem can be: how to be more agile, much faster in deploying services? That's why we integrate tools in many layers so user can have a very simple and easy tool to use in upper layer, programmer build the system in another layer, and another programmer use the communication protocol to push the instruction to the devices. The problem can be: how to use the SDN to open up new business opportunities? That's why we look at virtualization to partition the network, so we can offer new business model to customer, and so on.
So someone, with extensive networking knowledge, still needs to talk to customer to understand the problem and figure out the way to solve it. And that has to happen prior to writing the code. So we still need CCIEs to capture customer requirements. We still need CCIEs to tell the customer that the traditional networking technology won't be able to meet the requirements. We still need CCIEs to tell programmer what to build in the first place.
Cisco Learning Network has defined the "workforce of the future" with job roles evolution and certifications, to prepare the engineers who currently work in networking industry to adapt to this new paradigm in networking.
Network Programmability Engineer: The network programmability engineer will be responsible for deploying the network applications into the programmable environment and making them operational. The engineer will receive the network application and the infrastructure design from the network programmability designer to deploy, install, and troubleshoot.
Network Programmability Designer: In an architect role, this individual will collect the customer requirements, be knowledgeable about the applications that leverage the infrastructure, and translate the customer requirements into a recommended open infrastructure. This individual will provide the functional specifications of the network applications to the network programmability developer.
Network Programmability Developer: The network programmability developer will be responsible for developing network applications in the programmable environment such as Cisco Open Network Environment (ONE). This is a new role focused on the development of the network applications layer, which can live in any of the Cisco provided programmable components, and will enable service provider, campus, and data center use cases. This individual is a software programmer able to program in Python, C, or other languages in an open networking environment.
Business Application Developer: This individual develops business applications such as for SAP and Oracle, leveraging the programmability capability of the new open network environment. This individual will also leverage API capabilities in order to collect information from the network.
Prerequisite for Supporting Cisco Network Programmability course (for Engineer)?
CCNP. With hands on Operating System experience, understanding of debug and troubleshooting tools specific to a virtualized, software and programmable environment.
Prerequisite for Developing Cisco Network Programmability course (for Developer)?
CCNA. Obviously with knowledge of Java, Python, C programming language and good understanding of virtualized environment.
Prerequisite for Designing Cisco Network Programmability course (for Designer)?
CCIE, with knowledge of programming environment, and Operating systems.
So CLN say we need CCIEs to become Network Programmability Designer.
And I personally believe the knowledge learned from CCIE/CCDE is crucial to support SDN, especially to become the architect who can translate customer requirements into functional specifications of the network applications to the developer:
CCIE Routing & Switching is the fundamental knowledge.
CCIE Service Provider teaches how to build "self healing" network.
CCIE Data Center becomes more interesting since many SDN use cases are currently focusing on Data Center, especially the Massively Scaled ones.
And CCDE put all the pieces together, making sure we know the reason behind when and why to use the technology. Go beyond the configuration level.
To summarize, we still need CCIE.
But those who have the quality as above.
And the most important: we need CCIEs who can adapt.
So to all CCIEs out there: prepare yourself.
Use Protect, Grow and Transform strategy to develop your skillset.
Protect, by making sure you understand the traditional networking technology in detail. Beyond CLI.
Grow, by learning the end to end solution. To understand the big picture of networking.
Transform, by understanding the application layer. To learn how to write code.
It's almost 4 am here in Dubai. Time to go back to my Python course.
