Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.
October 22, 2019
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:
It increases operating expenses (opex), as deploying any SD-WAN solution means depending on the SD-WAN vendor for operational issues inside the black box, as any regular network engineer may not know how the solution is managed. Even if network engineers are trained on one solution, introducing more SD-WAN vendors means upskilling the same network engineers again and again.
It unnecessarily adds an extra layer of inventory, as a second SD-WAN vendor in the network means you must buy the second vendor's manager/controller.
Direct Interoperability between CPEs is out of the question.
In addition, apart from a few exceptions, it doesn't help the SD-WAN vendor community:
If SD-WAN systems were interoperable, there would be a greater likelihood that service providers would introduce additional SD-WAN CPE units from new vendors with little effort or pain. But if they are not interoperable, service providers are discouraged from seeking new vendors. This obviously helps incumbent SD-WAN vendors but blocks other players that could land new business from supplying their CPE units.
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/
Network Operator Technology Planning Dept.
Faisal Khan writes on his blog at www.telecomlighthouse.com on issues facing service providers on subjects related to SDN, NFV, Virtualization, IP and Optics. He has rich experience, working with multiple service providers and vendors in Middle East and Africa region. Currently, he works for a mobile operator Mobily in Saudi Arabia in technology planning department. The views expressed in this blog are his own and does not represent the views of his employer.
You May Also Like
Rethinking AIOPs — It's All About the DataMar 12, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Fiddling with Fixed WirelessMar 21, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Cable and 5G: The Odd Couple?Apr 18, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Delivering the DAA DifferenceMay 16, 2024