I recently participated in an exercise with a group of experts within an open source organization to describe the relative positioning of various open source software-defined network (SDN) controller projects. The particular angle sought was a sort of "A is good for X and B is good for Y" kind of differentiation and clarity. The expectation was that there would be a simple, differentiating theme among such projects and that our “expert” group would quickly and sharply describe such a theme (e.g. This one is better for service providers and this one is better for enterprise). Surprisingly, we couldn't even begin to provide a responsible answer because of the fact that nobody, especially experts, has any idea what SDN is anymore.

I first heard the term software-defined networking in 2009 in the context of the clean slate project and OpenFlow. At that time it meant something very specific, and was related to a new approach to building a control plane. It generated a lot of hype and media attention and became a hot topic among innovation pundits. As a result, everyone began to say their work was SDN and any specific meaning was washed away. It has sort of evolved from what the pioneers meant, to the dictionary definition of the three words. If it has software, and is related to networking, then it is SDN. Based on this expanded definition, virtually everything we have ever done in networking from the beginning is SDN. I'm pretty sure this is not helpful to networking buyers  from a marketing and terminology perspective, but it has also lead to some technical confusion as well.

Marketing folks at certain network vendors have anointed model-based development as the silver bullet to enabling interoperability in modular software. The greatest promise of the model driven approach to building SDN controllers is that it will enable a common model to represent diverse implementations of the many southbound protocols (interface protocols between controller and forwarding devices) being drawn at the bottom of SDN controllers block diagrams. This would allow us to move away from the current development model where you write code on the north side of the controller once per southbound interface. Diverse support for today's once-per-southbound requirement could one day demand specific expertise in tens of dissimilar interface models. The benefits of model-based diminish as the number of models approaches infinity. A common southbound model would dramatically increase innovation, re-use, inter-operability, and overall productivity.

But this is where the scope creeps in because defining SDN is hard to accommodate.

If you look at a picture of a modern SDN controller platform, (say ODL or ONOS from the open source world) you see a variety of acronyms for the things on the south side. Let me pick three that commonly appear in block diagrams: OpenFlow, NetConf, and BGP. The difficulty in finding a common model to represent these three is that they have NOTHING IN COMMON. OpenFlow is a match/action model based on pushing such flow rules from a centralized controller. NetConf is a management plane configuration protocol for configuring (primarily) autonomous systems (e.g. old school, pre-SDN L2/3 switch router boxes). BGP is a route discovery and distribution protocol for an AS routing control plane. It is one thing to say these are all SDN under some broad definition but quite another to pretend that they somehow serve the same purpose for the same architecture and use cases. They don't.

However, if we were to recognize that there are some distinct categories or segments among network systems that have software, we could begin to have meaningful conversations about common models and reducing the cost of development on a controller's north side. We could also help marketers and operators figure out when they are comparing apples to xylophones (comparing apples to oranges is currently beyond the state-of-the-art)

The three examples chosen may represent the three biggest and most obvious categories. Netconf as a means for automating legacy systems at a global scale is a valid use case and getting lots of attention. More of a hybrid solution is represented by external path computation engines and routing algorithms supporting multiple RIBs deployed in autonomous systems solutions. Finally, various match/action schemes can likely be generalized to a common model for some greater re-use and efficiency in that particular class of SDN solutions.

It is equally valid for intent pushed in the Northbound interface of an SDN controller to be implemented using any of these three models or a combination. However, if some segmentation within SDN allows us to come up with a relatively small set of common models we end up better off than with the one-model-per-protocol approach available today. Extensible is good, but not all extensions are good, and too many are clearly a problem.

I would like to contribute to work in the community to find both technical and marketing solutions based on recognizing that within the many things we now call SDN, there are some segments of related requirements and technology. If we can identify broad segments of related things within the totality of SDN, it can enable more meaningful conversations about solving problems and demonstrating the value of innovation. Furthermore, it may allow us to find common abstractions for modeling the components in such systems leading to better and more efficient platforms and solutions

It would be great to see analyst reports and controller evaluations describe which SDN segment they are analyzing and also to see comparisons of like things that are meaningful.

There are others far better qualified to lead a revolution in how we talk about SDN, but it's clear that something needs to change.

Earlier this month, Russ White discussed this subject and described some classes of things being called SDN including:

• An overlay with software based switching controlled by a centralized controller
• An entire data center with hardware controlled by a centralized controller
• Groups of physical devices federated into a single device at a controller
• Centralized topology gathering and distribution combined with distributed best path calculation
• Distributed route calculation with policy provided by a centralized controller

Following are some of my “off the cuff” ideas about clearly differentiated segments that I've seen called SDN.

• Using tools like ansible, chef, puppet, tail-F, and their descendants to automate aspects of router configuration
• Pushing routes to routers from a route server or PCE
• Match/Action rules pushed to tables in forwarding devices
• DevOps (whatever that is)
• Building a fabric to replace the AS (route discovery-based control plane with something based on a central database).
• Disaggregation of switch software personality from hardware platform

I have my hands pretty full with the intent work I do on the Northside but would really like to see our industry finding commonality on the southbound side by segmenting the many things we currently describe as SDN based.