Working Thoughts on SDN #1

I spend a lot of time talking about, thinking about and writing about SDN.  I would also state that I am in a small group of people who actually in the business of SDN.  I spend most of my time trying to sell SDN solutions.  If you want to purchase one, contact me.  What follows is my observation of how the SDN conversation is evolving in the market and it is an update to the compute conundrum post I wrote after ONS 2012.  I used the phrase “working thoughts” in the title because this post is really a reflection of how I view the SDN conversation in the field and I might have a different view in a few weeks or a few months; that is how dynamic and emergent the conversation is with the market participants.

I recently reviewed a number of IETF documents on SDN from various vendors and thought leaders.  One of the presentations was an expanded version of Urs Hölzle’s ONS 2012 keynote, which was a motivating element of post I referenced above.  As I was reading through the various presentations a number of themes kept emerging which I see and hear dialoging with customers, but are not really part of the ongoing industry and media dialog on SDN.

Managing the network as a system – rather than a collection of individual, distributed boxes.  I think this is where most of the industry wanders off into never-never land.  There is so much conversation around nortbound, southbound, eastbound and westbound APIs that the SDN objective is lost. The objective is to script the network as a system resource based on the needs of the applications.  If you do not see value in that objective, you do not need SDN and should stop reading this post.

Controller architecture is really important – in the discussion of SDN deployments, people sometimes miss the point of a centralized controller.  These people are easily identified because they talk about the 1977 NYC blackout and how a centralized system has a single point of failure or how we need to avoid building SNA networks or how the phone company built their network with Erlang-B.  Let us not confuse what (1) the goals of a controller based network architecture are with (2) the proper architectural implementation of a network controller.  I will forego the architecture implementation discussion for this post and reiterate what the advantages of the centralized controller are and most of this is a repeat of the prior post referenced above:

1. Better efficiency with global network visibility
2. Faster network convergence to target optimum on failure
3. Network efficiency to 100%
4. Deterministic behavior
5. Controller uses modern server hardware and compute to solve big data problems

What is the network architecture that SDN is trying to solve?  From a high level I have heard many times from clients that it is all about OPEX and yes, there is some CAPEX involved in that discussion as well.  The problem with the modern day data center and switched network architecture is that it embraces a well known geometric problem or tax.  To build wider you need to build taller and to build taller you need to build wider.  Cost per bit should go down with scale – but unfortunately in switched network architecture they tend to go up as we have reached the near limits of latency improvements in silicon, switch silicon densities and the steady decline of over-subscription ratios marching their way to 1:1.  A SDN architecture should provide a solution to the geometric problem in several ways:

1. Complexity in compute interactions and any-to-any communication requires more advanced forecasting and control mechanisms – that is why you want to evolve to a controller architecture
2. Lack of control and determinism in distributed protocols necessitates worst case over-provisioning – that is why you want to evolve to a controller architecture
3. Non-standard vendor APIs add complexity – that is why you have a controller that allows for compute resources to script network capacity based on application needs.
4. Existing networks with contemporary switching and routing mechanisms do not allow for the scheduling of the network as a resource with objectives around optimization and compute (i.e. application) needs – that is why you want to evolve to a controller architecture that can change the configuration of the network.

SDN is not new and networks have been software defined for decades.  Unfortunately we are stuck with the term SDN when it really does not describe the evolution that is underway.  Contemporary timeline of SDN initiatives (I read this in a presentation from Google researcher):

1. 1996 Ipsilon GSMP
2. 1998 Cambridge’s The Tempest
3. 2000 IETF FORCES
4. 2004 IETF PCE
5. 2004 Princeton’s Routing Control Platform
6. 2005 4d Initiative
7. 2007 Ethane
8. 2008 Openflow

There is a lot of confusion around what SDN is or is not.  I think we are talking about the evolution away from distributed protocols and fixed network configurations – other people think we are talking about some level of network programmability.  In my view, a software defined network architecture means the allocation of network bandwidth is computed as a system (i.e. pool?) resource by controllers with a broader view of the application needs.  There are many assumptions in that definition, but in a distilled form that is what SDN is.

As always I could be wrong and have no idea what I am writing about. The above points are really my view of how I think the SDN conversation is being defined, constructed and carried on in the market place.  What is real is what people deploy.  If is not deployed – it is not real.  In the end the market will be the final judge.

/wrk

* It is all about the network stupid, because it is all about compute. *

** Comments are always welcome in the comments section or in private. **