When standards matter (and when they don’t)
Standards are there to make our life more comfortable.
A car can’t be wider than 2.6 m (or 102 inches)
Built-in ovens are 60 cm wide
A USB device must follow a specific USB generation standard
An SD Card must fit the SD Card slot of the standard size it is advertised to support
What ties these things together is interest.
The common interest in all the cases above is financial. You must comply with the standard for your product to sell, either because of regulatory requirements as in the example of the car or because you provide only part of the puzzle and need the product to work nicely with the other pieces of it.
If you build an oven that doesn’t fit into most standard kitchens it will not sell.
If you build a USB device or SD Card that doesn’t match the requirements of the computer it needs to plug into, the customer will return it back to the store.
SD-WAN & WebRTC and their take on standards
In traditional VoIP, standards were developed to ensure that products of different vendors would work together in harmony and by that avoid the vendor lock syndrome. The goal was that an enterprise would be able to use a VoIP PBX of vendor A (that was before this function was moved to the cloud) with IP phones of vendor B and recording system of vendor C.
In theory this makes sense but in reality, vendors wanted differentiation and to lock their customers into their product line or ecosystem so they modified the protocols or added proprietary things on top, making it hard to mix and match products of different vendors.
WebRTC took a different approach and went more for compatibility rather than for interoperability. WebRTC was designed to be an end-to-end solution, therefore it didn’t standardize signaling. The only things it did standardize are the things that go on the wire like media, encryption… (IETF) and the APIs (W3C) so one side of the call could be on browser A while the other participant could be on browser B.
Even with this limited scope of standardization, we are not at full compatibility yet and the goal of having cross-browser compatibility is not yet realized in full.
SD-WAN has some similar characteristics in the sense that it is an end-to-end solution. The MEF has taken the effort to standardize interfaces of SD-WAN. These interfaces are for different levels of management and orchestration layers. The goal is not to allow for mix and match between elements of SD-WAN vendors such as having different vendors’ edge devices on each side but rather to allow for a unified management and orchestration system for all vendors.
Similar to the WebRTC goal of browser compatibility, also in SD-WAN, this goal is not close to realization.
The MEF is now on a new journey to define the minimal must capabilities of an SD-WAN system. A bold initiative, we’ll see where this leads to.
More on SD-WAN and MEF standardization work next week.
Standards are made to make things work together but must also be tied to the business interests. Standards can’t force companies or users to accept them, they need to bring value. There are many examples of standards that didn’t live up to their promise because they missed this point, RCS is a great example in the telecom segment.
SD-WAN standards are still under construction.
Is there a need for them?
What should they cover?
Who should drive them?
All and more will be discussed on my next post. Register now to be the first to know once it is out.
Meanwhile, write your view or questions in the comments below. I’ll try to address them here or in my post next week.
Learn about security and SD-WAN integration, should you trust your SD-WAN vendor for security features?
How can Telcos avoid the SD-WAN vendor lock through a community-driven ecosystem? Learn more
Never miss a post. Subscribe to TheNewDialtone