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" {
description
"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 {
description
"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;
description
"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++.
On Network Management 