2012′s dominant networking buzzword has been SDN: software defined networking. Packet Pushers has talked about SDN quite a bit because it represents a re-thinking of the way that the industry has built networks for the last two decades. SDN as a concept is both technically interesting and creatively inspiring, giving many pause for thought and cogitation along the lines of “what if.”
However, far more network engineers are sick of hearing about SDN than are interested in it. Rather than thinking “what if”, they are thinking “who cares?” The “who cares about SDN” attitude has been related to this Packet Pusher from all aspects of our social media community. Tweets, e-mails, blog comments, IRC chatter, and forum posts have seen a recurring theme of “shut up about SDN already and let’s talk about something that really matters.” In fairness, I empathize. I feel invective thoughts about SDN rising up in my own mind from time to time, and I’m a believer in the SDN idea.
Why are network engineers sick of hearing about SDN?
Engineers have a number of problems running their networks today. From a practical standpoint, these problems are not usually architectural ones. Which isn’t to say that there aren’t architectural challenges today – certainly there are, not the least of which is how to lessen spanning-tree’s impact on data center design. But in a broad sense, the model of fat-tree networks with predictable oversubscription still works in many scenarios, and the majority of issues with this approach can be ameliorated with MLAG.
Instead, I argue that the problem most engineers have is one of efficiency. Managing sprawling network topologies, a problem even in small-to-mid enterprises, is every engineer’s pain in the backside. This is true in at least two significant ways.
- One is in provisioning, or should I say “orchestration”. Even simple switchport provisioning is a tedious, error-prone process for most networks that can be difficult to delegate. Move up in complexity to something like HTTP server load-balancing with SSL offload, and the tedium and error-proneness only increases.
- The other pain point is in troubleshooting, where discovering and resolving a failure in an end-to-end path is time-consuming, requiring intimate knowledge of the environment. Security policies, routing protocols, private vs. public transport, disaster recovery, and interaction with third parties make for any number of details that must be well-understood during a network failure to restore service.
If SDN solutions available today were addresses these issues – provisioning/orchestration or reducing the time it takes to resolve a failure – network engineers of the world might be more keen to investigate. Instead, SDN for the most part represents potential that network engineers must leverage by themselves. Network engineers don’t have time for this. Network engineers are insanely busy individuals, usually with too many projects to manage and not enough staff to work with them. There is a dearth of network engineering talent in many job markets, certainly in the United States. Network engineers are leaned upon heavily to execute projects for purposes of cost reduction or business enablement, frequently in compressed timelines that don’t allow for taking any approach other than the trusted, proven one.
Vendors offering APIs to network engineers to help them solve their issues is akin to a an auto manufacturer handing a pile of metal and a welding torch to someone who needs a new car. While there are some shops that will learn how to weld, most would rather keep fixing the old car. Vendors need to deliver a new car, or SDN will remain the corner-case problem-solver it is today, confined to academia and the Googles of the world that can afford to build their own in-house auto-manufacturing plant.
Another adoption challenge SDN faces is that of mixed vendor approaches. There is no standard way to deliver a software defined network, and at this point there is little in the way of standard network abstraction models that are going to get us there. Yes, there is NETCONF. And yes, IRS (recently renamed I2RS) is in the early draft stages. But is the networking industry anywhere near being able to cobble together a vendor-agnostic network and manage it in a predictable, software defined way? Goodness, no. Vendors major on their differentiators; they don’t minor on them. And at this stage of the SDN game, most vendors are telling the market what they want the market to need, using specially crafted marketing messages that play to their own strengths. The fact that the SDN messages have been mixed hasn’t been lost on network engineers, and so the response has been variations on a theme of “meh“.
What’s a vendor to do?
The vendors that will lead the SDN revolution are the ones that deliver an integrated set of tools that make it easy for a network engineer to manage his network. The software defined network of the future won’t merely be vendor operating systems with APIs. Instead, it will be a mix of hardware, software, and controllers that make it possible to eliminate routine tasks through orchestration, deploy forwarding and security policies globally, and pinpoint problems quickly. Will those functions leverage APIs? Very probably, but a network engineer won’t be forced to sort that out.
I’ve heard vendors say repeatedly that they don’t know what a network operator is going to need to do, and so they’d rather offer tools than solutions. Some vendors believe the best approach is to hand off APIs, under the assumption that the network engineers know what they need and (apparently) have time to learn a programming language. The reality is that network engineers don’t have that kind of time, other than perhaps a quick script here or there.
For the majority of networks, it’s incumbent upon the vendor to put together the holistic network management tools that will allow the network engineer to manage the network, and not individual devices. Demonstrate that solution, and more network engineers will be interested. Why? Because that approach might actually solve problems, and not simply give network engineers more work to do.
About Ethan Banks
