Monthly Archives: April 2012

I’m in the process of writing up a more comprehensive post on the structure and content of the OF-CONFIG YANG module, but I’ve found a particularly interesting faux-pas that I though interesting to describe in this separate post.

YANG includea a couple of features that uses various types of references from part of the data model to another. The most common example of this is the leafref built-in type and it’s associated path statement that allows the module developer to reference a particular leaf instance in the data tree. Another type of references is used in the must statement and it’s associated XPath argument string that is used to fomal declare a constraint on valid data.

A good example of this comes from the draft interface configuration YANG module that is currently a working group item under consideration for standards track. The core interface model is very straightforward:

+--rw interfaces
   +--rw interface [name]
      +--rw name                        string
      +--rw description?                string
      +--rw type                        ianaift:iana-if-type
      +--rw location?                   string
      +--rw enabled?                    boolean
      +--ro if-index                    int32
      +--rw mtu?                        uint32
      +--rw link-up-down-trap-enable?   enumeration

The location leaf is an optional string. According to the specification text:

It is optional in the data model, but if the type represents a physical interface, it is mandatory.

So, in the example ethernet module in the Appendix we see the following construct:

container ethernet {
  must "../if:location" {
    "An ethernet interface must specify the physical location
     of the ethernet hardware.";

This means that the ethernet container will only be present if the interface configuration includes a location leaf. Note well that the reference references a configurable parameter (the location string is read-write). Now, turning to the OF-CONFIG 1.1 specification we see the following must statement in the global resources container:

container resources {
    "A lists containing all resources of the OpenFlow Capable Switch.";
     list port {
        must "features/current/rate != 'other' or " +
          "(count(current-rate) = 1 and count(max-rate) = 1 and "
          " current-rate > 0 and max-rate > 0)" {

If we follow the reference to the features/current/rate leaf highlighted above we see that it’s a config false node since it’s located in the current container:

container features {
  container current {
    uses openflow-port-current-features-grouping;
    config false;
      "The features (rates, duplex, etc.) of the port that are currently in use.";

This means that the state of the rate leaf is outside the control of the administrator and relies on operational state This is worth thinking twice about. The configuration simply becomes invalid if the operational state changes. What is useful system behavior in that case? Remove that part of the configuration? And what if that part of the configuration is referenced from other parts of the system? Consider the can of worms wide open.

In summary; referencing operational state is not what you want and this should probably be rethought in OF-CONFIG 1.1++.

The ONF YANG in MG-Soft's YANG Designer

It’s with some excitement I see that the ONF has publicly released the OF-CONFIG specification to precious little fanfare. The head-spinner (in a positive sense) for me is that it includes a nice little RFC 2119-style MUST statement making NETCONF mandatory:

[…] OF-CONFIG1.0 requires that devices supporting OF-CONFIG 1.0 MUST implement NETCONF protocol as the transport. This in turn implies as specified by NETCONF specification that OpenFlow Capable Switches supporting OF-CONFIG1.0 must implement SSH as a transport protocol

See, this is the exact type of use of NETCONF that I think will make all the difference. This means that pure OpenFlow switches actually don’t even really need a traditional CLI or Web UI. It will probably need some sort of very constrained CLI for seed configuration. After that it could be NETCONF only including a NETCONF CLI or a Web UI based with a NETCONF backend. It’s now programmatic, see.

Going back to the excellent (you should really, really read it) Problem Statement for the Automated Configuration of Large IP Networks draft makes me think that what is left is a reasonably well designed (secure!) “call home” protocol. This would mean that we could get rid of the ping-sweeps that is still, to this date, the most sophisticated tool that the network management world has in terms of discovering new network elements.

The Reverse Secure Shell (Reverse SSH) draft seems to be a good conversation starter. An open source implementation of that with some support from a vendor or two then I’m sure we’ll be able to reanimate the sleeping Secure Shell (secsh) working group and off we go.

Here’s a quick post on some of the things that makes adapting RESTful principles to the area of configuring network elements somewhat challenging. I’ve had a number of conversations of the tire-kicking kind (“What if we used REST instead”) in this direction and these are the kinds of conversation-holes that I find myself invariably unable to dig myself out of.

What I’m talking about below is the idea of adding RESTful interfaces to the network elements themselves. This is in contrast to providing a RESTful interface to the management system and then use whatever protocol or scripting means to make the configuration happen in the actual network elements.

REST relies heavily on the concept of hypermedia objects (remember the HATEOAS-principle!). Hypermedia objects are kind of self contained and self sufficient in that they are not expected to be mapped into any structured context (e.g. a tree or a chronological order). Think about what that would mean for designing hypermedia objects to represent the parameters required for any common router or switch configuration task (e.g. BGP peering configuration or MPLS VPN setup). How could we design useful hypermedia objects that:

  • Expose the useful set of configuration parameters available in the actual protocol implementations (vs an over-simplified model for very specific use cases)
  • Capture the relations among the common features in a rnetwork element (e.g. it doesn’t make sense to enable OSPF on interfaces that does not have an IP address)

A RESTful approach makes most sense when the designer have a very large degree of freedom to design the objects as they see fit and not be burdened with much implementation detail. The amount of configuration parameters and the amount of feature interactions in even a simple router or switch is such that this task will be very challenging.

This makes me think that RESTful interfaces may make a lot of sense on the element management layer where designers have a larger degree of freedom to make up application specific models and not be forced to reflect the underlying implementation. I believe it’s called abstraction.

On the other hand; I would love to be proven wrong through some ambitious attempt at breaking down some corner of a router or switch configuration into reasonable hypermedia objects that could be directly accessed by a management system. Or a REST CLI?