Is It Time for Open Source SD-WAN?

One of the recent SDxCentral posts by Ali Longwell covers the state and need for open-source SD-WAN, providing an interesting read and a great 360 view on the various aspects in which we can consider the need for open-source in the context of SD-WAN, namely:

• Open source as a DIY alternative to closed SD-WAN: whether there is a need for an open-source SD-WAN as an alternative to the current mostly proprietary SD-WAN? This argues that while such a need may exist, the timing of it may be coupled years away.
• Open Standard vs Open Source: which of them will come sooner- is there a need for an entire open-source stack or just an open standard to provide an open abstraction?
• Enterprise vs CSP’s need for open source:  Enterprise needs more of an end to end solution vs CSP’s that needs better flexibility.
• Using Open Source Components to build a more open SD-WAN solution.

The general opinion is that there is no reason to prevent SD-WAN solutions being built on top of open source components:

“Yet, before the standard, open source has started to infiltrate the technology as a number of vendors are currently using open source components — mainly orchestrators and security features — in their SD-WAN services.”

This is becoming a hot topic- recently covered in a Cloudify post, describing the need for open SD-WAN orchestration and how it can augment existing SD-WAN solutions including Fortinet, Nokia Nuage and VeloCloud as well as serve as a foundation for a fully open SD-WAN solution:

“Cloudify has also begun building an open virtual CPE (vCPE) and SD-WAN platform that will provide an automated way to access a number of SD-WAN use cases through its orchestration.””

Interestingly enough over the past year, there have been three projects presented at MEF 18 that resonate here:

• Fortinet: collaboration project with TCS and extending ever since.
• Amartus: Cloud Native SD-WAN, in collaboration with Sparkle, covered during our recent Cloudify 4.6 launch.
• Enea, Datavision, and partners demonstrating uCPE and SD-WAN reference solution

We are expecting to see more growth in this domain this year as well.

Open uCPE on top of SD-WAN

One of the areas in which there is a concrete need to add more openness into the current SD-WAN solution stack is at the edge of the network. Why? Disaggregation of the stack – i.e. separation of the network service from the hardware in which it will be running – this allows more selection of hardware devices at the CPE. Another argument for a more open approach to SD-WAN solution stack? Best of breed network VNF- allowing chaining of multiple network services (mostly security services) at the edge without being tied to a specific vendor. Also it’s important to note that the ‘Kontron’ solution as uCPE and SD-WAN, presented at MEF 2018, is now fully matured, running in production with the following architecture.

Looking into the Future – Application Driven SD-WAN (SD-WAN as code)

Most of the current SD-WAN solutions were built on the premise of taking the existing MPLS architecture and providing an overlay network to simplify the process of setting up multi-branch connectivity. This approach assumes that this process is driven by IT network operations. As such it put a lot of emphasise on a self-service portal and flashy UI. This means that the process of setting up SD-WAN here assumes that there is still a high degree of manual intervention.

The next generation SD-WAN is going to be vastly different as the entire SD-WAN network is going to be more cloud-centric. As with any other cloud service, it is expected to become more application-driven than IT-driven. The process of setting up SD-WAN will be fully automated, thus shifting focus from having a flashy UI that is essentially front-end IT to a rich set of API and automation capabilities that is serving developers and applications (DevOps). The current approach of exposing all possible configuration nobs through API exposes high complexity for most average developers. It also exposes vulnerability as it is more error-prone and open-ended.

Intent-based abstraction allows a more policy-driven approach that simplifies the automation process by providing a set of pre-canned automation follows that are a lot more intuitive than having to break each flow into its automatic parts.

Intent-based orchestration defined

With this approach, we can significantly simplify the automation process of our SD-WAN network. For example, we can add/remove branches, update an existing branch site, add/remove/configure CPE, auto-scale to add more capacity as needed.

To Summarise…

The SDxCentral article provides a great perspective on the current state of the union as it relates to Open Source in the context of SD-WAN.

What needs explaining and expanding is the effect of the cloud-centric SD-WAN move which will change many aspects of the SD-WAN experience as we know it today.
The move to cloud-centric SD-WAN should go hand in hand with the move to open-source as we have already seen with many other cloud services such as Compute and Storate. This should in turn drive faster adoption of open-source in this domain.  We don’t see standard SD-WAN reaching a maturity level that could keep up with the speed in which SD-WAN is evolving, nor should we expect many DIY types of SD-WAN popping up.  A key take away is the importance of intent-based abstraction – and how it seems to be  low hanging fruit.