Provisioning and Orchestrating MPLS Layer 3 VPNs With Cloudify

This article was originally published by Sebastian on June 4th on his blog, Orchestrated Things.

“…can Cloudify be used for MPLS L3 VPN provisioning? Hell YES !!!”
MPLS L3 VPNs are present on the market for quite some time. One may think, that is it long enough to consider them as “traditional” VPN technology. It is even more true these days in the era of widespread hype of SD-WAN. I still remember my good old days of OSS consulting (roughly 10 years ago) where many SP’s and telcos were seeking for some handy tools to facilitate MPLS VPN provisioning. Some of them ended up with monster, heavy provisioning systems, some with home grown tools …and yet it seem that some still didn’t figure how to automate it in a decent way on budget. Why? Because I’m still getting questions whether Cloudify can orchestrate MPLS L3 VPN’s and the answer is: “Hell yes!!!”. Cloudify is TOSCA based driven orchestrator and MPLS L3 VPN is a poster example of fantastic, topology based service provisioning.

Read the Multi-Layer Cross-Domain Service Orchestration Whitepaper   DOWNLOAD NOW

Recently, I accepted a challenge and I’ve prepared very simple demonstration how Cloudify can be used to orchestrate L3 VPN’s. In order to demonstrate how Cloudify can model MPLS L3 VPNs, I decided to pick reasonably complicated use case and I ended up with “fiveguys” and “tacobell” VPN’s between two PE routers:

Actual MPLS L3 VPN configuration is outside of the scope of this document. You can find it in any “MPLS configuration guide”. In my case I was using Cisco IOSv devices running on Cisco VIRL.  What I’d like to focus on is service modeling. There’s dozen of ways how L3 VPNs can be orchestrated. It depends on many things: context, telco requirements, BSS systems. Some of telcos will seek for more granularity, where others will prefer more rigid models. Actually, any of them is possible for Cloudify. Cloudify role is to orchestrate “the actions” and “an action” can be anything: from VRF provisioning up to BGP peering configuration.
In my example I decided to build models around following steps:
Step1: provision VRF on PE
Step2: attach an interface to VRF
Step3: set access interface speed
Why I decided to structure it this way? Because this is what telco operator will do:

• needs to find and pick PE’s
• needs to pick access ports
• set purchased speed

Every step is represented by blueprint (model) and in order to instantiate it, we need to create deployment. Deployment is a combination of blueprint + input parameters. Here are sample parameters for “fiveguys” VPN:

Complete walkthrough on Youtube

[embedyt] https://www.youtube.com/watch?v=W2EjNLy4wfk[/embedyt]

I’d like to point out in here, that Cloudify is a generic purpose TOSCA based orchestrator and as such, it has generic user interface. It supports many use cases ranging from devops CI/CD pipelines, applications through NFV use cases. Some may say that it is bit suboptimal to use Cloudify for L3VPN configuration the way it was demonstrated and I agree with this observation. What I’ll do in a production system, I’ll design UI where we can pick from topology map or drop down menus relevant PE’s and access interfaces – and this nice web form from will produce to me an input for orchestration which we’ll submit to Cloudify to provision. This is exactly what Cloudify does: it orchestrate things 🙂
Back to modeling. I mentioned before, that there’s number of ways in which we can design a service. In order to demonstrate flexibility of Cloudify, I’ve prepared one extra blueprint, which is leveraging deployment proxy where complete “VPN leg” (VRF, access, speed) can be configured in one step. It’s not covered in a recording but you can easily guess what’s going to happen when you see the blueprint.
Summarizing, can Cloudify be used for MPLS L3 VPN provisioning – the answer is “hell YES!!!” 🙂