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”

Every once in a while, the networking world is shaken by the new “shiny object” which is supposed to solve networking pains. The most modern “shiny objects” have the shape of a controller. As such, we have seen the rise of SDN controllers that are based on the promise of networking programmability, rooting from OpenFlow. Next, we have seen MPLS based SDN controllers, which are more scalable and mature. Likewise, we have seen the rise of programmable data center fabrics- where multiple DC switches can be viewed as one and are programmable from one place. The recent innovation is SD-WAN, which is storming the market with excellent programmability of VPN’ which we are familiar with. 

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 is also known as a domain. As a result we have islands with better or worse programmability. Within an island, things are simple. Usually you have a controller, whereby, from a single place you can build network constructs, create connectivity patterns and enable policies. But in reality, the real network, when we look at it holistically, is not a single island but rather a combination of many islands.

Let’s assume that we have a VM inside a data center which is controlled by DC fabric. Inside DC we can build connectivity patterns easily, but what happens when you need to leave a datacenter? Many VM’s have a need to communicate with the Internet or OSS network for monitoring. Usually it requires access to the outside world from a DC perspective. This “outside world” is usually implemented with MPLS. At the edge of DC we have a PE router which serves 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? Most likely not, as often, organizations have multiple DC fabrics (read multiple islands) – some built with the same, proprietary technology and some are built with different. Delving deeper, what if a company uses SD-WAN to connect two DC fabrics or company resources in general? We would then need to connect with yet another island, which is SD-WAN.

In summary, the real networks are a combination of “programmability islands” and connectivity between these islands will remain. For various reasons, this is the most fragile element of network programmability. The process of network automation aims to maximise efficiency and functionality.

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 a ‘handshake’ between groups (IP addresses, VRF’s, VLANs etc…). This process takes time and effort,sometimes taking a few weeks. Network Automation automates the security provisioning and management of devices within a network, maximising efficiency and functionality within these organizations. Network Orchestration, an ‘advanced’ version of network automation, automates entire processes as opposed to a single task.

Technical challenge

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

Solution

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

As presented in the image above, we can see the model of the “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 the orchestrator which implements it. I’m planning a more detailed blog on how to leverage TOSCA for building “logical network wire”, whilst also presenting sample TOSCA based templates. Stay tuned for more if interested. 

Generally, TOSCA enables defining networks in a declarative manner. If you’re interested how declarative networking with TOSCA works – please take a look at this blog post

Summary

Networks as we know it will stay for quite some time. We will see new or refreshed technologies which are going to make networks more programmable and network automation and network orchestration tools more accessible. Though I don’t count on this addressing complete network environments. There are movements and initiatives aiming to make networks “cloud native”, using cloud patterns and technologies to make it more agile. This does seem feasible for a network control plane, however for the date plane, it’s not that easy. The nature of the problem is that “network islands” are going to remain for quite some time. It’s the nature of the beast and the only way to address this in the short/mid-term is a proper service composition and network orchestration, to make it more automatic.