Efficiency versus Complexity
Throughout history, we've seen many improvements in the efficiency of various systems around us. In general, efficiency improvements are accompanied by increases in complexity. The internal combustion engine is a common example. Early versions were very simple and had low power output. Over time, developments like the four-stroke engine and overhead cam valves increased efficiency, accompanied by an increase in the engine's complexity. Today, we have turbo-charged, fuel-injected internal combustion engines that are very complex systems, relying on computers to control their operation to achieve the highest levels of efficiency.
However, there are also examples where new technology reduces complexity and also provides new levels of efficiency. I maintain that RISC (Reduced Instruction Set Computing) processors are an example. One could also suggest that the Virtual Machine paradigm is another example, since the VM host operating system is not appreciably more complex than a standard operating system of prior generations of computing systems. With VM technology, the client OS can be made more standardized and less complex. Being able to run multiple clients within one host system has revolutionized the computing industry and simplified system administration.
Into which camp will SDN fall? I don't think we can know for sure at this juncture. But here are a few thoughts.
The Current State of Networking
Networks today rely on a complex set of protocols to achieve the desired forwarding behavior. We've moved from simple Distance-Vector protocols to more complex Link-State protocols for routing within organizations. Resilience and the desire to route different types of traffic over separate links has introduced the need for policy routing (e.g., keeping high-bandwidth video off the low-latency interactive data paths). Add to that the Multi-Protocol BGP configuration for implementing Layer 3 VPNs, and we have a pretty complex network configuration.
These configurations can be difficult to troubleshoot and can be fragile. I know of one instance where two L3 VPNs were connected together to provide new video service connectivity to one part of an organization, and the result was that traffic destined for the Internet in parts of the network was directed to the video MCU subnet, which was advertising the default network. The network engineers had been lazy and used a default route in the video L3 VPN. When the video VPN was connected to another VPN, there were now two default routes. One simple network change took out Internet service, including some critical functions, for a substantial part of an organization.
Will SDN allow us to build less fragile networks? Perhaps. But perhaps not. It depends on how we implement and deploy SDN.
Will Efficiency Increase?
We won't know for sure if SDN will result in an increase in efficiency until we have some experience with it and go through some revisions. There will certainly be some false starts, which the naysayers will trumpet. There should also be some benefits, which the proponents will say is justification for the change.
When I look at the complexity of the incumbent, existing suite of protocols, I can't help but think that there must be a better, simpler way to configure, monitor, and control networks. SNMP is about the best we have for network monitoring and it isn't very good for anything beyond basic performance monitoring. For network control, the CLI tends to be the only viable approach, and it has its own set of hurdles that make it unsuitable for the long term. (Note: One could postulate that XML-based configuration control solves this problem. While it helps, I don't think it is the best (i.e. definitive) solution.)
SDN and Greater Complexity
There is certainly a valid argument that SDN is accompanied by significant increases in complexity. A reliable SDN implementation will need multiple controllers running a distributed algorithm to provide redundant control to handle the failure of a single controller. There may also need to be multiple control paths so that a single network failure will not cause a switch (i.e., a network packet forwarding device) to be isolated from all controllers.
Control mechanisms for packet forwarding and communications with each switch will also be implemented. The communications between the control and forwarding planes in existing routers and switches is very high-speed. Attempting to achieve the same level of performance in an SDN implementation's separation of control and forwarding planes seems to beg for more complexity.
In the short term, SDN implementations will need to interface with systems that use the traditional set of complex protocols that we use today: STP, OSPF, EIGRP, BGP, Policy Routing, QoS, etc. Adding SDN to that mix can only result in an increase in complexity.
We've solved similarly difficult distributed computing problems in the past and I'm confident that a number of ideas will be implemented that will address most, if not all, of the performance concerns that exist today. Still, there is the possibility that greater complexity will be the result. We will only know after a few iterations of SDN development over the coming 3-5 years.
Is SDN Revolutionary?
The other argument is that SDN is revolutionary and that it will greatly simplify the complexity of network configuration and control that exists today. I find this argument compelling. The myriad protocols that are required in a modern network look to me like covering a severe wound with a multitude of small bandages. Every time we face a new operational challenge, we invent a new protocol to address it and figure out how to make this new protocol work with all the other protocols as best we can. This method of operation isn't sustainable.
It makes sense to me that QoS, Call Admission Control, Policy Routing, and L2/3 VPNs are all closely related and should be solved with a common control mechanism. What is important is to determine what the control mechanism should be. Will it be worse than what we have now, or will it be revolutionary and allow us to greatly simplify networking? We will probably have to live through a few versions that are worse than what we have now. Hopefully, we won't throw out SDN just because a few early implementations are poorly conceived.
My Thoughts
There is enough competition in the industry that I doubt that SDN will be rejected because of a few poor implementations in the early days. But these early days are pioneering days and we should expect to encounter rough times before things get better. Complexity will increase, at least in the near term. Efficiency increases may not be achieved until later versions of SDN appear. We will likely find that the internals of SDN are more complex, just like the computer-controlled fuel injected engine, but that the result is greater efficiency and ease of operation. (Think about it; when was the last time you heard a conversation about an engine pinging, backfiring, or hesitating when accelerating from a stop? These were common problems of carburetor-based engines.)
Networks will continue to be complex systems and will need very smart people to understand how they work and to be able to troubleshoot them when they don't work as desired. [Note: This last statement is directed to those who are concerned that SDN will put them out of a job.]
I am hopeful that the new abstractions that Scott Schenker mentioned in his talk "A Gentle Introduction to SDN" will result in efficiency improvements beyond the cost of the complexity of SDN.
