Publish Your Data Models!

This post is written by Claes Wikstr√∂m. Apart from being one of our founders, and currently one of the driving forces in our NCS development, “Klacke” (which is the name he actually responds to) is also an Erlang hacker at large.

Consider the case that you are assigned the task to integrate with some software northbound of a router, a switch or any type of network device.

How do you find what the device can do? It’s easy to do a MIB walk using an SNMP client, but you cannot get hold of the MIBs that the device is actually implementing without contacting the equipment vendor.

Sometimes, the vendor has the MIBs on an FTP server with public access, sometimes not. (This feels pretty 1995 by the way). Sometimes the vendor doesn’t even publish the MIBs, this can be either out of negligence or on purpose. Maybe the vendor tries to sell integration services itself. Sometimes the vendor has gone out of business, or maybe you buy a 10 year old device on Ebay, and the vendor doesn’t even consider you to be a customer.

Regardless, the problem of finding the MIBs, and the right version of the MIBs according to revision of the software on your device is very real. Integrators are sometimes forced to guess (or experiment) on the version of the MIBs on the device. SNMP has no mechanism of conveying this information.

In stark contrast to the above mentioned mess, we can see how NETCONF/YANG has tackled and solved the problem. RFC 6022 “YANG Module for NETCONF Monitoring” has the solution which is the ability of a NETCONF client to query the device for the YANG models. Let’s look at an overview on the hello capability exchange between a NETCONF client and a NETCONF server.

The client connects to the server and sends it’s hello message, the agent responds with the following content in the hello response message:


<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04
</capability>
<capability>
http://tail-f.com/ns/example/dhcpd?module=dhcpd
</capability>
...

This hello exchange tells the manager that:

  • The server implements NETCONF base protocol version 1.1 as defined in RFC 6241
  • The server supports the RFC 6022¬†through the ietf-netconf-monitoring capability
  • The server implements a YANG module called dhcpd which is the one we are interested in here.

At this point, the manager can invoke the get-schema NETCONF operation that comes from the ietf-netconf-monitoring module to retrieve the schema (YANG module) of the dhcpd module.

The manager issues over the SSH channel:

<get-schema
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>dhcpd</identifier>
<format>yang</format>
</get-schema>
...

and will get the full YANG module text as a response from the agent:


<data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
module dhcp {
namespace "http://tail-f.com/ns/example/dhcpd";
prefix dhcpd;

import ietf-inet-types {
prefix inet;
}

Thus, this provides a mechanism for an integrator to retrieve all required information to integrate towards a device. The upsides for the NEPs to implement this are several:

  • An integrator doesn’t have to contact the vendor to integrate. Vendor saves time, integrator save time.
  • The integrator gets the modules and also the correct revision of the module. Errors are avoided.
  • The NEP vendor gets karma points and generally behaves as a good netizen.