Network automation: offering choices now key

Since that time, the approach has not evolved much. But some of the solutions available have, as well as moving past the SDN term towards network automation. So it’s a perfect time to revisit the subject and explore some of options now available for turnkey and open source solutions around network automation.

Options for network automation

Every IT organization is at a different stage of their in-house operational expertise and business requirements to execute and deliver IT services faster. Plus, no two network environments are the same. And it’s almost certain that 90%+ of the IT organizations looking to leverage automation, have a current install base they need to support. This is where the approach of offering various levels of network automation is critical.

Figure 1. The three categories of options for network automation.

The various options available can be aligned into three categories (see figure 1) that give IT organizations the power of choice. While the solutions themselves have evolved, these three categories have not. They are:

◈ Prescriptive “turnkey”

◈ Open source/standard tools and API’s with Cisco hardware/virtual network functions (VNF)

◈ Support for Heterogeneous Hardware/VNF Environments.

Prescriptive “turnkey”

The prescriptive “turnkey” options work best for organizations that have a limited amount of automation and programmability skill sets within the operations teams. Cisco’s offerings in this option have a set of common attributes, such as:

◈ Hiding of complex configurations that are typically done via the CLI

◈ Prescriptive on-boarding of new network elements (plug-n-play, zero-touch-provisioning)

◈ Pre-built GUI application

◈ A controlled fabric domain

◈ Some form of analytics and assurance

◈ And an “under the covers” device/fabric configuration which normal operations (CLI) could take days/weeks to accomplish.

Turnkey solutions typically target Cisco-specific hardware/software to allow the simplification of all of these tasks and offerings. Examples of these solutions include Cisco Software Defined-Access (SDA) with the DNA Center controller, Cisco Software Defined WAN (SD-WAN), Cisco Application Centric Infrastructure (ACI) for on-prem data center build-outs, and in the large enterprise and SP space, the recent Cisco CrossWork framework for closed-loop automation.

Open source/standard tools and VNF

Open source/standard tools and API’s with Cisco hardware/virtual network functions (VNF) can be used by those wanting to use Cisco hardware and/or VNF’s, but who prefer to leverage a more open set of controllers (API’s, SDK’s and open source tool sets and applications).

The typical customer using this approach already embraced a NetDevOps model and “do it yourself” mentality within their IT operations team. Plus, they have the in-house expertise to support it on a daily basis. And they are driving Cisco hardware/VNF’s to offer and support a rich set of standard API’s and overall management stack to allow them to leverage this type of NetDevOps approach.

Figure 2. The Model-Driven Manageability Stack

To support IT operations team using this approach, Cisco has created an open source management protocol stack (see figure 2) in some of its new software releases. This gives do-it-yourself type IT operations the ability to configure and collect valuable telemetry from Cisco hardware/VNF’s via third-party API’s (YANG models) and open protocols to/from the Cisco devices.

Leveraging YANG models

The goal of this model-driven protocol stack is to decouple the protocol, encoding and transport options from one another while leveraging the YANG models for both device configuration and telemetry collection. The result is that any application north of the network element has a consistent protocol stack to leverage for development of applications.

For example, an application written in Python can take advantage of the YANG Development Kit for Python (YDK-py) SDK. It leverages gRPC, with GBP encoding, using either native Cisco YANG models or OpenConfig models for configuration and operations of the Cisco device.

The exact same combination can also be used to stream telemetry from the devices to some collection stack, further simplifying the communication channels required. For customers embracing Cisco hardware/VNF’s, but who prefer developing their own applications to configure/modify the devices and collect telemetry, the model-driven management stack offers those capabilities through open source protocols, encoding and API’s (YANG models).

While there are many other open source tools that fit into this category, Ansible is a highly regarded one in the network operations space. This is because it doesn’t require a device agent to communicate with the device, it’s modules are widely available, it’s open source, and it’s viewed by many as a more readable language.

Heterogeneous hardware/VNF environments

The third option, support for heterogeneous hardware/VNF environments, targets customers like those in option two. They’ve embraced the NetDevOps model and have critical in-house expertise to fully support it. They’re able to leverage the exact same approach and capabilities as option two (if all their vendors can support the management protocol stack offerings).

What differentiates this multi-vendor option is the additional need to support an open standard transport (control and data plane) common to all of the vendors in the network. This could include IPv4/v6 and Multiprotocol Label Switching (MPLS) with multi-protocol BGP (MP-BGP), which has existed in multi-vendor environments for years. More recently, E-VPN/VXLAN in data center and campus fabrics, as well as Segment Routing with a Path Computational Element (PCE), is gaining traction in large service capable backbones.

Empowering network automation

As I discussed in the first blog, offering options similar to those above empowers customers with a variety of approaches as their network operations teams transition to automation.

As with any transformational shift of this scale, there are trade-offs to consider; ones that clearly align with the operational skill set of the organization (specifically the DevOps skills they are capable of injecting into their daily operations).

In the end, offering choices to customers as they move down the path of SDN, automation and programmability is, in my opinion, no longer an option but a necessity. But the choices offered should include common ground for supporting automation in a multi-vendor environment. The key challenge will be aligning the options offered by single or multiple vendors to the business needs of the IT organization. Lastly, if your IT organization is new to automation, don’t attempt to boil the entire ocean. Just focus on automating the day-to-day repeatable processes found in your network operations. By doing that, your organization can more quickly gain value from network automation.