YANG Model Driven UI Component Standardization

Introduction

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.

Why is it important?

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 server driven UI for it manually, and we then have to re-implement this in the frontend application.

As a result, for every new feature added to the device, the front end will need to be updated to provide a server driven UI to configure it. It takes resources and creates a situation where the frontend is always ‘behind’ the device, and the customer needs to upgrade the device and the frontend to configure the latest features. This problem will worsen as we add more products under frontend management. For every new product, we would need to create a new server driven UI for that product’s configuration mechanism. To meet this challenge, ISPs 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 (Yet Another Next Generation) was developed by the IETF NETCONF Data Modeling Language Working Group (NETMOD) to be easily read by humans. YANG mode or model describes a data structure. A YANG mode or model is used for operations related network configuration management.

Also, Cisco, Juniper, and Ericsson support NETCONF and YANG. Cisco YANG models can manage Cisco networking devices and services. Cisco YANG models are capable of defining the structure, hierarchy and attribute of the configuration specific to Cisco devices. Component standardization can be achieved in YANG models by adopting common conventions, guidelines or best practices to ensure consistency and interoperability. Through component standardization of YANG models, an ecosystem of vendors, service providers, or network management systems developers can be built. The YANG interface is also critical. YANG interface is part of the module which can outline the communicative interface that will interact with network devices. A YANG schema is how a data model is defined in the YANG module. The YANG schema gives the data structure, attributes and relationships of data elements.

Device Configuration Using YANG

One of the most important benefits of using YANG is the possibility of generating a server driven 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. UI models are nothing but user interfaces for network management built using data as specified in a YANG model. UI models are generated using data structure to enable users to interact with network applications.

Here is UI from a YANG perspective. The process of design and implementation of UI for network applications is called UI engineering. UI engineering enables seamless interaction with devices or applications in an easy manner. API driven UI engineering is about the design and implementation of UI by using YANG data models and APIs. API driven UI interacts with devices of services in the network using YANG based APIs. Automatic UI generation is the auto generation of UIs based predefined templates or data models. Automatic UI generation can create UI components based on what is defined in a data model. Backend driven UI is the use of YANG data models and backend infrastructure to develop UI layouts. Backend driven UI can include network systems or applications which leverage the data models. Configuration driven UI or config driven UI use configuration data in YANG Mode to develop UI layouts and components. Config driven UI is meant to show the structure and semantics of config data. Data driven UI uses data structures to develop UI. Data driven UI is mean to present the configuration and status data of network services. Data driven UI framework can also be used to build UI that can interact with network services. Data driven UI framework is to be integrated with YANG models using APIs. Schema driven UI uses data schema to create UI components. Schema driven UI is generated based on structure and relationships as defined in schema.

Flex UI components can be generated by using a UI framework. These flex UI components must adhere to the specifications of network applications. A model UI can also be developed by using YANG models along with UI frameworks or libraries. By developing a model UI, a standardized way can be enabled to represent and exchange information between network systems. A YANG model can also signify config data which is related to a banner UI component.

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 YANG 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.

What are the operational advantages of the Yang model

YANG data modelling language that allows the definition of constraints and separation of configuration and state elements. YANG data modelling language is used for network management. Unlike SNMP, NETCONF supports atomic transactions for a configuration change. A YANG model example can be seen as that which specifies a structure and semantic of a network configuration and the current operational status of network devices. The YANG data model example also can be seen as a standard way of defining and exchanging information between network systems. A YANG model example specifies the structure and semantics of configuration and state data for network devices, providing a standardized way to define and exchange information between management systems and network elements. YANG data modelling allows for consistent and interoperable management of network devices by defining data hierarchy, types, and relationships.

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

What are the 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 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.

Conclusion

YANG model can help in standardizing the design and implementation of UI components across network systems. It offers lot of advantages in the UI development. YANG gives a structured approach in defining UI components and enables easy integration and interoperability across network systems. YANG model improved UX and improves collaboration between developers and administrators. It also improves productivity and improves user satisfaction. Developers, administrators, or UI designers can use this framework to reimagine UI development and explore its possibilities to build reliable and scalable user interfaces for network management.

FAQs

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