SD-WAN remains a very hot topic, and say the enterprises I’ve chatted with, a very confusing one. The biggest source of the confusion is the fact that we use the single term “SD-WAN” to describe what are actually three different architectural models. Not only do those three models differ in capabilities and focus, they can also be looked at in different ways based on different SD-WAN value propositions. It adds up to too many subtleties for many users.
About the only thing that’s fairly consistent in the SD-WAN space is that, in some way using some technology base, SD-WANs create an overlay network framework. That means that they define an address space and connectivity rule set that uses traditional Ethernet/IP networks (including the Internet) as a transport network. Years ago, you could have created something that today would have been called “SD-WAN” using an edge router that could support some “tunnel” or “virtual wire” mechanism.
The dominant model of SD-WAN still looks a lot like that old tunnel-routing approach. The dominating feature for this model is the ability to use the Internet as an extension to or replacement of a corporate MPLS VPN. Since universal connectivity of all company facilities is important to most information empowerment strategies, this has been the primary driver for SD-WAN interest. That’s why there hasn’t been an enormous amount of pressure for the vendors supporting this first SD-WAN model to shift their focus.
Some shifting has been required, though, because while thinly connected branch offices are a general problem for enterprises, the ability to connect the cloud has arguably become a greater need. As we look to integrate public clouds and data centers into hybrid cloud and multi-cloud, it’s important to have control over your applications’ address space and connectivity wherever you happen to host the application components. Adding a software-hostable SD-WAN node instance for the cloud is now almost table stakes in any SD-WAN.
The second model of SD-WAN has been mindful from the first of the address-space-management and virtual-network-creating requirements the cloud introduced. The vendors who support this model (no more than three, currently, as far as I can tell) provide explicit control over forwarding policies rather than replicating the promiscuous routing that’s a fixture in IP networks overall. These vendors not only provide inherent security features, essentially combining firewall capability with SD-WAN, but they also can offer policy controls over traffic priority and even failover and trunk usage priorities where there are multiple connections per SD-WAN node available, or where wireless backup for wireline connections is available.
The third model of SD-WAN is one where additional connectivity features are provided through integration, most commonly in the form of “universal CPE” (uCPE) and virtual network functions (VNFs). Service providers, meaning the big-tier telcos and even some cable operators, are interested in this model because it leverages the long-standing NFV work many have been involved with. These products can provide connectivity control, but do so by adding an incremental firewall component. They can also provide other encryption and security features the same way.
The big failing of this model, in my view, is the fact that NFV is a big-operator strategy, not well-suited for managed service providers and not suited at all for do-it-yourself enterprise adoption. You can already see that some of the vendors in this space are becoming more uCPE-centric than NFV-centric, meaning that they’re allowing for hosting of features in a white box but not mandating NFV technology be used for deploying and managing those features. Since there are no hard standards for how independent components would share a piece of uCPE, this evolution tends to create a lot of risk of fragmentation, silos, and compatibility issues that could lock in users to a limited set of virtual features.
Another issue with the VNF approach is the licensing cost for the elements needed. Operators have been upset by vendors’ pricing policies for licensing VNFs, though of course vendors see this as ensuring their own business case is met by unbundling their software from proprietary devices. The only logical solution to this, as I proposed back in 2013, is relying more on open-source VNFs. There are open-source implementations available for nearly every useful network function, but NFV integration in general, and uCPE integration in particular, has been a barrier.
Other feature issues are emerging that cut across these three models. One is the use of wireless (often 5G in the media sense, even though 5G isn’t available enough to serve the role at this point) to back up wireline connections or to connect ultra-thin sites where no wireline may be available. It’s likely that 5G fixed-site connectivity will be supported by some 5G access point. For business sites, the device would almost surely have to include an Ethernet port, and so an SD-WAN product with two Ethernet ports could support both a wireline Internet path and a 5G (or 4G) path. A 5G hotspot that was dual WiFi/5G for local connectivity, or one with an Ethernet port, could also serve.
The key point is that it’s easy to support 5G or any “G” that offers an Ethernet port and presents a standard broadband access interface upstream. Optimizing that capability is another matter. Enterprises tell me that they expect wireless backup for thin sites to be available at a lower speed and higher cost, and therefore they want to have special control over the traffic policies while in backup mode. That implies an integrated connectivity management capability, since a separate firewall would probably not understand backup status.
Another interesting development is the notion of an open-source SD-WAN solution. A new company, flexiWAN, is now engaged in PoC trials with an open-source implementation. I’ve reviewed the white paper on this, and the idea is good but there aren’t enough feature details for me to assess just what the new open product can do. According to the company, flexiWAN will be a kind of “Android for routers”, a baseline set of features and a set of APIs that facilitate the integration of third-party components that add functionality.
flexiWAN sees SD-WAN as a foundation element, a virtual-network connection framework in which other things can then be used. This has some similarity to the way Kubernetes has evolved, as the basis for not only deployment but also a full ecosystem of capabilities. There’s not nearly enough detail available at this point to see how far they’ve gone in fulfilling their goals, but the notion is surely intriguing, especially for someone like me who’s a fan of open-source software.
SD-WAN today has multiple dimensions of divergence, in short. That in itself creates a certain disorder in the market, and I think one of the main reasons is another dimension to the space—the “media” dimension. The biggest SD-WAN vendors, the ones with account control and sales presence, don’t really have any incentive to push the envelope. The up-and-comings are, almost without exception, failing to use the media to promote any strong differentiating position. As a result, we have two market dimensions to align with the three technical models. One dimension is the “incumbent” players, who are largely leveraging their positions with customers and promoting a simple value proposition that leads to quick sales, and the other the startups who need to convince buyers of a new paradigm, but are so far not carrying that burden. We’ll probably not see any order in the SD-WAN space until this final two-dimensional face-off resolves itself.