When routing platforms were first introduced in the 1980s, the pace of new feature development was frenetic. It was common practice for new development teams to be formed almost daily and for them to work in relative isolation. These teams developed every element of a new feature, including the command line interface (CLI) and the data structures that were necessary for its configuration, operation, and monitoring.

This practice persisted for years and was prevalent industry-wide, therefore the syntax associated with features such as BGP, QOS, or VPNs varied widely across platforms and software releases.

Traditional Information Store Model - Interface to Each Process

This software development model was productive for customers as it supported rapid feature velocity. Over time, however, this model inhibited the ability to configure and manage networks at scale. Configuring and operating a single feature within a large network could require the use of several different CLIs.

Legacy scripting tools such as Tcl and Expect were leveraged to optimize configuration workflows and deliver more repeatable, less error-prone results, but they still had to be developed and maintained for potentially many disparate CLI interfaces.

As the networking industry adopts programmatic network device acccess methods, APIs and model-driven software interfaces offer a structured way to access and automate the network device.

This chapter will explore solutions to these legacy network management issues, which can be addressed with data model concepts and the NX-API REST interface.