Global
With networks becoming ever more critical to business success, most IT and network managers have become painfully aware that legacy manual processes are a speed bump in delivering new services promptly that executives expect. They also know that application and server teams, empowered by automation, are spinning up new business services in minutes or even seconds, while network teams can take days or weeks to make the changes required to deliver the services to employees, partners, and customers.
Automation tools are currently available to the network teams as well. Even so, most network teams still use legacy techniques and tools, manual processes, ping sweeps, freeware scanning tools, spreadsheets, databases, Visio diagrams, printed regulations, policies stored in ring binders, and vendor-specific tools that only work for a subset of the devices deployed.
If these antiquated techniques are causing the delivery of network services to lag the delivery of applications and servers, why are they still in use, especially since automated alternatives are available? Perhaps it is because they’ve been used for decades as inefficient as they are, and they work as long as you have enough time, staff, and expertise. Too often, network teams are swamped with day-to-day requirements and focus on just keeping their heads above water instead of seeing what can be done to improve the situation.
Nonetheless, networks are increasing in complexity and capacity, as well as the density of the services upon them. Uptime, reliability, and predictable latency requirements drive the need for automation. The problems with network management are rather complex and intricate. But these problems must be solved to meet the stability needs of existing services.
What is the Problem with Manual Processes?
Network management teams are facing unprecedented change as Managed Service Providers (MSPs) and Internet Service Providers (ISPs) are digitizing their processes worldwide. Digitization is critical for organizations to reduce operational expenditure and take user experiences to unparalleled levels. In the telecom and networking industries, using rudimentary text editors for managing snippets of network configuration is a norm, and such practices have adverse effects on business processes.
Manual Configuration Problems
Human error regularly leads to network outages and ongoing delays. Because CLIs (Command Line Interfaces) require specialized skills, they limit the number of networking staff that can make changes, which is inefficient and can cause a single point of failure in the change process. Since CLI requires touching devices manually, the risk of human error, such as transposing characters on the keyboard or messing up a copy-and-paste function from a separate spreadsheet, is significantly increased.
Excessive Operational Expenditure (OpEx)
Repetitive network changes and activations create unnecessary operating expenses.
Inefficient Processes
Manual configuration management will never harvest the benefits of an automated solution. The core of the challenge is that the traditional network operation processes are focused on internal processes and are not based on customer-driven requests. It can be contrasted with the common situation with a native configuration system on the device. For each variable added to the device, we must create a web UI for it manually, and we then have to re-implement this in the front-end application.
As a result, for every new feature added to the device, the front end will need to be updated to provide a UI to configure it. It takes resources and creates a situation where the front-end is always ‘behind’ the device, and the customer needs to upgrade the device and the front-end to configure the latest features. This problem will worsen as we add more products under front-end management. For every new product, we would need to create a new UI for that product’s configuration mechanism.
To meet this challenge, SPs are looking to update their technology platforms to deliver services in an efficient manner and enhance customer responsiveness.
Network Config Changes Without Using Established Processes
Ideally, all changes should go through a change-management process and be fully documented. In the real world, changes are often made outside the process and are missing documentation. It adds security risks, increases compliance violations, and lengthens the time necessary to troubleshoot network issues. If you don’t know a change happened, how do you document it?
Solution: YANG-Based Network Configuration Management
YANG (Yet Another Next Generation) is a Data Modeling Language widely used to configure network devices. YANG has good tooling support like auto-generated code, REST APIs, Web User Interfaces, etc. YANG was developed by the IETF NETCONF Data Modeling Language Working Group (NETMOD) to be easily read by humans. Also, Cisco, Juniper, and Ericsson support NETCONF and YANG.
Device Configuration Using YANG
One of the most important benefits of using YANG is the possibility of generating a UI from the data model automatically. A UI framework that can take a data model and generate a UI from it will provide substantial resource savings.
We can efficiently add support for new products and features if we have a YANG data model for each component and have the front end automatically generate a UI based on the YANG model. The new device under management would be expected to provide a YANG data model. The front end would upload the data model when contacting the device to ensure it uses the correct version of the data model for the device in question. A UI would be automatically generated, and the customer could configure the device. It would also allow us to provide configuration abilities for the third-party network functions, or even the third-party hardware devices, if these support NETCONF/YANG.
Operational Advantages of the Yang Model
YANG is a significantly refined data modeling language that allows the definition of constraints and separation of configuration and state elements. Unlike SNMP, NETCONF supports atomic transactions for a configuration change.
NETCONF/YANG offers a wide range of specific benefits, including, but not limited to:
- YANG has been widely adopted by key standards bodies (such as IETF and ONF) to produce a broad range of rich YANG models
- YANG models both the configuration and state of key layers of the network
- Proprietary extensions are required less frequently, resulting in easier multi-vendor interoperability
- Enables automated operation and policies
- Enables rich integration with OSS and other SDN controllers
- Provides a solid foundation for automation and SDN
Business Benefits of the NETCONF/YANG Model
The primary benefits of a NETCONF/YANG device management approach are programmability and interoperability.
Programmability: The structured description of all managed objects in the device through the YANG model and the structured set of methods for managed object exchange provided by NETCONF are the building blocks for programmability and automation.
Interoperability: Using the NETCONF/YANG standard provides interoperability, leading to flexibility in the choices of devices and device types and management solutions. Using standard YANG models can save development time and ensure that devices with a common feature set can present the same set of managed objects, simplifying a managing entity’s challenge when managing multi-vendor networks.
High Availability: A NETCONF/YANG solution provides high availability benefits. The YANG model is a contract that defines how the managing entity configures and monitors the device and how the device responds, reducing mistakes due to misunderstanding. Validation of configuration changes against the model can prevent malformed/inconsistent changes from being applied, and validation catches/prevents mistakes. Further validation can be applied within the device based on the current state of the device.
Stability: Using robust transactions eliminates the inconsistent outcomes due to some changes working and some not working within a given set of changes. A clean transaction rollback can quickly and safely restore stability and availability for completed transactions that result in unexpected behavior such as instability or degraded service.
Ness’s Solution
Session Border Controller (SBC) Flex UI Generator (FUG)
Instead of a custom UI implementation, it would be ideal if YANG models could be used to generate UI and backend code. With this approach, features in the future requiring new configuration options would not result in a proportional UI and backend effort – most of that code would be generated from the modified YANG models. Our solution proposes an automated UI component generator, and we have named it Session Border Controller (SBC) Flex UI Generator (FUG).
Ness Approach
Ness adopted a two-pronged approach of devising a vendor-agnostic solution that brings in automation in the overall scheme of things.
Vendor Agnostic
A limited set of configuration templates is not good enough. Every business should have complete control over the configuration they wish to generate. Since a customer may deal with multiple vendors, a mechanism should empower them to achieve a dynamically generated GUI. FUG enables such users to have this GUI, which is vendor neutral.
Automatability
FUG generates configuration through a REST API. It allows enterprises to fully digitize their configuration processes through integration with other IT systems, including Orchestrators, Policy Managers, CRM platforms, and much more.
Solution Architecture
The solution devised by Ness primarily consists of Network Inventory, YANG model translator, and SBC Flex UI Generator, as shown in the block diagram below.
Network Inventory
The product will require knowledge of network infrastructure. The data should be sourced from a dynamic inventory source for a scalable solution to avoid manual management. FUG is agnostic to the inventory source chosen by users.
Configuration Daemon (ConfD)
The goal is to have a centralized configuration daemon that accepts NETCONF configuration input and applies it to each application. This approach will alleviate the problem we have on VOS, where each configuration mechanism manipulates the configuration files directly. The WebUI, SNMP, BroadWorks Device Manager, et al., must implement the configuration setting logic and input validation. The enormous re-implementation effort makes it impossible to add new configuration mechanisms. With YANG, we should be able to use the data model to drive the interface.
YANG Model Translator
Since any UI component generator cannot translate the YANG Models directly, transforming them to a required format becomes essential. A translator can validate YANG modules for correctness, transform YANG modules into other formats, and generate code from the modules. Several tools are available for this purpose, and pyang is one such tool.
The translator can further be utilized to provide the JSON Schemas using REST APIs. The frontend framework will invoke these REST APIs to generate UI components dynamically.
SBC Flex UI Generator
The SBC Flex UI component generator will be responsible for creating the UI form at runtime, based on the received JSON schema from the REST API call. It will take this schema as input and generate UI elements logically on the fly. For example, for enums, it will create a dropdown, a textbox for string, a range selector for numbers, and checkboxes for Booleans.
And to achieve this, we must not hard code such things. Instead, we can make use of existing solutions that are more flexible and scalable. Angular JSON Schema Form (AJSF) is one such package.
Below is a fundamental sample of a YANG model. It is translated JSON Schema and the form generation.
References
- Data Model-Driven Management – https://www.informit.com/articles/article.aspx?p=2979064&seqNum=4
- Pyang – https://github.com/mbj4668/pyang
- Angular Json Schema Form – https://github.com/hamzahamidi/ajsf/tree/angular6-json-schema-form
- UltraConfig – https://ultraconfig.com.au/docs/
- InfoBlox – https://www.infoblox.com/wp-content/uploads/infoblox-whitepaper-time-automate-network-change-configuration-processes.pdf
Abbreviations
- CLI: Command Line Interface
- FUG: Flex UI Generator
- IETF: Internet Engineering Task Force
- NETCONF: Network Configuration
- NETMOD: Network Modelling
- ONF: Open Networking Foundation
- OSS: Operations Support Systems
- SBC: Session Border Controller
- SDN: Software Defined Network
- SNMP: Simple Network Management Protocol
- YANG: Yet Another Next Generation
