What’s in a name? Too much, in many cases, because we tend to use a single very popular name (one with good media visibility) to cover a product space that may have little in the way of uniform features or even missions. We clearly have that problem with SD-WAN. Scott Raynovich did a nice piece in Fierce Telecom on why vendors and service providers “missed the boat” on SD-WAN, and it shows indirectly how the same technology name can cover a lot of missions.
The main point of the piece is that because SD-WAN is an alternative to higher-profit MPLS VPN technology (that service providers can charge for and that equipment vendors can sell more to support), fear inhibits support of SD-WAN by either class of player. I think that’s very true, but I think it’s also true that there could be more to SD-WAN than MPLS replacement, and that’s getting overlooked.
Basic SD-WAN uses the Internet create a little VPN among thinly connected sites, and then connects that to the company’s MPLS VPN. Some vendors promote a total replacement of MPLS. That’s an easy value proposition to sell—buy this and spend less, or connect more. It’s also something that could be done using half-a-dozen classic tunneling approaches, using open-source software. Durable SD-WAN value demands more features.
The cloud, in various forms, is already driving a broader vision of SD-WAN features. If you’re going to host something in the cloud or use a cloud-hosted SaaS, you may need to incorporate what you’re using into your VPN. Cloud providers charge for MPLS VPN connections (some don’t even support them), and they certainly won’t let you stuff SD-WAN boxes into their data centers. As a result, some vendors have added cloud-hosted SD-WAN agent elements to their offerings, which extend the SD-WAN into the cloud and support at least some configurations of cloud applications.
The cloud is the tip of the iceberg. Virtualization, as the general process of creating an elastic abstraction between application hosting and actual server resources, creates a much more complicated problem than the cloud. Here we have the notion of a component of software migrating around a pool of resources to accommodate failures or overloads. The problem with that is that we reach applications by IP addresses that represent where something is, not what it is in a logical sense.
What I’ve called “logical networking” is the next step in SD-WAN evolution; the need to support the cloud is the “camel’s nose under the tent” here. Inevitably, we end up with more features to support the agility of virtualization, and inevitably that leads us to logical networking.
What these statements show is that there are really three different broad models of SD-WAN, but we really don’t recognize the differences. In the process of consulting, blogging, and doing an SD-WAN tutorial (available the end of July 2018), I’ve looked at about two dozen SD-WAN vendors. What I find is that the great majority cluster around the first and most basic mission, or the second and simple cloud extension mission. Very few even promise to support broader virtualization and logical networking. And yet, we talk about “SD-WAN” as though there was some specific set of features that the name implied. There is no such thing even now.
Recently there has been some discussion about “standardizing” SD-WAN, but it’s my view that these comments suffer from the same name-overloading that the term SD-WAN itself does. SD-WAN is a bewildering collection of naming, addressing, connection awareness, policy management, network management, security, compliance/governance, orchestration and “network as a service” (NaaS) concepts. The “standardization” so far seems to focus on a tiny piece or two of this—common encapsulation of data within the SD-WAN, common interfacing to MPLS VPNs or the Internet, common hosting models for the cloud. The higher-level features that will dominate the SD-WAN market down the line are simply not on the radar of the standardizing people, because these features are way out of their domain of influence.
NFV is another example of the overloading of a term creating confusion. Much of what people think is happening in the NFV space has nothing to do with the NFV specifications. We’re really talking about “white box CPE”, a generalized device into which we could inject network features as needed. This, as an alternative to a bunch of specialized appliances strung out in a sequence at each service termination. Do we need to service-chain stuff inside the same box? Hardly. Is the ability to do that a proof point in NFV adoption? Hardly. Is there therefore a fragmented notion of NFV and the market for it? Surely.
Everyone thinks the cloud and virtualization are transformational in IT and the Internet, yet we’ve barely thought about the ramifications of virtualization in the area of agile connectivity. We have here the unusual picture of a market rushing forward to define what might be the most fundamental requirement for optimizing our future hosting and networking model, and we’re really still stuck in bearskins and stone knives (to quote an oft-used phrase). The problems we’ve had in overloading other technology names (like NFV) could pale into insignificance compared with what could happen here, because SD-WAN is really, vitally, important and most of the stuff that makes it that isn’t available in the offerings today.
I remember the first personal computers aimed at business users. They were as big as a convection oven, difficult to use and develop for, and most of all lacking in any clear mission or major sponsor. What changed everything was the IBM PC, and not because it was a technical marvel (my system was the second delivered in New Jersey, had 128 kb of RAM (yes, that’s kilobytes) and two floppy drives, and was “so complex” that the local store had to get IBM specialists to help configure it. Because it had a business mission and a credible sponsor.
IBM didn’t invent the PC, and in fact their technology at both the hardware and software level was much the same as we had already in the older business PCs. They provided business air cover for buyers, provided a vision of workers empowered by something on their desks and not just something living in a distant data center tended by technological geek acolytes. This is what the big players could have provided for the SD-WAN space.
This is where Scott’s point is right on, or perhaps even a bit understated. The big players have missed the boat, but the boat wasn’t launched by the price war with MPLS VPNs. You could forgive vendors for not rushing to create a network technology that ultimately undermines their revenue stream, which is all the basic model of SD-WAN could be expected to do.
Not all that it can do, though. What both vendors and network operators have missed is the opportunity to frame SD-WAN and logical networking as the virtual network, the NaaS, of the future. And, of course, the opportunity to set themselves up as the kingpin of that space. So here are the questions. Are we going to have a populist revolution here, a smaller player that rises up to strike at the mighty? Or are we going to see some major M&A when the real requirements of the market, the next generation of SD-WAN, are realized?
An effective SD-WAN overlay based on logical networking would relegate current enterprise network technology to the role of plumbing; all the features would live up in the SD-WAN layer. That’s’ where vendor fear comes in, but is some of that fear a result of taking such a short-sighted view of SD-WAN features? If the total network is more valuable, could it not justify more spending? If a vendor had both the underlay traditional stuff and the SD-WAN stuff, the combination could be a gain not a loss. If somebody else gets the SD-WAN stuff, then loss is what you’re left with.
Scott summed it up nicely: “This [the cloud and SaaS] is a strong value proposition that will continue to attract investment from enterprises to build next-generation SD-WANs. Providers of legacy WAN hardware and services should adapt as fast as possible, or they risk being left behind.”