Stop me if you have heard this before: “We have had the ability to do that for 10 years. It’s called MPLS.”
For whatever reason, the networking industry seems more open to innovation these days than for much of the past 15 years. We see the rise of important technologies like SDN, NFV, network virtualization, DevOps, and photonic switching. Every new technology threatens to disrupt some existing technology. And along with it, whatever business or personal interests have accumulated alongside.
Take SDN for example. A centralized control plane does a couple of things. At its most basic, it makes things like edge policy provisioning more straightforward. Taken a bit further, it provides a point from which the network can be viewed as a single resource, which makes things like monitoring meaningfully different. Beyond that, a global network view allows for intelligent allocation of network resources.
Some networking diehards scoff at the notion that SDN is innovative. They proclaim proudly, “We have had policy controllers for ages!” They point to OSS/BSS systems and declare, “Monitoring has been done for decades. How do you think service providers stay in business?” If you mention anything about intelligent network pathing, they might ask, “Have you not heard of BGP or MPLS?”
First, let me concede that most of what SDN (and the other disruptive technologies, by the way) is trying to do has been done before. But that doesn’t mean that we should all become pointy-headed academics who say things like “Everything that is old is new again.” Doing so would ignore the very nature of change.
It is true that almost everything that is invented is a derivative piece of work. There have been a number of pieces written about the myth of the a-ha moment. Most epiphanies are the result of dutiful experimentation that yields a meaningful conclusion. That there is a conclusion provides an a-ha moment, but the experimentation that precedes it is where all the work takes place.
As we look at SDN, simply discarding it as a reimagining of things we have already done is ignoring the value of years of real-world experimentation with networking technologies. A more meaningful response is to ask: what have we learned through the years?
What we should take away is that the presence of advanced technologies is not sufficient. While it might be true that MPLS or BGP extensions are enough to make the network do whatever people want it to do, at what point do the diehards relent and ask the question: if the answers are so clear, why do 99% of networks not use these tools?
It is tempting to blame the users. There is this rather condescending viewpoint in some circles that people who manage some of the smaller or less sophisticated networks are somehow incapable. But riddle me this Batman: isn’t the measure of technology greatness at least somewhat dependent on how easy it is to use?
Said another way, there are really two sides of every technology: what it does, and how it plugs into what people do. No matter how elegant the solution, if it goes unused, it is in fact useless. As an industry, we have driven networking technologies forward paying careful attention to only half of this equation. In doing so, we have created the kind of inequality that we see in other aspects of society. We have in fact left behind networking’s 99%.
The question we need to ask ourselves is whether this is the right path forward. Does the fact that most people do not deploy sophisticated MPLS networks mean that the average network simply shouldn’t get access to the benefits of a well-traffic-engineered environment? Or does the absence of deep programming expertise mean that network operators shouldn’t enjoy a workflow-optimized experience?
The answer here has to be an emphatic no. We simply have to make some of these benefits more accessible to networks that extend beyond the major service providers, web-scale companies, and Fortune 100. Collectively, we need to be looking beyond just the capability. We need to consider how those capabilities are used in context. And then we need to make the associated workflow (everything from provisioning to validation to troubleshooting) much simpler to use.
If, when we are done, our networks are still unwieldy and fragile, then we need to keep working. The “problem” is not the people managing networks. The customer is never the problem. The real problem is that the networking industry has built half of some of the most powerful stuff imaginable. We need to build the other half.[Today’s fun fact: The world’s oldest piece of chewing gum is over 9,000 years old. I think I sat at the restaurant table it is stuck to once.]