Just a quick note from some of the conversations we’ve had with analysts over the last few days. As many if them are now finally revisiting the economics of service provisioning and activation they’re truly trying to understand, no really understand, the technical problem space in the stack between a customer service order (e.g. a VPN) and what actually happens in individual network elements (e.g. configuration changes to a VRF).
And they will eventually struggle pretty hard when it comes to the “last hop” in the configuration chain, meaning the nature of the technologies used, to make a set of changes to a single network element. To their horror, they realize that the current best practice is still scripts towards CLIs and to some extent SNMP SETs. At times I get the same feeling of pity as the first time my son was lied to, and found out. They’ve been stuck hard in SEP fields that the industry has been spectacularly successful in building. And this has been the source of revenue for system integrators for a long, long time.
We often get the question (in relation to our NCS product) about how we manage the lifecycle of our network equipment drivers (NEDs). NEDs is that part of NCS that manages the protocol specific details while communicating with participating network elements. We have one for cisco CLI, one for SNMP, one for REST, etc. Managing this type of features has traditionally been very painful in terms of complexity, cost, and time of delivery. We have a data model driven approach which reduces the time and money spent on maintaining NEDs significantly. Mainly because there is no programming required, only modeling the behaviour of the device in our data modeling language of choice: YANG.
Now, here comes the kicker. What happens if the device itself can communicate the data model that can then be fed into NCS? Well, the cost of maintaining adapters approaches zero, since it’s all about the data model. And what if there was a standard way of fetching the data models from devices? Well, that is the whole point of the get-schema operation in NETCONF as describes in RFC 6022, section 3.1. So, imagine a system that fetches the formal declaration of what a network element can be configured to do and all it’s operational data. And does this through a protocol that provides transactions, validations and rollbacks. That’s a fundamental change to the current situation.
The adapter layer as a revenue source goes away the ability for management systems to stay updated increases improves significantly. Ironically that takes us back to where many analysts thought we were a long, long time ago. With the big difference that we can now start forward momentum and start replacing the current generation of OSS systems and all the barriers they have raised around our networks.