One of the questions raised by the onrush of interest in SD-WAN is where SDN is. Obviously, two things whose acronyms start with “software-defined” should be related in some way, and I’ve noted in other blogs that SD-WAN and SDN may converge in the longer term. What are the differences today, and where are we in coming up with a general, converged, model that would result in enhanced SDN features, including my “logical networking” capabilities?
There’s never been a lot of consistency in the SDN space. The concept got started by some university work that suggested that separating the control and data planes of networks and moving to a centralized control point for forwarding rules would improve both network efficiency and resilience. This stuff was the basis for the OpenFlow protocol and related device work, driven largely by the Open Network Foundation (ONF).
SDN in ONF form was a pretty radical concept. You have some central controller that is responsible for framing the routes taken by traffic in the network, and this controller then sent forwarding instructions to each OpenFlow white-box device. There are a lot of obvious questions raised by this architecture, such as how you ensure you don’t lose control connectivity with the devices or overload the controller. These have reduced the adoption of ONF SDN beyond the data center, where it obviously can work.
In the data center, though, the main impetus for SDN was tenant/application isolation. Ethernet LANs have various technologies to create private VLANs, but many cloud providers didn’t like them because of the limits they imposed on the number of VLANs or the fact that these technologies had to be implemented in the devices themselves. That gave rise to a second SDN model, based on an overlay network, one that uses traditional IP (or Ethernet) as a transport network, a kind of virtual layer 1 or tunnel network, and did its own routing at a higher layer. That allowed the overlay SDN model to support vast numbers of independent virtual networks. Today, we see this from a variety of sources, including Nokia (who got it by acquiring Nuage) and VMware (who got theirs by acquiring Nicira).
Overlay SDN is easier to extend out of the data center, and in fact Nuage (for example) did that from the first, providing branch/workgroup connectivity to the overlay network. That arguably creates the convergence between SDN and SD-WAN, since SD-WAN technology was at the same time moving to embrace data center and cloud connectivity as well as the branch connectivity it started with.
To make things even more complicated, bigger network vendors like Cisco tried to blunt any specific drive to SDN by offering application control over connectivity through distributed policy management of existing switches and routers. This was also characterized (particularly by the vendors themselves) as a form of SDN, so we ended up with three different models.
It’s my view that the industry is gradually drifting toward the universal adoption of an overlay model of networking. Bodies like the MEF (their “Third Network”) worked out a multi-network interconnect approach for an overlay network (but didn’t define the overlay). Overlays are proving themselves in both data center and WAN missions and are now starting to look at the features and benefits that an overlay could provide.
The most obvious place this new overlay-centricity would influence product directions is in SDN and SD-WAN, which both use overlay technology and which are already facing a converging mission. SDN overlays could easily be extended out to users instead of simply separating data center tenants, and SD-WAN already has to provide some support for cloud applications, support that could be extended into the data center.
We now have two vendors who are implicitly positioning for the convergence of SDN and SD-WAN. Nokia/Nuage has always had the capability, as I’ve noted above, but interestingly they’ve elected to frame an SD-WAN offering rather than a unified offering (though it is in fact unified). VMware has positioned its “Virtual Cloud Network” as a unified overlay model, but it still has a technical separation between their NSX SDN and Velocloud SD-WAN. The two exemplars of overlay convergence, with totally opposite approaches. Helpful, huh?
The barriers to unification probably start with the historic aversion of the network industry to the “god box”, a single device that essentially did everything you needed. Trying to sell this proved to be a challenge, since most buyers had a very limited set of missions and had to be made to understand stuff they never thought they’d need to value the universal capabilities of the device. Then there was the conviction of buyers that if a box cost X dollars for ten different missions, and if they valued only one, they should be able to find a box costing X/10 to serve their needs.
Another problem is that the quadrant charts of analyst firms rate vendors/products in specific categories, and something that fits into more than one is hard to position in these reports. A “god-box” category is unattractive and difficult to “quadrantize”, so to speak, and analysts love new product categories that justify new reports, so there’s not much incentive to reduce the product category range.
Vendor influence is another challenge for a single-overlay-network positioning. An overlay network provides all the features a user sees, because it rides on top where the user connects. By its very nature, it reduces the differentiation available to the underlay network, and that’s where switches and routers deploy. If anything you could overlay SDN/SD-WAN on top of would work to build the network of the future, the big vendors see this as hanging out a sign saying “White boxes welcome!” Since venture capitalists want “laser focus” from the startups they fund, small vendors tend to push simple missions and messages only.
That leads to the question of publicity. We have stories on both SDN and SD-WAN, and users are led to see the two product classes as totally independent rather than as different slants on a common (overlay network) approach. It’s difficult to sell network technology door to door, and impossible for smaller vendors. That means getting your name and product in front of prospects on a larger scale. What better way than to get your name into the media? Since editorial mentions drive website visits, then sales calls, then sales, you don’t want to mess with the publicity side, and remember we have SDN and SD-WAN stories, not overlay/god-box stories.
SDN cannot evolve without broadening its scope to include what SD-WAN does, and vice versa. Whether there’s going to be an SDN evolution seems likely to be indicated by the actions of the two SDN vendors who have SD-WAN-ish plans or capabilities. Do their actions indicate there will be SDN evolution?
No, they don’t, and some of my friends at the vendor level have a suggestion as to why, one related to my points above. Vendors see different buyer constituencies for data center networking and the WAN, which encourages them to keep the SDN and SD-WAN products distinct. In addition, it’s possible that each product area might arouse the competitive push-back of vendors like Cisco, if that vendor has a product strategy in either the branch/WAN or data center. Separating the pieces might facilitate a quiet introduction of the new stuff.
That doesn’t mean that there won’t be tighter integration of SDN and SD-WAN products down the line. Here the two vendors can each offer indicators. VMware, because they have a more unified positioning of SDN and SD-WAN and yet have less functional integration of their offerings in the two areas, could signal us by providing an NSX on-ramp from Velocloud. Competitor Nokia/Nukage has fairly complete integration, not yet leveraged in positioning. Positioning has little inertia, so they could improve their story.
All of this depends on my final point, which is the technical value of the integration. SDN applications for overlay technology involve creating an application subnetwork using overlay addressing to isolate applications and tenants in a cloud data center. SD-WAN uses overlay technology to create a VPN-like subnet that could extend, replace, or overlay an MPLS VPN. What’s the intersect?
There is really one intersect, and that’s the gateway that provides user access to an application subnetwork. That gateway has always spoken “external IP” into an IP network where users (including other applications) can access it. The “internal IP” used within the application subnet isn’t visible to the outside. There doesn’t seem to me to be any utility in making components of an application that were declared not to be exposed as part of the company VPN, only the exposed gateway(s). Logical networking enhancements only apply to visible network applications and components, which excludes the internal subnet connections of multi-component apps that SDN would typically connect.
If my view here is correct, a vendor who decided to declare for true convergence of SD-WAN both at the technical level and the positioning level would have to validate a benefit for the convergence, at least for now. I don’t think that this would be easy in the current market, and that probably means that the two product categories will stay separate for some time, and that overly SDN isn’t likely to get many advanced logical networking features in the near term.