Are MEF's SD-WAN Specs Enough?

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/

  • Faisal Khan 11/6/2019 | 4:14:48 AM
    Re: Good thoughts Faisal
    @praupadhyaya ! Actually when i say the blackbox. It means it is not clear how vendors are implementing it. I have seen both a manager and a controller as two components as well as combined them into one. Yes the interface between manager and controller to the CPE is not standardized. Openflow can be a good candidate here. PFCP is like openflow but has more specific characteristics to mobile core.
    Faisal Khan 11/6/2019 | 4:08:30 AM
    Re: MEF is just meaningless To some vendors may be it is meaning less as they may not have good service provider presence, but NOT meaningless for Service Providers or  major SD-WAN vendors.

    SD-WAN is essentially a networking application as you need software defined overlays  ( but of course there can be other higher-layer applications on top) therefore the statement that there is no routing or switching component is not entirely correct.
    praupadhyaya 10/29/2019 | 12:20:45 PM
    Good thoughts Faisal So I believe, the main target area would be the interfaces between CPE and Controller on one hand and CPE and Manager on the other.

    Perhaps a beginning point would be a formal definition of control plane interface between CPE and Controller. This could be Open Flow. 3gpp gave up on Open Flow and created its own PFCP (Packet Flow Control Protocol, RFC 29.244) between Control Plane (SMF) and the User Plane Function (UPF) in 5G -- something on similar lines should be taken up by MEF here.
    VPMarket13134 10/27/2019 | 12:36:22 PM
    MEF is just meaningless MED clearly stated their objective is no longer inter vendor interoperability (it will never happen for business reasons). And, What they did define is the “obvious” stuff that is mostly academic. There is in fact no confusion in the buyer as to the expected capabilities of SDWAN and the technical Implementation is straightforward generally speaking. Vendor lock in? Maybe. You got no more lock in when moving from aws to azure or from CHKP to Palo Alto. SDWAN isn’t a router it is an application so it will never be as interoperable as a router or switch.
    Faisal Khan 10/24/2019 | 11:17:54 PM
    Re: Servce vs. technology standards for SD-WAN Correct , the service is standard but technology is a "black box". I am not saying either that it is a scope of MEF. But this area is completely overlooked by everyone else
    Faisal Khan 10/24/2019 | 11:16:17 PM
    Re: Vendor interoperability is not a new problem In the Hardware defined world , it  is not that bad............a router and switch of one vendor can talk to the other very well.....SD-WAN CPE at the end of the day is either a router or a switch... Are we going to a better networking world ?
    udunuwara 10/24/2019 | 6:23:51 AM
    Servce vs. technology standards for SD-WAN On SD-WAN, you are right. While the SD-WAN services are standardized, the technologies are not and it's not the scope of MEF I guess. But someone has to do it.
    udunuwara 10/24/2019 | 6:22:04 AM
    Vendor interoperability is not a new problem The problem of vendor interoperability is not a new issue in the industry. Not only in Software Defined world, in the Hardware Defined world also have you very limited possibilities to interoperate. Ex:- Interoperability of vendors in PON OLTs and ONTs.

    Vendors are also doing a business and none of them want to lose the top or bottom lines. There's huge misalignment with what open source communities propose and what vendors willing to adopt. It's far from reality that we use all open source hardware (ex:- OCP white boxes) and open source software with minimal vendor intervention. Operator skills and knowledge is the challenge here. Vendors capitalize on this and as the industry move from hardware to software, realizing the challenge of maintaining hardware profit margins, and now even the software profit margins, vendors move to SI and services space.

    sohailfujitsu 10/23/2019 | 1:50:17 PM
    Yes this is an issue with SD-WAN I think the industry on SD-WAN has moved so fast, that they have completely overlooked these important standads. I wonder when ONF can standadize the southbound as openflow for SDN,  whats stopping them from extending them to the hot technilogy such as  SD-WAN. The principles should be same...
    Asayyed 10/22/2019 | 2:44:44 PM
    Totally agree I totally agree with you, implementation part was also missing during SDN Congress for this year 2019 in NL. Which is a very important part to help the end user or operator to have such a technology in their network.
    Sign In