Could Finding the “Right SDN” Help?

Cisco will be reporting its earnings this week, something that for sure everyone in networking and on the Street will be anticipating.  By any measure, Cisco is a giant in the space and most certainly it’s the leader in IP technology, the layer where the Internet and most business networking is done.  To paraphrase Sinatra, “If you can’t make it there, you can’t make it anywhere!”  If margins and sales won’t hold up in IP then there’s little hope of escaping from commoditization.

It’s not like buyers don’t have issues they’d like their vendors to resolve.  Among service providers and enterprises, my surveys have found a surprising level of continuity in terms of expectations.  Operators say that they face significant reductions in revenue per bit and need to reverse this trend or they can’t invest in the network.  Enterprises say that their business case for IT and networking hasn’t been improving and that this forces them to continually “improve” by reducing costs to meet corporate targets.

I think one reason why vendors are a bit deaf to these pleas is that they see the solution lying up in the application or IT processes and not in the network.  Yes, it’s true that you need applications to empower workers and to create new online experiences, but you also need connectivity.  The notion of making the network a better partner with applications has been around a long time, and it’s representing what might be called the “sane approach” to the future of networking.  You can see attempts to reach this partnership goal developing from the application side, in activities like the Quantum virtual network abstraction of OpenStack or the DevOps activities of cloud deployment.  From the network side, the path arguably lies through software-defined networking (SDN).

Most of the focus of SDN discussion has been on high-level SDN services, and this despite the fact that I firmly believe that you can’t software-define a network with a technology that doesn’t touch its nodal behavior.  Nicira and similar above-Level-3 technologies are software-defined endpoints, not software defined networking.  But does this mean that I’m waiting for somebody to define IP networks through SDN principles?  Nope.

As you rise higher in the OSI stack and enter the realm of large numbers of users and network devices, you make the process of creating a service conception around packet forwarding more difficult.  OpenFlow tells a node how to push a packet, and absent a bunch of intelligence on topology, status, and signaling/control with adjacent smart devices, this isn’t going to get you anywhere.  Push OpenFlow and SDN down even one layer (Level 2) and you reduce the scope of the problem because processes there are simpler.  OSI network layers are known by what they expose to their partners above.  That’s obviously a lot more complicated at Level 3.

OpenFlow and SDNs are a movement to turn the network upside down, in that they demand focusing on lower layers to add value by implication rather than on higher layers to add it explicitly.  You can make an SDN “underlayment” that envelopes both Levels 1 and 2 of the stack, and have this new structure present a fail-safe connective mesh that can look to any higher-level device or user however it would be convenient for it to look.  You can then simplify the operation and even the protocols and products at these higher layers because a lot of what they look for, like failures, are either going to be handled below or can’t be handled at all.

Is the problem here one of excessive defense?  Are vendors like political parties—they’d rather face the past than face the truth?  Is the industry just not holding them to a reasonable standard?  Light Reading published a list of SDN startups and I’d be hard-pressed to find any vendor on that list who met that to-me-critical basic SDN requirement of being present IN the network and not just riding on it.  Maybe we’re creating both SDN and political problems from the same behavior—apathy.

 

Leave a Reply