Our customers tell us that NETCONF is fast becoming the preferred way to provision virtualized networking devices. Tail-f has been the main advocate of this protocol, with a pitch that goes roughly as follows: “NETCONF provides the toolset to configure an end-to-end service with a single network-wide transaction. OSS programmers spend less time in handling error cases –as the role of transactions is precisely to ensure success and rollback in case of errors. You do not need to pay high-salary CLI experts to handle such rollbacks manually, when the OSS has failed to do it in a proper way. And you can now automate service creation at an unprecedented level.”
The more you automate the less people you need and with the transactional capabilities of NETCONF you do not need them to recover the disaster of accidental automation glitches. That has got to be rather scary for the cohorts of CCIE-certified engineers and other CLI experts, doesn’t it? Does it mean their expertise will become redundant? Do they need to find a new mission in life?
I recently met some CLI engineers. They see the change coming but as they are buried by the demands of their day-to-day activities, they have not yet had the time to study and experiment with NETCONF. So, this protocol along with YANG data modelling remains very abstract, if not confusing to them. Of course they understand quite clearly that NETCONF is about a programmatic approach to the process of service creation. Network engineers thus understand they must acquire new skills in programming but it is certainly not their comfort zone today.
In many cases, an OSS will not manipulate YANG models or NETCONF directly. The likely way to program network services is to use tools that generate an interface code from the relevant YANG models and programmers will use that API to create the services. For IT engineers, service creation is not much more than mapping a Service Abstract Layer (SAL) data model to objects on a set of networking functions or devices, nothing more.
But that is not the starting point for network engineers. Their initial steps are still the same (as before NETCONF): create a network design, prepare a reference setup, elaborate configuration templates, write troubleshooting guides, etc., with the notable difference being that such templates must be written in NETCONF XML. With OneAccess products, this is a fairly natural step: first create the reference configuration using the familiar Command-Line Interface, then use some commands to export it as XML or a set of xpath statements. Using this process, CLI can be mapped to NETCONF pretty intuitively. In other words, an extensive CLI knowledge is still a valuable asset for engineers. Working with NETCONF is then an easy next step and defining XML templates is after all not so difficult.
An important task for network engineers is often to manage non-regression testing and analyze the resulting technical issues. Because NETCONF will be used, they will need to emulate the OSS to carry out these activities. This is where network engineers need to become masters at scripting NETCONF scenarios.
For sure this evolution is a threat for those who remain static. But it is also an opportunity: good network design know-how with thorough CLI expertise combined with some programming skills will be a great combination of skills on the job market. For those who tremble when hearing the word ‘programming’, the good news is: it really is not such a big leap! CLI experts can sleep soundly, for a while at least.
