I'm going to spend a bit more time writing about network automation. If networking is not part of what interests you, I'll try to make certain that you can tell from the title of my posts that it will not be of interest.
Problem Space
When defining configuration, I hate to repeat myself. Copy and paste is useful but has its risks. I get snagged when I'm doing a paste-and-modify but I forget the second step. Also, if you ever have to change the configuration in the future, any repeated data has to be fixed in many places.
In an ideal setup, we want to be able to declare configuration for each device in an autonomous system with as little repetition as possible.
This implies hierarchy but an important observation is that very few network architectures fit the neat and tidy mold of being able to be concisely defined in terms of a tree. More specifically, we can't assume that the parents of a tree tell us anything about what the children will be like. For example, a fabric switch may have leaves that are of type TOR-A and TOR-B.
Proposed solution
It would be nice if we could declare a set of scopes that a device belongs to and those are used to determine the bulk of its common configuration with other similar devices.
Also, so that we may reason about how the configurations will be built deterministically, the scopes themselves must be defined with a property that indicates the order of application (or broadness/narrowness of scope).
Here I propose the definition of a new concept: "Config Scope Tags". Every device config declaration must begin identifying the list of memberships to Config Scopes.
Arbitrary Assignment
Scope tags are defined and then arbitrarily assigned to each device. They can be used in a hierachical fashion but are not restrictive to any particular tree shape or method of inclusion. In this respect, they are similar to community tags in BGP.
An example set of Config Scope Tags applicable to a data center environment may be:
- All Sites
- Site Name
- Build/Architecture Revision
- Device Class - e.g. TOR/Fabric
- Device Model#/SKU/FRU
- Fabric Bank
- Pod ID
Property: Order
In order to achieve minimal repetition, each scope tag will have a property for order which establishes the order in which template variables are applied. 0 is the broadest of scope and values are applied first so that they may be overridden by more specific data. Subsequently higher broadness values added to the configuration hash in order.
0 should be reserved as a special value for All Sites. Applicable to all devices in all domains. This is the only global scope.
The narrowest scope is the device specific configuration.
Example
Implicitly I was conceptualizing this as hierarchical YAML and I express my example in this way. But it can be stored in any form.
scopes.yml
This is a definition of config scope tags and their order values.
tor-5a.yml
This is a sample configuration for a TOR switch.