Will the MEF SD-WAN specification work solve the vendor lock concern?
Back in September 2017 I had a chat with Daniel Bar-Lev at the SD-WAN Summit in Paris about the work MEF is doing regarding specifications for SD-WAN. This was after a heated debate on a panel I moderated about “The Ingredients of an SD-WAN Service” that got into talking about standards and the work the MEF is doing on this front. Daniel wasn’t on the panel but since he is a Director at the MEF CTO office and is facilitating the specification work at the MEF, I asked for his comments on the topic of standards.
Now that we are getting close to the 2018 SD-WAN Summit, I thought it would be good to take another look at the MEF whitepaper and get up to speed with Daniel.
Taking one step back for those who are not familiar with the MEF. The MEF is an industry association with 200+ member companies, mainly service providers and vendors that deal with specification, implementation and certification around Carried Ethernet, IP, Optical Transport and SD-WAN services.
MEF & SD-WAN
As mentioned, the MEF is dealing with specification, implementation and certification. Let’s take a closer look at each of these in relation to SD-WAN services.
This work spans two main areas, one already public which is the definition of the LSO (Lifecycle Service Orchestration) APIs. This work is detailed in the previously mentioned whitepaper. In a nutshell, these APIs cover the interfaces between:
- SD-WAN Edge and the Controller (LSO Adagio)
- SD-WAN GW and the controller (LSO Adagio)
- SD-WAN Controller and Service Orchestrator (LSO Presto)
- Service Orchestrator and the Service Provider BSS or Business Apps (LSO Legato)
- Service Orchestrator and the User Web Portal (LSO Allegro)
- Service Provider BSS or Business Apps and the User Web Portal (LSO Cantata)
The goal of these APIs is NOT to try and create many-to-many interoperability between SD-WAN vendors. Trying to do so would be a failure as each vendor has its own technology and methods implemented in the SD-WAN Edge and GW which make it an end-to-end service.
The goal of these APIs is to allow for a service provider or enterprise to manage and orchestrate SD-WAN services from one single backend that rules them all.
While this work has been underway since 2017, I’m not aware of any vendor that went full force this path, nor did I hear from service providers a strong demand to have this. If there are any vendors that already offer support for these APIs, please contact me, I’ll be happy to mention that in details on my blog.
The other specification work that is underway is defining what SD-WAN actually is. With 40+ vendors claiming for the SD-WAN crown, enterprises are puzzled and have a hard time deciding which vendors or service providers to evaluate when making their SD-WAN choice. The MEF is working on a specification that will define the minimal must a service should have to be called SD-WAN. This is so enterprises will have some common baseline to relate to. This work is currently in call for comments (available for MEF members – vendors/SPs) and is expected to be publicly available around the end of 2018.
My 2 cents on this work: Current situation in which companies do a marketing spin around the buzzword SD-WAN although they continue to do their traditional WAN optimization/App prioritization or any such partial solution is a problem.
Having said that, I have 2 concerns related to this work:
- Over specification
- Vendor-specific impact on the specification
The success of this work will very much depend on where the line will be drawn, to what level and details will this specification get into.
Over specification (defining areas that should be vendor or service specific) creates issues, it hinders innovation. Enterprises know better than anyone else what their needs are and are capable of ignoring the noise.
One needs to remember examples of such specification attempts. A good example is the specification of RCS by the GSMA which resulted in failure and the creation of OTT providers such as WhatsApp that took the messaging revenue away from the service providers. This failure was mainly due to a very long over specification process that went way to high into the application layer.
Vendor-specific impact on the specification
SD-WAN vendors involved in the specification work is also a concern. Different from open standardization organizations such as the IETF where work is open to the public and anyone can comment along the process, this work is open for members only and will be released to the public only once completed.
IETF work is also impacted by vendor specific interests but the process is transparent from start to end allowing anyone interested in being part of it to follow and contribute.
Yet to be seen what the MEF has for us in this area before being able to reach a conclusion, my hope is that this specification will be limited in its scope and vendor agnostic.
The implementation work puts the specification to work and includes actual coding and integration. Currently, VeloCloud (VMware), InfoVista, Riverbed and Nuage Networks (Nokia) are engaged in this work to test usage of the APIs for management and orchestration integration between them.
The goal of this is to allow vendors or service providers to pass through a certification process after which they will be able to claim that their compliance with the MEF specification is certified. More about this process can be found here.
Enterprise & service provider concerns
Above, I reviewed the specification work done by the MEF but as mentioned, it is not yet adopted by the industry in working products nor do I hear a call of urgency by enterprises or service providers for realizing it.
What I do hear from large and small service providers I speak with is mainly a concern. A concern about the launch of their SD-WAN service and how do they differentiate themselves from SD-WAN vendors that offer a managed service. This differentiation is imperative when speaking with an enterprise that is considering its SD-WAN options. The service provider concern is mainly how not to become simply a pipe, due to the fact that SD-WAN is offered as an overlay, not tied with the underlay network, this concern has merit.
The other concern I hear from both enterprises and service providers is vendor lock. Again, due to the end-to-end nature of SD-WAN and since these solutions are not really open in their core for 3rd party integration (not talking about management or LSO type of interfaces) they leave the enterprise and service provider with very little control over the service. Many enterprises decide to live with the vendor lock for now. Service providers, on the other hand, opt for the multivendor approach but this only allows them to offer a complete and closed service they hardly control by using different vendors for different segments of their customers.
Both enterprises and service providers are looking to release themselves from the vendor lock chains currently embedded in the nature of SD-WAN services.
The MEF is not a new organization, it was founded in 2001 and started with Carrier Ethernet. SD-WAN is an overlay and therefore has less need for coordination between vendors. Only time will tell to what extent the specifications created by the MEF will be adopted by the industry.
Based on my conversations with service providers and enterprises, their main concern is the closed end-to-end nature of SD-WAN solutions and the fact that additional services (e.g. security) are added on top, this is a perfect storm for creating vendor lock. Join other enterprises and service providers on a mission to minimize vendor lock in SD-WAN deployments – Qualify here.
In what way do SD-WAN and WebRTC take a similar approach to standards?
How can Enterprises & Service Providers avoid the SD-WAN vendor lock through a community-driven ecosystem? Learn More
Never miss a post. Subscribe to TheNewDialtone
Leave a Reply