Software Defined Networking is real,everyone talks about SDN, network engineers worry about their jobs and ask below questions. Hundreds if not thousands of articles, a lot of books have been written on SDN.
SDN is not a new idea or concept and we see this ping pong game many times but this time it is marketed very well in my opinion thats why everyone talks about SDN and that is real, inescapable.
Yesterday we were talking with Russ White on webex for one of my project which I will announce very soon and at some point we started to talk about SDN.
What should Network Engineers will do in the new SDN world?
Which type of skills Network Operators, Admins even Network designer should have to survive in SDN era?
Will SDN kill the network engineering?
First of all, everyone should understand that eventually all the protocols, technologies and new ideas has to try to help one important business case at the end , ” Cost “.
SDN is not an exception! It promises to reduce the complexity by centralising the policy with control and data plane separation. It promises many other things as well but in this post I will not go through what is SDN and what should be the best SDN approach.
Network Engineers definitely will need to have new skills. Probably the most important one is the programming skill.
You should consider to learn Python, Yang , Netconf , C++ and so on. You may not be an expert for all of them but you need to understand them. It was interesting though that Russ is thinking that within 5 years Network Engineering will completely change and maybe Network engineering might be a part of Software Engineering.
Network Engineers should understand Software and programming definitely !
I think slightly different on this, maybe within 5 years it might be the case for the Large scale networks, or just some places in the networks of the large companies such as Datacenter or WAN but the time will take longer for the smaller companies.
SDN will not definitely kill the network engineering. Why ?
First implementation , attempt for the SDN uses Openflow.With OpenFlow you separate Policy , as well as reachability information, and the devices are considered as dump. Networking is considered as plumb, and the network engineers are plumbers.
Sorry guys, you are not the smartest people ..
A lot of applications/functions in today networks perform much better in a distributed manner.
For example , if you want to have Fast reroute in your core network, distributed approach always better. Because you need to detect the failure, inform the central node, then calculate ( or maybe pre-calculated ) the new loop free path and program to the networking nodes instead of having local protection.
But some functions definitely work in a centralised fashion. Probably the obvious example is Traffic Engineering. Doesn’t matter you do it with Layer 2 traffic engineering ( PBB-TE for example ), MPLS Traffic Engineering or Segment Routing , having a centralised nodes which receives all the topology information and keeping the updated states provide excellent visibility compare to the distributed traffic engineering.
As you can understand from the two examples above, not all functions should be centralized thus network engineers will be required to perform fast reroute , capacity planning elements, maybe BGP-LS , PCEP, IGP, MPLS and many other advanced network engineering tools.
Not everyone is a senior , not everyone knows these principles. So ;
You may not be dealing with these technologies or advanced networking works in your organization, then you may be asked to learn the programming tools to troubleshoot, operate and maintain the software part of the network.
SDN will help for some functions in the networks to perform better and new protocols will emerge or existing protocols will be extended ( BGP can carry even your home from one location to another ) thus network engineers will need to learn new protocols, technologies.
The SDN controllers, APIs, new protocols will require software knowledge , thats why we suggest you to consider to have basic understanding for now at least.