REST In Network Elements Makes No Sense

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?

Leave a comment