The topic of SD-WAN just keeps getting hotter. Juniper, one of the network equipment vendors who hasn’t seen quarterly revenue declines, talked about it a bit on their earnings call. Here are some interesting quotes to explore: “Telcos are going through a significant transformation as trends such as SD-WAN…” and “So as we talk to our customers around SD-WAN, for example…” and “…it’s around business models and it’s around software. It’s around selling the value through Contrail, virtual security, SD-WAN.” Five citations in one earnings call. Interesting? And recall that Juniper isn’t a household name in SD-WAN either.
The first of these points is important because it’s clear that the network operator segment isn’t as much a factor for Juniper as it has been, or as it is for many of Juniper’s competitors. Juniper sees that sector as in the midst of a transformation and “…it’s all very much around new architectures, new ways of driving service revenues…” and that “…the new build-out that drive these new modes of service delivery are just going to take some time.” Clearly, Juniper sees SD-WAN as both a transformational element for the network operators, and a driver of change in itself.
SD-WAN is an edge-driven technology that wrestles VPN services out of a variety of infrastructure options, including the option of transformation of options. Today, it’s a means of achieving lower costs through partial or complete elimination of operator-provided (usually MPLS) VPN services. Tomorrow, Juniper thinks, it will be an item in a telco inventory, perhaps a way of generating a “service” that’s independent of infrastructure and thus able to ride out lower-layer transformations like SDN or NFV. They mention Contrail, their SDN/virtualization offering, in the same sentence as SD-WAN, after all.
Juniper doesn’t say exactly what “customers” it’s talking with about SD-WAN, but given the company’s success with cloud providers and given its specific mention of the cable companies, I think it’s likely that they are already in dialog with both those who would use SD-WAN as an overlay and those who would use it as a part of an infrastructure service—network consumers and network operators, in short. Juniper has SD-WAN material on both missions on their website.
One reason for all this “SD-WAN-washing” is the same as the reason behind other “washings”. You always want to tie yourself to something that’s getting good ink. However, as I pointed out in my blog yesterday, we seem to be seeing a greater recognition of reality in positioning these days, not only from vendors but from the media that wants their advertising. I think Juniper believes that SD-WAN is important because it’s a decisive way of separating service technology from network technology.
Today, network services are created by coercing native behaviors from the underlying infrastructure. An IP or Ethernet service emerges because of service features available in an IP or Ethernet network below. Things like SDN and the MEF’s “Third Network” concept presuppose that services could be offered that are laid on top of infrastructure, with the service-layer features added by the add-on. This vision would allow operators to reduce, eliminate, or shift their investment in protocol-specific technology within their infrastructure, which of course SDN and the MEF concepts presume is a goal.
Many of the benefits of SD-WAN, like the ability to extend services to smaller sites at lower costs, are attributes of any tunnel-overlay network approach, and there are of course many different tunneling models out there. Seven or so years ago, there was a rush to work on “pseudowire” technologies that let users build networks over virtual wires that were laid on various infrastructure options, and some of these supported nearly anything. So you could have accomplished a lot of what SD-WANs are supposed to do for half-a-decade or more.
What the current SD-WAN model does is productize the solution, which is essential given that it’s become clear that operational complexity is a greater risk to cost-effective networking than service costs or capital equipment cost. Users don’t want to do all the network planning and operations heavy lifting, and a good SD-WAN product is a kind of plug-and-play approach, encapsulating all the features and steps needed and organizing and managing them as a whole. Service management, independent of network management.
This is a topic that goes back even further than tunnel networking. I remember doing a CIMI White Paper on service management about 20 years ago. I’ve worked on the relationship between services and networks in standards groups for almost that long. What may have happened with SD-WAN is a “vehicularization” of the service layer, and that would give us a way to manage services that can be reduced to managing the devices of that vehicularized service layer.
We’re not out of the woods with this yet. I mentioned the MEF’s reliance on SD-WAN for its Third Network glue, but the MEF’s own material on SD-WAN takes a very limited view. The figure that leads off the MEF Wiki defines an SD-WAN as “SDN implemented on WANs”. I don’t agree with that, and not just for philosophical reasons. SDN today implies central OpenFlow control of forwarding, and while of course SD-WAN devices or software instances have to be able to forward traffic based on header addresses, there is neither a consensus today that this is done via SDN nor a need to presume that.
It’s clear from their broader description that the MEF is looking at the “infrastructure” model of SD-WAN, one where SD-WAN services are partly or fully reliant on features of the underlying network. Yes, since that is one of the SD-WAN goals, it’s important we understand how that might work. But first we need to decide on how SD-WAN services work, how they relate to the users and how they are managed as services.
It would be enormously helpful to have a model/MIB defined for the SD-WAN service interface, and another for the underlying network interface(s). It would similarly be helpful to have a specification for the way that an SD-WAN VNF looked and was managed (by VNFM). This would be a good time to get something like that going, before the SD-WAN market explodes and it becomes impractical to refit products and software to an emerging (and perhaps long-in-emerging) specification set.
If we know how an SD-WAN looks to a service-layer user, it would even be helpful in framing the way that it might call on infrastructure services. Certainly service-layer management has to be able to obtain from the user any parameters or behaviors that have to be driven downward into the network. Even the MEF work would benefit from that input, and so would NFV proponents that want SD-WAN VNFs.
We have, in the SD-WAN space, a rare opportunity to ride a credible market wave, but ride it far enough ahead of the crest that we still have options to standardize and structure things for interoperability and suitability to fit within other technology frameworks that are co-evolving. I’d like to recommend to the MEF leadership, and to vendors and operators, that we take up that opportunity and run with it.
