If software defines everything, is everything converging? Obviously not, but some software-defined things probably are converging, and there’s no better example than that offered by SDN and SD-WAN. The big questions raised by that convergence are what emerges in the way of a combined model, and what group of vendors/supporters wins in the mash-up. Will the future be SDN-ish, driven more by SDN features and vendors, or will it belong to SD-WAN?
Let’s first dispense with the “probably” qualification in my opening. SDN and SD-WAN are converging, but that’s not admitted by all the players. Software-defined networking (SDN) emerged in the form of the Nicira overlay network technology aimed at creating effective multi-tenant cloud networks. That first mission of SDN was to separate a physical network into multiple virtual networks. SD-WAN is also a form of overlay technology, but one designed originally to combine multiple physical networks into one logical network. Separating and combining are opposite processes, but they’re both a form of mapping between the physical and virtual.
The separation between SDN and SD-WAN really came about as the formal standardization of SDN emerged in the ONF. SDN became not an overlay technology as the original Nicira model proposed, but rather a substitution for a traditional adaptive forwarding technology that was based on explicit forwarding tables maintained through the agency of a centralized controller. The OpenFlow evolution hasn’t been enormously successful, as my blog yesterday on the new ONF initiative (Stratum) concludes.
The problem with this evolution of SDN from, a pragmatic marketing perspective, is that the kind of transformation required in network infrastructure to adopt SDN. Switching to explicit white-box forwarding on a large scale is simply not practical, unless there’s some massive range of service benefits that could justify it. Even the AT&T dNOS and ONF Stratum initiatives, and P4-based network devices, don’t change the fact that SDN is still about forwarding networks.
SD-WAN, in contrast, is about connecting and connection management. The nice thing about SD-WAN and the original overlay model is that since it is an overlay it doesn’t require transformation of the underlying infrastructure. Instead it maps services to a new layer on top of that infrastructure, and there it’s free to adopt whatever connectivity forwarding and connection management rules it finds convenient. SD-WAN fits a “mister outside” model, a model that puts it in the point of connection with the user, and that’s the ultimate high ground.
Buyers report that SD-WAN is cheaper even than “commercial” overlay SDN, and it’s also reportedly a lot more operationally friendly. That combination has made SD-WAN a favorite of managed service providers who position it as a kind of multinational VPN without MPLS interconnect problems. If the SD-WAN product has prioritization features, it can even offer a better managed service model where the underlying service is homogeneous, or it consists of one VPN and the Internet. But most of all, SD-WAN is about WAN, which is where SDN needs to be to succeed broadly.
It’s pretty clear that SDN is going to maintain a datacenter-centric mission unless something radical happens to justify SDN being extended into the WAN. It’s pretty clear that SD-WAN is already in the WAN, and because of that any attempt by SDN to penetrate the space is necessarily going to cause a functional and marketing collision with the other technology.
It might be possible today to see an example of that collision in the Nuage SDN product from Nokia, which is an SDN product that includes SD-WAN capability. Nuage is arguably the most functionally useful of the SDN implementations. It doesn’t conform to the strict OpenFlow white-box-centric new forwarding paradigm of the ONF. Instead it goes back to the original roots of SDN with Nicira-like technology. Perhaps that regression is why Nuage is able to provide something which is, in a functional sense, almost a bridge between SDN and SD-WAN. But how much of the SDN side is baggage now, if the SD-WAN space is the end of the rainbow? What other useful or even critical SD-WAN stuff could we find in that space, stuff SDN has yet to address?
I blogged about what that stuff might be, over the last ten days. The clear truth is that if both SDN and SD-WAN are about virtualization, then it’s time to start thinking about virtualization in the broadest sense. That’s the only way we can hope to understand where the two converging technologies are converging. Where is virtualization in networking services heading? Ultimately, toward creating the truest form of “network as a service” (NaaS), a form where what’s connected is connected by policy.
The basic notion of NaaS is to provide policy-managed connectivity over arbitrary infrastructure, in such a way as to separate services that need to be separate and make inclusive those that need to be. To make NaaS work, you need to have physical connectivity across your community of users, though it doesn’t have to be provided to every user in the same way. The NaaS overlay would harmonize any differences in how lower-level services worked, and create communities that could draw from any mix of underlay technology.
SDN today has focused on providing alternative underlay networking not NaaS, though as I’ve said the earliest models of “SDN” were overlays and offered NaaS services. So do some of the current options for SDN, in fact. But it’s SD-WAN that most clearly aligns with the original NaaS concept, and so if the NaaS model is the future, it’s a future that SD-WAN would be best positioned to control. Is NaaS the model?
The mission of most policy-managed connection models and even of access control technology at the application level, is to create virtual subnetworks. Presume universal open connectivity and then bar the stuff that you don’t like. This model poses pretty significant challenges even today because of the difficulty in ensuring that the prohibitions on connectivity are established and maintained in the face of dynamic worker movement. Start moving resources around and it can only get worse.
In a dynamic cloud framework, you host stuff where you need to, based on a combination of hosting policies and application needs, tempered by availability of the resources. From the first this created issues with addressing resources, because of the classic what/where dichotomy of IP networks. An address gets traffic to the addressed entity, which means that the address represents the entity at a logical level and the hosting point at a real level. Virtualization’s elasticity messes up this picture. Amazon, with Elastic IP Addresses, provided a mechanism for tying a logical resource (the elastic address) to the physical resource (the private cloud address).
The problem with this basic level of virtualization support is that it doesn’t establish the community entitled to communicate, only the means of connection. Fundamental to NaaS is the notion of “services” or “service subnets” that represent a collection of things that can connect among themselves. That could be provided by SD-WAN, but the way it gets provided is as important as the facilities. A pure policy-and-firewall model only establishes an SD-WAN as the place where you have to maintain connectivity rules, not a way to make the rules easier to apply and maintain.
To make service/subnets work, you have to start with logically named entities and deal with addresses as nothing more than a convention needed to map “virtuality” to reality. You then have to provide a way to associate the names into communities, and only then map to a way of addressing them over the set of physical facilities that exist. This capability could be offered by SD-WANs (and is offered in some cases) but it’s not the basis for most current products, and isn’t even provided in useful form in all of them. If you’d like to read about the SD-WAN offering we think best fits our future-needs model, we’ve produced a free report.
We have done a great disservice to the SD-WAN space, to the SDN space, and to networking overall, by conflating solutions that don’t have much in common except an acronym. SD-WAN is perhaps the worst of the lot, because there are so many different ways of seeing the technology, and so few that are actually leading us to where we need to be. What will enable SD-WAN, and SD-WAN vendors, to win the race with SDN is an awareness of the real, long-term, value proposition of NaaS. Some of that awareness is emerging in the market even now.
SDN may undergo a transformation as new forwarding-control technologies and architectures emerge. I blogged about AT&T dNOS and ONF Stratum earlier this week, and they could certainly change the game and help get SDN out of the data center. But all the way to the edge? It’s hard to see how these SDN advances do anything more than harden SDN into transport flow management missions, and the money will always be where the user connects with what the user is paying for—connectivity. This is SD-WAN’s game to lose.