The industry has begun to converge on the main characteristics that make up a software defined networking (SDN) architecture, as you can see in blog posts like those on the SDxCentral "must read list" covering early 2013. In one of my previous blogs, I highlighted those characteristics, and there are various other articles out there, like the one on Network Computing, that give a decent explanation, whereby one can still argue about the specifics of the architecture.

When I look at the characteristics and the promise of SDN, I see:

• Centralized management and control
• Network programmability
• Vendor interoperability and integration capabilities

The centralized management and control can be implemented via a centralized controller or any other central control plane component in a distributed architecture that enables the programmatic access into the network infrastructure from a single point. For programming and integration, you obviously need an open and accessible API. (Whereby the world converges on XML somehow. RESTFul or SOAP doesn't really matter as compared to CLI and SNMP; this is many times more accessible for an application programmer)

And you probably need more: network abstraction. The level of abstraction depends on what you are trying to achieve. If you just want to expose all of the capabilities of your network devices and your network topology to a networking geek (a.k.a. network administrator), you might not need abstraction at all, but where is the benefit? And this is probably what you experienced when you took a look at the OpenFlow controller approach: You really need to know a lot about networking to make the right decisions. And who outside of the network domain really can claim this?

On the other hand, SDN for me is also about an organizational change and different processes -- you do delegate control to lines of business within your enterprise that are outside of the network domain, eventually even outside of IT. That creates real agility. The knowledge about networking in those groups is probably close to zero, and they should not need to care about it -- it just should work. But even if you stay inside IT and you let the system administrator deploy applications and workloads in a automated and orchestrated fashion on the network -- the typical SDN use case in the data center -- the question still comes up: What does the system administrator need and want to know about the network? And how much does the application need to know about the network that it gets deployed on? "Nothing" is not a good answer, as you will end up with the challenges that overlay technologies have today, and "everything" is not either, as you did not gain anything compared to the old operational model.

The usability of a SDN solution, the adoption in the enterprise, and also the success of those vendors who provide SDN solutions to the enterprise will depend on how good they find that balance. The race is on.

Some food for thought. Another blog of mine will probably focus on another question that comes up in the case of delegation of control: resource brokering. If every application can manipulate the network configuration and request resources, how/who/where do you resolve conflicts? Don't we always want the best service, the fastest link, the lowest latency?