If cars were made like routers they’d have two engines, eight wheels, two entirely separate drivetrains, no windows, no steering wheels, no pedals, a command-line interface, and the expensive ones would let you change a tire while driving (via in service software update). Also, not unlike cars today, as long as the syntax is right, they’ll happily let you command them to drive right into a ditch. There has to be a better way to operate the network.
Overcoming inertia
Last week we were meeting with a Western European telco and arguing for a Software-defined Networking (SDN) trial on their transport network. The telco people were skeptical about the benefits of SDN and I struggled to create a clear and compelling argument for the clean-slate approach I was advocating.
They have a LOT of routing protocols in place today – creating an overengineered mess that no one would ever design today by choice. But their network happens to work just fine (for the moment), and like when most people face the prospect of attempting large-scale change of a vast complex system, their natural instinct is to just say, “Ugh, forget it.”
They would rather leverage and evolve existing protocols, and look for a more measured uptake for SDN. But from my point of view, all this current complexity costs money and makes everything cost more and take longer than it needs to, so the faster you get started with SDN and making things simpler, the better off you’ll be.
How do I convince people who make good money now and have years of experience in evolving best practices in owning and operating network equipment understand that they’re doing something wrong and missing a great opportunity to simplify things?
Why make it simpler?
Traditional routers are complicated and difficult to operate. They function autonomously (hence all those aforementioned protocols), and are responsible for all the routing decisions for the information in their “custody.” But their decisions are selfish; they only care about getting their own information to its destination, without considering others. This was fine back when networks were like countryside roads (few lanes, few choices about how to proceed), but today’s operators face soaring capital expenditures and modest revenue-growth prospects, and thus cannot afford for infrastructure to sit idle for long stretches of time, like a countryside road does. So modern networks are more like an urban traffic grid (many lanes, many choices), and we all know what happens when you have busy roads full of selfish decision-makers – traffic jams.
If everyone tries to take the shortest route to a destination, that route ends up actually becoming the longest route because of traffic congestion. All routes would flow better if some drivers would take alternative routes, ones that cover a bit more ground but end up saving time, and for years we’ve bemoaned our SPF algorithms’ inability to find them.
But SDN changes that equation, as decisions are now made by centralized “traffic controllers” and not at the level of the individual cars (routers). Not only does this make for smarter decision-making, it enables the building of simpler cars.
A bigger better picture
Two things make this possible. The first is faster computers. The second is streaming analytics. You can make more sense of more data faster than you ever could before, and usually faster and better than any single router can, because the controller is collecting data from a group of routers and is able to make a more optimal decision about what to forward where and when.
You’ll have something like vehicle telematics for your network. You can aggregate, slice, and dice everything, with every network device in a controller domain knowing the state of its connections. You can use that information to steer traffic away from congestion points and, if you’re clever enough, avoid congestion before it happens. You can do this while optimizing every flow based on any criteria I can measure inside a decision window. This centralized control plane with streaming analytics lets you do online traffic engineering, but not in a way that makes the network devices more complicated, but simpler – a tremendous need as both traffic (thanks to video) and connections (thanks to the Internet of Things) are set to balloon over the next few years.
I’m not denigrating the ability of things like Netconf or the Yang modeling language to make configuration tasks simpler. Writing and maintaining scripts that do that work, either standalone or as part of an Operations Support System (OSS) provisioning system, is hard work and those advances make writing and maintaining those scripts easier across different platforms.
The cat is out of the bag here, and OSS guys are going to have to adapt if they’re going to remain relevant. We can make network devices much simpler by centralizing control, and if we just give that controller a few simple tricks based on some analytics and the creation of a feedback loop, we can drive some of the time, talent, and cost out of owning this stuff.
The routers will still be complicated and heavy, but they’ll be far less of a road hazard.
