Network Orchestration and Visibility for Managed SD-WAN

The great conductor and composer Leonard Bernstein said: “To achieve great things, two things are needed: a plan and not quite enough time.” And he must have known a thing or two about orchestrating. That quote certainly rings true in networking today, as enterprises implement SD-WAN under the intense time pressure that is common in IT these days. And that leads us to automation and orchestration, which are closely interlinked.

Automation

Automation of course is a top priority in IT these days. But what do we mean by “automation”? Depending on the definition, automation is nothing new in networking.

In networking – which is often seen as a culprit for obsolete, manual configuration – we have used scripting for a very long time. Scripting allows us to greatly speed up device configuration as well as reduce the risk on typing errors when manually working with the CLI. Definition-wise, something like scripting is known in software science as an imperative approach, meaning that you have to know every detail of the underlying layer’s capabilities to interact with it, and do so with utter accuracy – otherwise it is very unforgiving.

But the scope of applicability of scripts is very narrow: they are very device specific and are executed device by device.

Orchestration

Orchestration, on the other hand, is the tool that allows for far more wide-reaching automation. For example, if I want to update an SD-WAN QoS policy globally because I am rolling out a new UCaaS deployment, the way it works for the 2 different automation approaches is as follows:

  1. Scripting: If my network has 50 sites, create 50 slightly different versions of my automation script, resulting in 50 site-specific scripts. Then run them individually. If you think this approach preposterous, consider the fact that it’s not unknown to run several hundred CLI commands if you simply log into every node and configure it manually to change local class of service policies. And then add up the likelihood of configuration mistakes if you run hundreds of manually typed commands on 50 sites. Which is why automation by scripting was far more widely adopted in networking than it ever got credit for.
  2. Orchestration: I simply define an abstracted policy that states my intent for UCaaS, such as: what traffic priority it has and what my optimal breakouts into the UCaaS cloud are. The orchestration tool translates it using what is called a declarative model in software engineering.

A declarative model is very different to an imperative one. In an imperative model, the elements you try to control expose all the complexity to you. Imagine hiring a cab, and instead of just stating your destination and letting the cab driver pick the best route, you direct her turn by turn, without ever revealing your ultimate destination. That would be the imperative model. In a declarative model, you trust the cab driver to understand your “intent” and resolve the underlying complexity in order to get you to your destination with accuracy and speed.

Orchestration is the key tool to deliver on automation and allow networking to offer the operational agility and efficiency that are now common in the cloud-first application world.

It is important to point out that, architecturally, successful orchestration relies on a hierarchy of abstractions that, thus far, the networking world has not quite delivered on. Unless orchestration relies on true abstraction models and trusts the underlying elements to intelligently resolve the abstracted “intent” to the best of their ability, the orchestration model becomes a script, and will inevitably fail to scale.

Visibility

To be effective, orchestration relies on global multi-layer visibility, able to immediately identify any underlying network issues that impact subscriber traffic. With an MPLS overlay across a routed infrastructure, this is an indirect operation, as these elements are often managed by different organizations and visualized with separate tools. In many MPLS deployments, cloud connectivity follows a sub-optimal path, often backhauled all the way to an organization’s HQ or data center. Compartmentalized visibility is the underlying issue and prevents orchestration tools to optimally resolve business-level intent.

Integrated visibility enables rock-solid performance guarantees. Monitoring must also include visibility into all applications that are in use and how they compete for network resources. That way optimization rules can be orchestrated in the most effective way.

A Look Ahead

With consolidated visibility and effective orchestration based on abstractions, we will deliver on the promise of intent-based networking.

A this point, the key question that is always asked is whether abstractions models are driven by standards, as we’re seeing now -at least partially- with certain emerging models like NETCONF-YANG and others, or whether -as often in the application world these days- they are simply driven by de-facto industry standards (think of Kubernetes for container orchestration, for example). And the simple answer is that…only time will tell!

 

 

Author's Bio

Paul Liesenberg

Paul Liesenberg

Senior Product Manager, Aryaka

Paul is a Senior Manager in Aryaka’s Product Marketing Team. Paul has over 20 years of experience in product marketing, product management, sales engineering, business development and software engineering in Cisco, LiveAction, Bivio Networks and StrataCom. Paul enjoys scuba diving, motorcycles, open software projects and oil painting.