The Path to Network Automation
Automating transport network operations is fundamental to building the fully automated network of the future. CSPs have shown a strong preference for building up this automation through a set of well-prioritized, bottom-up steps. These steps include both simplifying network infrastructure operations (sometimes referred to as resource-facing automation) and (at a different level) simplifying customer-facing service offerings (sometimes referred to as subscriber-facing automation). In this blog we focus on the path to network infrastructure automation, built on the research we have recently conducted about service providers’ initiatives toward those goals.
ACG analysts Paul Parker-Johnson and Mark Mortensen recently had the opportunity to expand on our research into network automation with an in-depth survey of CSPs' priorities pursuing it.Infinera sponsored the research, which focused on automating transport network infrastructures. The goal was to engage in-depth with CSP practitioners that are working directly on (in most cases leading) their transport network automation initiatives. The survey’s findings made a strong addition to the knowledge of CSPs’ network (and business) automation initiatives and suppliers’ offerings to support them that we have been studying in our Domain Control and Orchestration research stream.
CSPs’ preferred paths for automating their network operations are evolving along a clear and structured path. Here are several of the important highlights of those paths:
The Path to Network Automation
CSPs are working to increase the scope of their infrastructure automation mostly from the bottom-up, within a technology and a workgroup, and then hooking these islands of automation together in a variety of ways. Generally, the work in this bottom-up construct is organized into efforts making progress in a clearly scoped set of solution spaces:
Domain Automation: Work in this space is focused on automation of provisioning and service assurance within a particular technology and geographic/organizational boundary. This level of automation is usually based on applications and playbooks input into Robotic Process Automation engines of various types. CSPs are focused on solutions that support standard protocols and data models but also show a strong preference for automation at this level to be provided by the infrastructure element provider (for example, physical network element manufacturer or virtualized network element developer), since they know their areas well. They are skeptical of vendors that claim to provide excellent support for all vendors’ network elements in a domain, though they are pragmatic about determining how they can simplify operations in a multivendor context. Sometimes, they will work closely with a dominant vendor they have chosen for a domain in creating a solution that supports their (often limited) multivendor requirements in that domain.
Horizontal Cross-Domain Orchestration: In this space, operations teams need to support the same technology layer (for example, optical or packet) but across different geographical and topological areas (for example, access vs. metro vs. long haul). This is a cross-domain problem that requires both workgroup and solution integration and interoperability. CSPs highly value this type of cross-domain automation, especially with network topologies expanding in this manner as new access and cloud interconnect requirements emerge (for example, in 5G, distributed broadband access, and cloud provider interconnect).
Vertical Cross-Domain Orchestration: In transport network operations, there are often large gaps in organization and technologies used between teams working on differing layers of deployment (for example, the optical and the packet transport layers or the packet and the virtual network functions layer). CSPs want greater automation of the interaction of these technology layers and the teams supporting them. This is a high priority moving forward in both technology integration and organizational coordination. Although important, it is challenging to pursue, as it is hard to find people with a mastery of each of the related skills, and a requirement is to find solution suppliers that can bridge the same gaps in integration as well. Making step-wise progress on both the teaming, skills, and the technological integrations needed in these portions of the infrastructure is a goal stakeholders will be working on earnestly over the coming several years.
End-to-End Cross Domain Orchestration: CSPs view vendors that are pushing for end-to-end orchestration of the entire network as being early stage in their developments, believing it will take a long time. Many CSPs look to their own IT shops (with or without using open source solutions) or independent software vendors for these capabilities since it is inherently multivendor and tends to work at a layer above automation in the individual domains.
The Automation Touchstones: Standards, Practicality, Partnerships
Standards: CSPs view emerging YANG models, NETCONF interfaces, and gRPC telemetry as critical in implementing network automation. They highly value network resources and software systems that adhere to these standards and have a proven track record of working with other vendors’ offerings on the other side of the interface.
Practical Approach: CSPs show that they are approaching network automation in very bottoms-up way with multiple practical projects, depending much less on large, vision-driven programs.
- Priorities: CSPs set their priorities according to simple algorithms and straightforward goals: activities that happen very often and are mostly rote are first on the priority list (hence, these are very amenable to simple automation via RPA technology).
- Implementation: Although CSPs like the simplicity of suites of applications that support domain and interdomain automation needs, they often need to replace one or more of the applications in the suite with another one that is already in widescale use. Thus working with decomposable suites is preferred.
- Computing platform: Although hybrid cloud is the preferred infrastructure for the automation software, they are open to a variety of arrangements (hosting applications in a public cloud when that will meet their requirements, for example).
- Use of open source: CSPs view the use of open-source components neutrally, considering them pragmatically as to whether they help solve a problem they have reliably and economically. On its own, open source as a category of solution offering is not considered positively or negatively.
- Offerings: CSPs are open to traditional licenses plus maintenance agreements as well as managed services, subscription-based offerings, and SaaS.
- Partnerships: CSPs believe that the best solutions involve the cooperation of their own network engineers and IT personnel working with the vendors. Few desire turnkey solutions, nor do-it-themselves toolkits.
We as an industry (and we, too!) are profoundly motivated by the benefits achievable with more fully automated operations. We are inspired by what web-scalers have been able to accomplish. We see great potential in the virtualization of network resources as they become more amenable to software control. When coupled with a new generation of software models, including cloud-native microservices, robust data models, machine learning and artificial intelligence, we can do things that could not be done before. All these fuel the opportunity to automate network operations more completely since the software and computing resources are inexpensive enough and sophisticated enough to do it. We cannot forget that when it comes time to actually implement these solutions, it will take both vision and a complex series of practical, nitty-gritty projects to make progress toward the goal of a fully automated network.
Click to read the results of the Service Provider Directions in Networ Automation, A 2020 Survey Report.