on Posted on Reading Time: 5 minutes
At the MEF 3.0 PoC Showcase in Q1 2021, Cisco, Equinix and ngena demonstrated a MEF-standard SD-WAN service using open source Cloud Native SD-WAN. The showcase illustrated how, thanks to Cloud Native SD-WAN, Cisco SD-WAN services managed by ngena automatically provide per-application WAN optimization to a cloud-based Kubernetes cluster, connected via Equinix Cloud Exchange.
This blog post provides a selection of questions and answers resulting from the MEF 3.0 PoC (136) showcase. (They have been edited for clarity.) A recording of the entire showcase is available on demand. Our thanks to the following who provided the answers: Alberto Rodriguez-Natal (Cisco); Charles Eckel (Cisco); Erik Radvon (ngena); and Tom Yin (Equinix).
Q1: What prevents a DevOps engineer from configuring all of their apps to receive high priority in the application directory to gain an unfair advantage over other applications (e.g., classifying them all as video)?
A1: Despite the fact that DevOps engineers can assign any metadata to their applications, the mapping of that metadata to SD-WAN policies is still in the hands of the NetOps team. That means that, in a general scenario, DevOps doesn’t configure its applications as ‘high priority’ but rather as “web” or “video,” then NetOps are the ones that decide which SD-WAN policies are going to apply to “web” or “video.”
It is in the interest of DevOps to use the application metadata following NetOps’ guidelines, so that they can leverage NetOps’ knowledge of the network conditions and configured SD-WAN policies. As an example, at a particular point in time, NetOps might decide to update the policies that apply to applications labelled as “web” in order to deliver a better experience for web traffic. However, if web applications were incorrectly labelled (expecting better network treatment) they might miss these optimizations.
Q2: How does the MEF 70 standard help you to implement this PoC?
A2: MEF 70 is the MEF SD-WAN service standard. A planned update is nearing completion, known as MEF W70.1. (The “W” indicates that it is a work in progress rather than a published standard.) Work on MEF W70.2 will start once MEF 70.1 is published.
MEF realizes SD-WAN standards are needed today and will need to advance and evolve over time as SD-WAN services continue to become more advanced over time. This iterative approach to standards aligns very well with the needs and practices of the Kubernetes community, where we see continuous improvements to the code and subsequent releases over time.
These MEF standards play a critical role in MEF 3.0 PoC (136). We have an adapter in the Cloud Native SD-WAN project that makes it work with Cisco SD-WAN, but, thanks to MEF standards, any other implementation that is capable of supporting MEF SD-WAN services will work as well. Not only that, but, when you bring different communities together as we have with Cloud Native SD-WAN, it is extremely helpful to speak the same language. The MEF SD-WAN standards give us that common definition, or a common language if you will, when talking about SD-WAN services.
Q3: Is Cloud Native SD-WAN different from what we are doing now in terms of application traffic classification and dynamic routing? Will DevOps programmatically re-allocate priority network capacity? If so, how far away are we from this?
A3: Cloud Native SD-WAN improves existing SD-WAN solutions by enabling the delivery of additional application metadata to the SD-WAN system. Available traffic classification and dynamic routing techniques will still be used and complemented by the Cloud Native SD-WAN-provided metadata.
DevOps will not re-allocate network capacity directly, since the network is still under the control of NetOps. However, depending on the applications DevOps deploys and the metadata applied to them, NetOps might want to apply some changes to the network. For instance, if an application is labelled as “backup” by DevOps, NetOps might establish a policy to automatically put that traffic on a high bandwidth link. Furthermore, if a particular site has multiple “backup” applications, NetOps might consider allocating additional links towards the site that prioritize bandwidth over latency, to better serve “backup” applications.
Q4: What are the challenges in transitioning a team doing traditional networking to one that is suited to administer a programmable-driven network model demonstrated in this PoC?
A4: As with the transition to more declarative and scalable application systems, one of the main challenges when transitioning to a programmable-driven network model is to make sure that the right interfaces (i.e. APIs) are in place:
- First, the right APIs towards the network, so the programmable-driven model serves as enablement to the team and not the other way around.
- Second, APIs within the teams themselves—so that, as they become more decomposed and modular, the right communication is still in place.
MEF standardization can help with the former by defining appropriate network APIs (e.g. to request SD-WAN services). And, approaches like Cloud Native SD-WAN help with the latter by making sure that the right semantics are in place to dynamically exchange information between the teams (i.e. between DevOps and NetOps).
Q5: Is MEF engaging the Kubernetes community and how receptive is the community to this approach?
A5: MEF 3.0 PoC (136) is a fantastic example of standards and open source working together and benefiting both communities. Cloud Native SD-WAN has been featured at KubeCon on multiple occasions. In addition to KubeCon, Cloud Native SD-WAN and MEF SD-WAN service standards were also represented in this talk, “Optimizing External Kubernetes Traffic with Cloud Native SD-WAN,” at FOSDEM, a huge open source conference run by the open source community for the open source community.
The Kubernetes community knows and appreciates the value of standards, and by taking the concepts of MEF SD-WAN service standards and applying them in the PoC using Cloud Native SD-WAN, we put MEF SD-WAN in the hands of the Kubernetes community and developers in general.
Q6: How important of a role does standardization, such as the SD-WAN standards from MEF, play in making a concept like Cloud Native SD-WAN viable?
A6: MEF standards play a critical role in proof of concept. We have an adapter in the Cloud Native SD-WAN project that makes it work with Cisco SD-WAN, but, thanks to MEF standards, any other implementation that is capable of supporting MEF SD-WAN services will work as well. Not only that, but, when you bring different communities together as we have with Cloud Native SD-WAN, it is extremely helpful to speak the same language. The MEF SD-WAN standards give us that common definition, or a common language if you will, when talking about SD-WAN services.
When it comes to MEF SD-WAN APIs, these do not formally exist today. The API used by the Cloud Native SD-WAN project and supported by Cisco SD-WAN is essentially a candidate, or an example, API. It is extremely valuable and informative in that it illustrates the capabilities the eventual MEF SD-WAN API must support and key requirements of the API. This is a great example of how open source code can inform the definition of a standard, with both communities working together to accelerate the pace of standards and shorten the time to running code that embodies those standards.
Q7: Is it possible to leverage this approach for applications running in on-premises datacenters or at colocation centers?
A7: Absolutely. The solution is agnostic to where the applications reside. In the demo shown during the MEF 3.0 PoC showcase, we hosted the application in a public cloud—the exact same demo could be reproduced by hosting the application in an on-prem datacenter or at a colo. The key point here is that, as long as the application is being served by an SD-WAN, regardless of where the application is actually hosted, the Cloud Native SD-WAN optimization techniques can be applied to improve the application experience over the SD-WAN. However, using the Equinix colos, we were able to quickly enhance the cloud on-ramp performance through private connectivity to the Kubernetes infrastructure instead of using the internet.
Q8: Are non-Kubernetes workloads supported? Does this apply to VMs or apps running on bare metal? What about serverless functions?
A8: Indeed, the way the solution conveys application metadata is by leveraging a service registry. So, as long as the DevOps team can populate the application metadata in the chosen service registry, the rest of the Cloud Native SD-WAN principles will still apply. This population can happen automatically, as shown in the demo, or manually by DevOps. By using the right application APIs for each case, automatic or manual population of application metadata can be done for VMs, bare metal, or serverless applications, just as it is done for Kubernetes applications.
Q9: The PoC leverages SD-WAN as a Service from ngena’s platform. What level of customization is required to configure CPEs and Internet links in order to support a proposed Cloud Native SD-WAN design in the way shown?
A9: Because ngena has already abstracted the various components of networking infrastructure in its service platform, including everything from edge hardware devices, software licensing, as well as private connectivity to Equinix cloud on-ramp backbone and internet links, there are no obstacles or delayed “project-type” customizations needed.
The ngena SD-WAN as a Service platform is already leveraging automation to make customizing the network and orchestrating resources simple and fast for NetOps, including for the type of deployment outlined in this POC.
Learn More
Read more about: MEF 3.0 PoC (136) MEF SD-WAN Service Provided Using Cloud Native SD-WAN
This PoC was presented at the MEF PoC Showcase in Q1 2021. Watch the Presentations on YouTube
About MEF’s PoC Program & Showcase
The MEF 3.0 Proof of Concept program effectively fosters innovation, seeds new MEF standards and projects, and accelerates our existing work within the ICT industry by providing our members—including service providers, technology suppliers, and other stakeholders within the ICT industry—the opportunity to collaborate on MEF 3.0-based use cases throughout the year.
Initiated by MEF members and facilitated by MEF staff, each MEF 3.0 PoC receives a unique, identifying number that remains unchanged as its title and messaging evolves over the life of the project.
PoC work is highlighted in public showcases and award presentations that explore individual Proofs of Concept. Learn more about these enabling technologies and the MEF 3.0 PoC Program.
Related PoC (136) Blog Posts:
- SD-WAN in the Age of Kubernetes and the Cloud Native SD-WAN Project: Highlights from MEF 3.0 PoC Showcase 2021
- Cisco blog post: Cloud-Native SD-WAN: The WAN Your Kubernetes Applications Deserve
About MEF’s PoC Program & Showcase
The MEF 3.0 Proof of Concept program effectively fosters innovation, seeds new MEF standards and projects, and accelerates our existing work within the ICT industry by providing our members—including service providers, technology suppliers, and other stakeholders within the ICT industry—the opportunity to collaborate on MEF 3.0-based use cases throughout the year.
Initiated by MEF members and facilitated by MEF staff, each MEF 3.0 PoC receives a unique, identifying number that remains unchanged as its title and messaging evolves over the life of the project.
PoC work is highlighted in public showcases and award presentations that explore individual Proofs of Concept. Learn more about these enabling technologies and the MEF 3.0 PoC Program.
