Most IP practitioners have a similar history to tell when looking back on their careers: time spent configuring lots of routers to make big deployments possible. I always appreciated the responsibility that came with participating in these projects, and I would capture these memories on a photo archive throughout my career.   

Ivana+Lemos+Configuring+Routers_1     Ivana+Lemos+Configuring+Routers_2

Even though these are good memories, one aspect was challenging: the need to manually configure and repeatedly type nearly the same configuration using the command-line interface (CLI) – over and over again.

Thinking back, I have configured 100's of routers with 1000's of line configuration scripts! The simple math still amazes me. I have manually typed hundreds of thousands of command lines.

Why have we been doing so much manual configuration?

Historically, Simple Network Management Protocol (or SNMP) has been used to monitor all types of red and green statistics and charts showing how your devices were performing. SNMP was designed to support monitoring as well as configuration aspects, but it has not been a practical choice for the configuration of networks, especially as they have scaled.

For decades, people have been trying to automate the configuration of routers. They have used device-specific tools, proprietary integration, and scripts to push through different proprietary CLI with little choice of other standard data representation technology other than SNMP management information base (MIB).

As time passed, more and more network engineers realized – as I did - that those everyday tasks they frequently did on a repetitive basis aren’t just time consuming but are also prone to human errors. It was clear, there is a need to automate those tasks for the health of the business (and our own).

But how could this be done?

NETCONF/YANG: Wind of Change

Webinar
What is YANG and Why Should I Care?
The industry realized standardized data models and configuration protocols were needed. So, the IETF's Network Configuration Protocol (NETCONF) and Yet Another Next Generation (YANG)  data modeling language were developed to add structure, interoperability, and control to an otherwise chaotic configuration environment.

One often overlooked aspect, and reason this hasn’t happened sooner, is NETCONF standards were published years before the IETF standardized YANG. Over that timeframe, the overall NETCONF adoption was limited, because it was only when paired with YANG data modeling language that practical automation could be achieved and we started listening to the wind of change.

The table below summarizes how the configuration management protocols mentioned up to this point changed over time:

Chart+showing+evolution+from+SNMP+to+CLI+to+NETCONF

Don't worry if you are starting with the concepts of "Modules", "YANG", "NETCONF", "XML". Here is a straightforward 20-minute Webinar Series resource you can dive into to jumpstart your journey.

Now, if you are about to implement or implementing NETCONF/YANG and SDN management, I'd suggest reading further. It will be worth your time!

3 tips to make your NETCONF/YANG implementation successful:

  1. You need the right equipment — Investing in a programmable hardware infrastructure should precede automation.  It can be extremely difficult to automate the network at scale if some routers do not support standardized data modeling and configuration protocols (e.g., NETCONF/YANG).
  2. Use APIs instead of CLI — Harness the power of modern software and use Application Programming Interfaces (APIs) for automation. YANG itself is not an API nor a configuration mechanism.  YANG is the language used to build data models of the network and its capabilities.  Once you have YANG data models, you can use APIs to programmatically operate on the data model to configure and monitor the network.  These APIs can be NETCONF or others such as gNMI/gRPC.  But remember, whatever API you use should operate on the YANG data models.
  3. Make sure you have CLI and NETCONF parity – When using NETCONF/YANG, you need access to the same capabilities and state that you have with the CLI.  NETCONF/YANG should not just cover some aspects of the router. The manual CLI-based management and the automated NETCONF management must yield the same results.  At Ciena, we are proud that our SAOS next-generation operating system (OS) CLI is based on and consistent with YANG data models. So, there are no deployment mismatches or surprises.

Ciena has been actively participating in industry interoperability and deployment testing on a regular basis, such as that conducted by The European Advanced Networking Test Center (or EANTC). The 2021 NETCONF/YANG results are very illuminating and can be found here. 

Final thoughts

When we first started to build networks, it was about connecting locations. Then we began to connect people with wireless networks. Next, we built networks to connect machines. Now we are building networks to connect application workloads. The combination of places, people, machines, and applications have driven up the demand for intensive configuration of networks.

What Is the Adaptive Network™?
We must ponder the day of CLI scripting ending. For this to be possible we must adapt, our hardware must become more programmable, and our processes more automated. At Ciena, we call this combination of a programmable infrastructure with analytics driven intelligence the Adaptive NetworkTM.

It is always fun to look back at old memories – and see how things have changed. As our customers work on their network evolution journey, it’s exciting to be on the forefront of this change, working together to make this a reality - and updating our photo albums along the way.