Since the establishment of the Open Network Foundation (ONF) in 2011 to the inception of the Software Defined Networking (SDN) vision, a technology concept born in the 90’s, into the Mainstream Market, till this very date, I still find that many of my peers, and until recently myself included, in the Network Industry are still finding it difficult to grasp this now quickly evolving trend. This is quite understandable and for many reasons:
- Varying definitions of SDNs between the ONF and other industry giants that are Slapping the “SDN” Tag on nearly all new products as the new hype.
- The concept of software for many network engineers is completely alien, and if asked, many will say that is why they chose networking over software programming, and to them the dawning of SDN means either Re-skilling or going home.
- The challenge of figuring out how SDN and related architectures, such as Spine and Leaf to handle increasing east-west traffic, would make sense to a specific industry and eventually justifying the need to adopt and invest in such a solution.
In order to clear away some of the mist surrounding SDN; let’s start off with the definition of SDN. The ONF states that SDN is “The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.” (Software-Defined Networking (SDN) Definition, opennetworking.org). In layman’s terms it is taking the brain (Control Plane) out of the body (Switch or Router: forwarding Plane) and connecting a lot these brainless bodies remotely using a higher level of consciousness (OpenFlow) to a Central Brain (Controller), just like the Borg Collective in the movie Star Trek: First Contact. What this means is that a single controller, usually redundant, based on Control Software would influence multiple hardware devices regardless of vendor using a unified Communication Protocol such as OpenFlow to manage Forwarding Tables that steer traffic as per the needs of the Business Applications. This opens up possibilities for Network Automation and Orchestration. For this definition to work all hardware would need to support OpenFlow including Control Software.
A second definition of SDN disregards the separation of control and forwarding and simply focuses on programmability, i.e. configuration, of multiple hardware from a central location using protocols such as NETCONF implemented using modeling languages such as YANG. This would allow Service Provider and Enterprise Network personnel the ability to move towards more of a Service Oriented Approach to network provisioning and management. A first look at this second definition would reveal that different vendors use different command syntaxes to manage and control their hardware thus making it challenging to have one system to configure all. Standards are currently being updated to overcome this.
Yet another definition of SDN focuses on software as the main attribute meaning a network would be completely created in software by virtualizing firewalls, L2 Switches and L3 routers much like visualizing compute resources managed by a centralized virtual controller. This version of SDN is supported by VMware NSX combining both SDN and Network Function Virtualization (NFV) overlaid over almost any existing network hardware that provides a pool of bandwidth for the virtualized environment. If management of physical hardware from the controller is required, the hardware would need to support VXLAN and VMware’s OVSDB protocol (open source and available to most hardware vendors to implement on their devices).
Whichever definition of SDN is adopted, one or a combination of two or more (such as Cisco ACI with OpFlex, that combines Openflow and NETCONF like architectures) there needs to be a unification of effort between Vendors and Manufactures, on one end, to insure adoption of standards and seamless integration, and on the other end, between Service Providers & Enterprises, to highlight the realistic needs of SDN. Otherwise SDN Networks would not deliver on the following Key Aspects:
-
Fast Network Provisioning
-
Centralized Control Across Vendors
-
Quicker Software/Application Deployment
-
Programmable Network Components
After all we can’t all be like Google, building our own network (Hardware & Software) from the ground up.
The feeling of apprehension from many in the Networking Industry towards SDN and this is due to the misconception that it is an all or nothing solution and many would be replaced by programmers if they do not start brushing up on their coding skills.
-
I would say this fear is understandable but misplaced, the term is Software Defined Networking, Networking being a key Part of the solution and this includes, dealing with the first 4 layers of the OSI Stack, the bread and butter of any networking engineer. Yes some scripting is required if you intend to develop the controller software or design custom networking applications, but most SDN suits will be available with a large set of predefined templates covering most of our networking needs. Plus it is never too late to learn an easy to use scripting language such as Python or a modeling language such as Yang.
Last but not least, the belief that the technology is still too immature making it difficult to choose the right SND flavor for the business, coupled with the notion of “I don’t want to be the first to try it”.
-
Also a rational way of thinking when it comes to any new technology, but SDN is not new and there is currently an install base of customers with different flavors of SDN deployed at different phases of the network cycle, be it Planning, Testing or in a Live Environment, with benefits well documented, not to mention the collaboration efforts and investments being deployed by major vendors in order to bring forth SDN. The trick is to figure out the flavor that suits your environment and that is in-line with your business and networking needs. You can start with a small investment by setting up a PoC or lab environment just to get your feet wet and there is lots to learn from industries in the same vertical market who already migrated to SDN. This will greatly ease your way through this transition to SDN, hone your teams skillset and reduce fear of the unknown.
My advice to you is to start the SDN conversation within your environment and between your peers and get your Network Partner/ Vendor involved in your SDN planning as they can be your best ally.
The journey to SDN can be an exciting network transformation, if planned well at the beginning, leading up to a plethora of benefits.
Raed Hmaidan
Senior Solutions Architect
