What is Software Defined Networking (SDN)?
What is Software Defined Networking (SDN)?
SDN is by far the most misunderstood term in networking. Many companies think opening up “C” API to others to program network elements by themselves is SDN. Others think any automation is SDN.
“Software Defined Networking encompasses moving network equipment from proprietary to standard and separating Control Plane from Data Plane”
Software Defined Networking (SDN) Encompasses:
• Moving network equipment from proprietary to standard Central Processing Unit (CPU) and standard Network Processing Unit (NPU)
• Separating Control Plane from Data Plane
• Making forwarding programmable
One of the first protocols to attempt to separate control and data plane and make forwarding programmable was OpenFlow Data Plane Abstraction (OFDPA).
It defines a “controller” to manage the flows, OpenFlow protocol to exchange messages, and flow tables and groups to manage tables and groups for forwarding traffic.
Forwarding and Control Element Separation (ForCES) and P4Runtime are alternative to OFDPA.
What is “Network Automation” then?
Network automation is not the same as SDN. You can start your automation adventure by automatically installing software on your switches Zero Touch Provisioning (ZTP) and configure them via Ansible, Chef, and Puppet in such a way that none of your switches has to be manually configured. This is possible with many of your existing routers and switches today.
If your network needs large number of devices to be modified regularly, this automation would reduce errors and increase efficiency.
What is the difference between Ansible, Chef, and Puppet?
They are all server-based tools to help you automate repeated tasks. Major difference that I would highlight is that Ansible does not need an agent on your network equipment. It connects and communicates with your switch via SSH. Chef and Puppet need a small agent to run on you network equipment
For more comparison details see:
What are open disaggregated network, White-box, and Gray Box?
In today’s market, you have to buy aggregated solutions. That means purpose-built switches, routers, and software that control them are from the same company—such as Cisco, Juniper, Arista, and Huawei.
The problem with this approach is that you are at the mercy of the supplier. They dictate how you run and manage your network. If you need a particular feature, even if it is very simple flow manipulation, you have to:
1. Request a feature
2. If you are large enough they would evaluate your request
3. They would plan it in a release
4. They would code it
5. They would deliver it to you when it fits their timeline
Disaggregated network solutions, on the other hand, stands for separating network equipment from networking software. Once you decide on buying disaggregated solutions, you have a choice of white-box, or gray-box for your hardware.
White-box network equipment contains a CPU, NPU and some basic boot software, such as Open Network Install Environment (ONIE).
Gray-Boxesare similar to white-box, but they come from the same company that supplies you with network software.
Imagine Microsoft selling you windows software on a Microsoft laptop or desktop. This would be your gray-box.
How does ONF and e-CORD fit into all of this?
Open Networking Foundation (ONF) is attempting to put together SDN into an easy to deploy package. Community has created ONOS controller that takes over control plane and flow programing. It communicates via OpenFlow or P4Runtime to the white-box switch to program the flows.
ONF have also come up with the concept of Central Office Re-Architected as a Datacenter (CORD). A subset of this effort is Enterprise CORD or e-CORD for short.
BOM list for eCORD can be found at:
For more details on e-CORD see:
How mature is scalable, programmable networks today?
The latest e-CORD release is usable and testable and a number of organizations have started proof of concept (POC) with it.
What are ROIs from SDN and automation for enterprise?
The best Return On Investment (ROI) that I have seen is from: SDX Central
NOTE: These investments are over time. To realize these ROIs, initial investments are needed to move to automation and SDN.
Which Enterprises would benefit from SDN?
Large enterprises that are able to bring in Software Developers or DevOps engineers on board, who have scripting and programing experience in Python or other languages would benefit from this the most.
Over time, packages and apps would be developed for controllers that reduce this investment. In the end Software Defined Networking is intended to give you flow programing, so investment in IT engineering is needed.
To start please consider:
• Total Cost of Ownership, not just price. Sometimes price does not equate to “cost”. Look at operational impact to your organization, both positive and negative.
• Look at companies that are larger and can provide you support, when things fail. As you all know, even the best networking equipment fail from time to time
• Ask about replacement policies and RMA process and technical support
Having that said, phased transformation may be best approach for you to transition, learn and not impact your mission critical operation
All enterprises can benefit from automation today. Start by building Zero Touch Provisioning (ZTP) mechanism and then expand automation to configuration and roll out automation with Ansible, Puppet or Chef. It will reduce user-error in provisioning and configuring network elements.
Move to disaggregated solutions by separating your switch from network operating system. Evaluate products from white-box or gray-box vendors.
Start simple. Start at outer edge of your network. For example if you have remote offices that have broadband access to your network, start with Secure SD-WAN. Then work your way inward. This part of your network is likely simpler and impact smaller subset of your subscribers.
If your network cannot tolerate risk, look at larger vendors who offer great prices, end-to-end support, and disaggregation in a gray box.
You will be surprised by the options you have at much lower cost!
Look at eCORD and learn how controllers can streamline your existing operation. Build yourself a CLOS topology and experiment. Are JSON and programming needed within your company’s tolerance?
You may find that your IDF, BDF are similar to CLOS.