Contact Information

  • AUTHOR Govind Thakur
  • PUBLISHED ON February 10, 2021

YANG Model Driven UI Component Standardization

With networks becoming ever more critical to business success, most of the IT and network managers have become painfully aware that legacy manual processes are a speed bump in delivering new services in the timely manner 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 behind the delivery of applications and servers, why are they still in use especially since automated alternatives are available? Perhaps it is because, as inefficient as they are, they’ve been used for decades and they work, more or less, 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.

 

But 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 all around the world. Digitization is critical for organizations to reduce operational expenditure, and take user experiences to unparalleled levels. In the telecom and networking industries, use of rudimentary text editors for managing snippets of network configuration is a norm. There are adverse effects of such practices 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 greatly 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. This can be contrasted with the common situation with a native configuration system on the device. For each variable that is added to the device, we have to manually create a web UI for it. We then have to re-implement this in the front-end application.

 

As a result, for every new feature that is added to the device, the front-end will need to be updated to provide a UI to configure it. This takes resources and creates a situation where the front-end is always ‘behind’ the device and the customer needs to upgrade the device as well as 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

 

In an ideal world, 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 it takes 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 Modelling Language widely used to configure network devices. As such, 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 and as of this writing, Cisco, Juniper and Ericsson all support NETCONF and YANG.

 

Device Configuration Using YANG

One of the most important benefits of using YANG is the possibility to automatically generate a UI from the data model. Having a UI framework that can take a data model and generate a UI from it will provide substantial resource savings.

 

If we have a YANG data model for each component, and have the front-end automatically generate a UI based on the YANG model, we can efficiently add support for new products and features. 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 is using 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. This would also allow us to be able to provide configuration abilities for the third party network functions, or even the third party hardware devices, as long as these support NETCONF/YANG.

 

Operational Advantages of Yang Model

 

YANG is a significantly refined data modeling language. It allows definition of constraints, and separation of configuration and state elements. Unlike SNMP, NETCONF supports atomic transactions for 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 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 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. The ability to use standard YANG models can save development time and ensure that devices that share 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 as well as how the device responds, reducing mistakes due to misunderstanding. Validation of configuration changes against the model can prevent malformed/inconsistent changes from being applied. 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. For completed transactions that result in unexpected behavior such as instability or degraded service, a clean transaction rollback can quickly and safely restore stability and availability.

 

Niyuj’s Solution

 

Session Border Controller (SBC) Flex UI Generator (FUG)

Instead of a custom UI implementation, it would be ideal if YANG models can 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, we have named it Session Border Controller (SBC) Flex UI Generator (FUG).

 

Niyuj Approach

 

Niyuj adapted a two-pronged approach of devising a solution that is vendor agnostic and which 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 full control over the configuration they wish to generate. Since a customer may deal with multiple vendors, there should be a mechanism which empowers 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. This allows enterprises to fully digitize their configuration processes through integration with other IT systems – these could include Orchestrators, Policy Managers, CRM platforms, and much more.

 

Solution Architecture

Solution devised by Niyuj 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. For a scalable solution, this data should be sourced from a dynamic inventory source 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. This means that the WebUI, SNMP, Broadworks Device Manager et al, have to implement the configuration setting logic, and the validation of input. This makes it impossible to add new configuration mechanisms, since the re-implementation effort is huge. 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 be used to validate YANG modules for correctness, to transform YANG modules into other formats, and to generate code from the modules. There are several tools available for this purpose, pyang is one such tool.

 

The translator can further be utilized to provide the JSON Schemas using REST APIs. These REST APIs will be invoked by the frontend framework to generate UI components dynamically.

 

SBC Flex UI Generator
The SBC Flex UI component generator will bear the responsibility of 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, range selector for numbers, and checkboxes for booleans.

And to achieve this, we must not hard code such things, rather 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 very basic sample of a YANG model, it’s 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

Post Comments