The future of network automation & orchestration

This post was originally published Aug 11 on Sebastian Grabski’s blog Orchestrated Things

Networks as we know them, are going to stay like that for quite some time”

Once in a while, networking world is being shaken by the new “shiny object” which supposed to solve networking pains and make its operation silly stupid. The most modern “shiny objects” are having a shape of a controller. As such, we have seen the rise of SDN controllers based on the promise of network programmability coming from OpenFlow. Very smart idea, however the reality have verified its promises. Next, we have seen MPLS based SDN controllers – much more scalable and mature. In parallel, have have seen the rise of programmable data center fabrics – where multiple DC switches can be seen as a one and be programmable from one place. The recent innovation is SD-WAN, which is storming the market with very cool programmability of VPN’s which we know for years.

Watch our upcoming Edge Computing webinar with Mirantis!     Register Now

What’s the fuss then, and what it has to do with network automation?



The common denominator for all of them is an island, which oftentimes we call a domain. As a result we have an islands of better or worse programmability. Within an island, things are easy. Usually you have a controller, where from single place you can build network constructs, create connectivity patterns and enable policies. But reality is that the real network, when we look at it holistically, it’s not a single island. It is a combination of many islands.

Let’s assume that we have a VM inside data center which is controlled by DC fabric. Inside DC we can build connectivity patterns easily, but what happens when you need to get outside of a datacenter? Many VM’s have a need to communicate with Interne or OSS network for monitoring. Usually it requires an access to the outside world from DC perspective. This “outside world” usually is implemented with MPLS. At the edge of DC we have PE router which servers as a gateway for a DC. Some DC fabrics are smart enough to configure it, some are not. In reality, we need to connect two islands somehow. Is that all? Likely not, as oftentimes organizations are having multiple DC fabrics (read multiple islands) – some built with same, proprietary technology, some are built with different. Going further. What if company is using SD-WAN to connect two DC fabrics or company resources in general? We need to connect with yet another island, which is SD-WAN.

Summarizing, the real networks are a combination of “programmability islands” and connectivity between these islands are going to stay. This is most fragile element of network programmability for various reasons.

Organizational challenge

In real life, domains are managed by different groups and organizations. This means, that in order to create connectivity between two domains, you need to have a process that facilitates handshake between groups (IP addresses, VRF’s, VLANs etc…). This takes time and effort. It’s not uncommon to see such handshake taking few weeks.

Technical challenge

Another challenge is proper tooling. Every domain usually have own controller and within domain provisioning is smooth but when we need to get out of a domain, we need to provision bit of the additional infrastructure (routers, switches). Many existing tools out there, are very device centric. If you take an Ansible for instance, it can automate nicely configuration but on a single node. If you need to connect two or three nodes and create topology & dependencies – Ansible or Terraform are coming bit short short.


Let’s assume that we’re able to address organizational challenges with processes and let’s focus on a technical challenge. The solution for cross domain network stitching requires proper orchestration that can properly model network topology. TOSCA seem to fit perfectly well into that picture. It’s grammar is based on concept of nodes and relationships which directly can translate to network topology constructs. With TOSCA, we can model “logical wire” which is network service composition represented by TOSCA nodes and relationships.



On the above picture we can see the model of “logical wire” with sample implementation where “Openstack NET” is connected to “GW”, then “GW” is connected to “RTR” and “RTR” is connected to VRF. This model defined in TOSCA is later on consumed by orchestrator which implements it. I’m planning more detailed blog on how to leverage TOSCA for building “logical network wire” presenting sample TOSCA based templates. Stay tuned for more if you’re interested

In general TOSCA is allowing to define networks in declarative way. If you’re interested how declarative networking with TOSCA works – please take a look at this blogs post:


Networks as we know it are going to stay for quite some time. We’re going to see new or refreshed technologies which in a smart way are going to make network more programmable but I do not see this addressing complete network environment. There are movements and initiatives to make networks “cloud native” – use cloud patterns & technologies to make it more agile. This seem feasible for network control plane, however for the data plane it’s not that easy. The nature of the beast is that “network islands” are going to stay for quite some time. It’s the nature of the beast and the only way to address it in short to mid term is proper service composition & orchestration in order to make it more automatic.

Leave a Reply