Standards are not getting great press these days, nor are standards groups. Part of the problem is that open-source seems to be stealing the traditional thunder of standards, and part the fact that standards seem to take forever. That combination can be deadly, and when you think of standards in connection with a hot and expanding concept like SD-WAN, it can be doubly so.
According to SDxCentral, the MEF has set some new goals for its SD-WAN standards, which have been underway since 2017. There are ambitious goals for the new initiatives and for the MEF’s SD-WAN work overall, and given that there are at least two dozen SD-WAN implementations out there (including a new open-source one), you can reasonably question whether the market has already outrun the MEF’s work. In the near term, surely. In the longer term, we need to see what the MEF is trying to do to understand whether there’s a chance it can (retrospectively) impact the SD-WAN market.
You can read the public information on the MEF SD-WAN 3.0 work here, but if you want to read the draft standard you need to request it. The white paper on the page, which is freely available, does lay out the basic architecture and framework for the MEF’s work, but it dates to the launch in 2017. The figure on the referenced webpage provide a glimpse of the major goals of the initiative, which starts with defining standard elements of an SD-WAN deployment and giving them standardized names. To quote the site:
- SD-WAN Edge, Physical or virtual
- SD-WAN Gateway Between SD-WAN and external connectivity services
- SD-WAN Controller Centralized management of SD-WAN edges & gateways
- Service Orchestrator Lifecycle Service Orchestration of SD-WAN and other services
- Subscriber Web Portal Subscriber service ordering and modification
This is helpful in itself because (of course) SD-WAN vendors don’t adhere to any common terminology, and it’s hard to offer a general explanation of how SD-WAN works without running into differences in how vendors describe the pieces. The MEF does capture the real elements of SD-WAN, and it provides at least logical names for them.
Overall, the MEF is positioning SD-WAN services within their LSO (Lifecycle Service Orchestration) framework, which means (of course) that the MEF work is really more about SD-WAN service than about SD-WAN technology. That does help to dodge the problem with the timing of the work relative to the launching of SD-WAN products, but today the fastest-growing piece of SD-WAN service is the operator-provided SD-WAN, so the onramp for the MEF’s work at the service level is under some time pressure already.
LSO diagrams also lay out the notion of pan-provider service, so of course pan-provider SD-WAN would be a target. The question is whether, given that SD-WAN was designed to deploy over a network not within it, there’s a meaningful pan-provider dimension to SD-WAN unless there’s an attempt made to harmonize different implementations of SD-WAN for different providers. That doesn’t seem likely to work, since virtually every SD-WAN implementation has proprietary elements in tunneling and connection management. I note, though, that it would be possible in theory to create a kind of “SD-WAN Demilitarized Zone” between operators, where each operator contributed an SD-WAN node of some sort and the two nodes were interconnected on a small stub network. The white paper doesn’t describe this sort of pan-provider connectivity in any of its use cases, so we have no basis to assume there’s a specific strategy being promoted by the MEF.
One thing that is being promoted is some harmony in how SD-WAN elements would access the underlay transport network. That’s not particularly critical for SD-WAN vendors or users who acquire SD-WAN technology and build their own service, but it’s important for MSPs and network operators because without some standard interface between the SD-WAN “layer” and the transport “layer”, operators would have to provision transport connections differently depending on the SD-WAN implementation used. The obvious question is whether the MEF could effectively promote such a standard, given how many different SD-WAN vendors there are, and that most vendors would see any “open interface” as a doorway to admit competitors into their deals.
Some of the articles on the MEF’s work have suggested that some feature harmony would be part of the MEF’s work. One vendor was quoted as saying “that prior to MEF’s efforts in SD-WAN, vendors defined their services in a lot of different ways. Service providers need to have a service definition. With service definitions we are defining the vernacular. We are saying what the service components are and how they connect together.” That also seems problematic in a competitive market, particularly since the common vernacular would tend to impose a minimal feature set on buyers when the market trend is to advance new features for differentiation.
I understand the MEF’s interest in basic connectivity features. It will be incredibly difficult to harmonize SD-WAN if you step beyond VPN services, because what lies beyond basic VPN services is anyone’s guess, anyone’s product decision. Furthermore, if you aren’t doing just VPNs you are now stepping into areas where IP standards don’t offer any guidance on interworking, or any base set of protocols or procedures that might offer interworking solutions. It’s the wild west of connectivity.
But is that bad? SD-WAN, even as a service, is really about the “edge” as the MEF’s own material admits with its definitions of the elements of an SD-WAN service. In the terminology of old, we have a user/network interface or UNI in the SD-WAN Edge, and a network-to-network interface (NNI) in the SD-WAN Gateway. An NNI is still an edge, not a deep element in operator infrastructure, and given that it’s not clear whether you really need a lot of interworking of the SD-WAN layer and not of the transport layer. Does the MEF see operators selling SD-WAN interconnect among different SD-WAN implementations? The operators I’ve talked with aren’t seeing that approach at all.
Most of the leading SD-WAN vendors have either said nothing about the MEF work in public, or been cautiously but noncommittally supportive. In private, some have told me that they think the MEF is making a fundamental mistake with SD-WAN, treating it as a featureless IP VPN implementation option when in fact there are already SD-WAN implementations that offer features IP VPNs lack. Some of these features, like the ability to host a software node in the cloud to extend SD-WAN connectivity there, challenge a carrier deployment model because they involve a non-carrier component. Other features, like explicit connectivity control rather than promiscuous connectivity that IP provides, are increasingly found in the newer SD-WAN offerings, and most operators believe that they need many more features, even services above simple connection, to be successful.
It seems to me that harmonizing SD-WAN features through standardization is going to end up emphasizing the lowest common denominator, and that’s already shooting well behind the duck in terms of state of the art. It does nothing but encourage operators, who are already too fixated on simple connection services, to hunker down in their comfort zone and await inevitable doom.
Years ago, on election day in the US, I participated in a mock political debate on smart versus dumb pipes. I took the smart pipe side and won, and my argument was that without something beyond basic connectivity features, operators were doomed to be low-value players that could easily end up needing government protection again. SD-WAN could be important not because it’s an extension to the dumb-pipes model of VPNs, but because it’s an on-ramp to the smart pipes that operators need. It’s fair to say that if operators are satisfied with basic SD-WAN connectivity, they’ll never get smart at all.