Live Talk - Insight - NETCONF/YANG.

Questions from the Live Talk.

• Why should an operator care about NETCONF/YANG and not just continue as they have before?

  Multiple reasons - for one, network vendors are starting to deliver equipment that only speaks NETCONF, which means you either use the vendor Element Management System or speak NETCONF to the device, which will only accelerate in the future.

  But also, unless you have a completely homogenous network with one vendor, one product, and one version, NETCONF, and YANG will save you time and money.

• Currently, drivers are written in PHP and mostly push commands via SSH or Telnet to the device, with no real transactions or equivalent. Does Netadmin plan to keep that model and translate it to YANG and NETCONF?

  No, we're keeping the driver model as is, but we will not be implementing NETCONF as a driver; it will be its own management type, separate from drivers and assemblies, because we need to be able to build features like network-wide transactions that would not be possible to implement in a driver.

• What vendor will you be using for your proof-of-concept?

  As many as we can. We've tested against Cisco, Nokia, and a number of other vendors. We want to cover as many vendors as possible to be able to deliver what our customers expect: a solution that will talk to your equipment, no matter the vendor.

• You mentioned that YANG would enable fraud detection, human- and machine-readable configs and multivendor. Are there other interesting things that NETCONF/YANG could enable?

  One of the things that machine-readable configurations enable is keeping the configuration state within Netadmin. Once you have that, you can do things like closed-loop configuration, where you have an intended state in Netadmin, and Netadmin keeps the devices in that intended state. You can also do intent-based provisioning where you have an expressed intent ("provision 100 Mbps Internet access for this customer"), and it is up to the system to generate the configuration to make that happen instead of the system being told the exact configuration to provision on the customer port.

• Would Netadmin be interested in using customer test equipment to improve vendor support?

  Absolutely. We are always interested in ensuring that the customer use case is supported, whether from a technical or business standpoint.

• Apart from being a more modern and robust provisioning method, transaction support, and vendor agnostic, do you see any other positive side effects or features that Netadmin plans to develop or use while implementing NETCONF/YANG?

  I think we will discover along the way many things that are now possible because we now have a standardized way of talking to devices and standardized models for reading and writing configuration and operational data. We have many ideas, and I'm sure many of our customers have even more, so we hope to go on this journey together with our customers and, along the way, find the best solutions possible.

• Will NETCONF/YANG require an additional license?

  No.

• Will there be a Git-like tracking of changes for configurations? Can we upload configurations into Netadmin while keeping them in our own repositories?

  All these things are features that are enabled by this change, and it's something we would like to do. Imagine having a consistent database of changes for all your configurations for all your devices and being able to track your changes through time - that would be awesome, and of course, we want to do that; it's just a question of how do we implement that in the best possible way to make it as flexible as possible to support all our customer use cases.

• Will NETCONF/YANG also replace SNMP monitoring?

  Replace, no, but it will be an additional way of getting operational data into Netadmin. NETCONF/YANG supports various ways of getting operational data, either by polling a particular path of a model for specific data or using something called YANG-Push, where you can subscribe to a device-defined feed of data, much like SNMP traps.