The industry has come a long way since SD-WAN came into the limelight a few years ago. From a debate within service providers on its relevance vis-ŕ-vis MPLS to becoming an essential part of the business offering by service providers, SD-WAN boasts not only industry-wide acceptance but tremendous growth too.
With such strong growth, the industry felt the need for SD-WAN standards, so the MEF 70 specifications are an important milestone in the standardization of SD-WAN.
This standard specifies the "service attributes" for an SD-WAN service, providing what had been a missing piece from the SD-WAN managed services offered by communications service providers. It will help the SD-WAN community to be able to refer to the same terminology when buying and selling an SD-WAN service. In addition, it enables the deployment of SD-WAN with standard service attributes, and that service transparency benefits service providers and their customers alike.
So far so good.
However, there is another important part of the SD-WAN process that does not relate to the customer -- how an SD-WAN service is actually implemented in a network. MEF 70's scope does not cover implementation, despite its importance: This needs urgent attention from other standard bodies.
So, how important is this issue? Consider the following…
Any vendor's SD-WAN solution is like a black box, as shown below. Inside the black box, there is no "open" standard on how the SD-WAN manager and the SD-WAN controller communicate with different SD-WAN CPEs and how one SD-WAN CPE communicates with others (some combine the manager with the controller, while others keep it separate). In short, there is no standard related to the data, control and management planes. (For perspective, MEF is only addressing the area that relates to SD-WAN service for a customer, which is primarily the user-to-network interface, or UNI, in the instance below and, in future, the APIs from the Orchestrator to the Controller.)
So there are as many ways to implement SD-WAN as there are SD-WAN vendors. Not surprisingly, every solution comes with the vendor's own secret sauce -- the vendor's own tweaks to networking protocols and other proprietary developments.
Consequently, it's impossible to introduce a second vendor's CPE in this black box as the existing manager/controller is not able to manage it -- to introduce a second vendor's CPE, you would need to add its own manager/controller. Not an ideal situation, is it?
This vendor lock-in situation is bad for service providers for various reasons:
In addition, apart from a few exceptions, it doesn't help the SD-WAN vendor community:
The good news is that, with relatively little effort, the industry could address data plane standardization as the vendors are already using standard protocols such as VXLAN, IPSEC and GRE. Some effort would be needed to address how the manager/controller communicates with multiple CPEs, but Netconf/Yang could come to the rescue here if vendors are willing to cooperate.
So, could the industry resolve this situation by cooperating to address these issues through standardization? I ask because this industry constantly talks about open source, interoperability and avoiding vendor lock-in and there has been plenty of work already done by industry bodies in SDN that could be re-used.
The SD-WAN market for vendors is projected by IHS Markit to grow quickly and be worth US$4.4 billion in 2023: It would be a shame if standardization efforts were ignored in what is such a major and important market.
Do you agree or disagree? Please share your thoughts.
— Faisal Khan has 17 years' experience working with a range of network operators across the Middle East and Africa region, including one where he is working now: The views expressed here are his own and do not reflect those of his employer. He shares his views through his blog at www.telcocloudbridge.com. You can find him on LinkedIn at https://www.linkedin.com/in/faisalk1/