So, time for another blog post from Klacke (previous post available here).
In Network Equipment Provider (NEP) companies there is often a big disconnect between the groups that build the devices and the group that build the EMS, or if the NEP is larger, the NMS.
I have experienced the lack of communication first hand. For example, one of my responsibilities as an engineering manager was to set up a mailing list to communicate changes in the CLI. CLI engineers emailed new CLI commands to the list and the EMS/NMS groups monitored them to get notice of any changes. The whole process was ad hoc and unprofessional to say the least.
The EMS/NMS group has traditionally used CLI screen scraping for configuration management (if there was any) and SNMP to retrieve operational data.
Now NETCONF and YANG provides the means to overcome the divide between the device people and the EMS/NMS people. Apparently these groups have a communication problem, they don’t talk to each other, and it’s not likely that they will in the future either.
If the device people use NETCONF/YANG on the device, that in itself will be all the communication that is required. In particular the formalism of YANG provides all information that is required to the NMS team to:
- Retrieve the data models from the device
- Configure the device
- Get operational data from the device
The YANG models form a binding contract between the device and the NMS.
This is in stark contrast to CLI commands getting reluctantly and ad hoc mailed to email@example.com