I have had the opportunity over the last couple of weeks to deliver several SDN presentations to different audiences. As I prepared for the presentation I kept coming back to one truth – the network has always been software defined. What changed is that certain vendors decided to take that software and put a configuration interface on top of it that gave you limited access to the functions and capabilities of the devices. In other words you could say that networking has predominantly been CLI defined or vendor defined based upon the features and functions that are exposed to the customer.
As I thought back to my career, the majority being a network engineer, I was struck by this construct. When I was doing development every new problem could generally be satisfied by code…software…back then in an editor and compiler. So why shouldn’t I be able to solve my networking problems the same way? I understand that there are standards and protocols that help protect us from bad code by an end-user (because application developers always write perfect code…right?). However if I know how I want to manipulate the flow or control plane – shouldn’t I be able to do it given the risks? The answer previously has been “NO” – but that is changing. With the advent of EOS and extensibility the ability to manipulate SysDB and the control plane in general has opened the possibilities. I understand that other companies may be running to the “bolt-on” SDN approach where they build APIs that will interface with the hardware, but these will ultimately be flawed unless you truly have an architected operating system that interfaces in an OPEN way with the underlying hardware and software.
So I am not an SDN purist that thinks that Openflow=SDN. In fact I am much more in the camp that if you have a highly programmable platform the agent that you use to push control plane information to the hardware doesn’t matter. You could use Openflow, Closed Flow, Darrin Fl0w – it doesn’t matter. What does matter is that you can translate the flow or forwarding entries into information that the hardware can then populate its various elements to switch the packet efficiently through the device.
In short – I came back to the networking industry to combine all the great things that I had learned in the application world over the last 5 years. The intersection of SDN or Programmability with networking provides for endless opportunities as to where we can take application control of the environment. You see somewhere networking lost its way and became CLI or Vendor defined networking…not any more. The new revolution is to open this programmability for those that want it through the use of OPEN APIs and interfaces. Now I can have a truly business defined network or customer defined network…all due to enabling the programmatic inclusion of the underlying hardware and software.
That’s all for now – off to Cleveland for two more fun days of customer meetings!