Over the course of the past four months I have been hard at work growing and stabilizing my own business. Doing so allows me to work in areas of technology that I am most passionate about. Right now that is in the field that has been loosely termed “Software Defined Networking”.
I recently pulled out a product requirements document I created with some friends close to a decade ago for some software we were thinking about developing. I vaguely remembered it somehow being related to the current hot trend in SDN. I was excited to think that back in 2005 before I had ever heard anything about SDN, we could have been at the forefront of a revolution! (Yes, I know SDN concepts had been in play since the mid-nineties but buzzword bingo didn’t really start until after Martin Casado’s amazing work in the mid-2000’s)
Unfortunately, after reading through it again I see why we abandoned it. It was too short-sighted and didn’t really explore the possibilities for automating, orchestrating and ultimately controlling networks. We were really only thinking of ways to translate configurations between different vendors equipment in heterogeneous environments. Not really a revolutionary concept.
I realized something was missing from the document. We had defined a fairly static piece of software that would work with libraries of network syntax to take one vendor’s configuration and morph it into another’s version. We even defined how we would configure devices if the original was using vendor proprietary protocols such as Cisco’s EIGRP. We would analyze, in theory, how things were configured and come up with ways to introduce a new device into the mix and configure ways to allow it to communicate with the existing infrastructure (e.g. route redistribution and/or VRFs). It was in that little piece that I remembered what most excited me personally about what we were trying to accomplish. It was building a system intelligent enough to react and respond to how the network was working. It would just take a statically defined configuration file as input and spit out a different static config file. It would look at how the network was working and automatically orchestrate the way the entire network functioned in a centrally controlled manner (See what I did there?).
At least, that was what I wanted to try and accomplish. But pretty much everyone else disagreed with me. A lot of smart people told me it was going to be too hard to do especially with no money. I met with investors who basically told me that unless I had a working product they weren’t interested and without money I couldn’t to quit my day job and but the resources to make a working product. So into the archives of interesting but unsuccessful things it went.
Fast forward to a couple of years ago and the SDN craze has really started to pick up steam. Vendors big and small have all thrown their hats into the ring made all sorts of claims about what SDN is and how their version is best. I started to realize that yes, what we were trying to accomplish would fit into the world of SDN. Realizing that, I started to think about how I could resurrect what I wanted to accomplish. Trying to make something that fit the specific definition of SDN was problematic since there is no one specific definition of SDN. Instead I want to create something that adheres to spirit of software defined networking and its usefulness to network/systems administrators, programmers and ultimately, users.
Since there are so many different definitions of SDN I am going to stick to the general points outlined by the Open Networking Foundation. Improved management, control, automation, flexibility, scalability, end user experience and so on. I am going to not focus as much on the details that seem be up for argument such as how much hardware is required to use software defined networks, how the control plane needs to be separated from the data plane, and so on.
At the end of the day, the networks job is to provide for the transport of information in the most efficient, secure and robust manner possible. A network by itself doesn’t really serve much of a purpose. It’s what rides on it that really matters. This is where I think SDN can really make a difference. It will finally allow networks and applications to work together to ensure that information gets where it needs to go quickly and safely. It works at the enterprise and the provider level.
With all of this in mind I have dusted off some the ideas I had before and have started to work on ways to use software defined networking concepts to allow systems and applications to communicate not just to each other over a network, but to the network itself, and in turn let the network talk back. This sort of collaboration is, in my opinion, at the heart of what SDN should be all about.
