Archive

Monthly Archives: March 2012

IETF is back in Europe for its 83d meeting starting Monday and I’m going. These are pretty interesting times for standard defining organizations in general and the venerable Task Force that created everything you use to read this post (except the browser markup language) is no different in that area.

With the networking industry in an unprecedented state of hype-driven flux it is no surprise that many SDOs are thinking about how to keep relevant. How this thinking manifests itself depends on the cultural roots of the organization. Some try to “pivot” (or whatever it’s called these days) away from being marginalized and spend marketing (!) resources on things like membership brainstorming sessions, general cloudification and virtualization activities, or simply raising the cost of exhibitors booths during events. Very few of these activities lead to better, more well timed and more useful standards.

I’ve always felt that IETF is the FreeBSD of the standards industry. It may not be first to publish specifications for emerging challenges, but when working group drafts eventually pass through the eye of the needle (which is IESG approval) it usually provide specifications with enough detail and quality to actually make it into implementations and interoperability.

Much of the criticism of the IETF comes from lack of understanding the principles and processes it is built on. Ironically enough this is in humorous symmetry with the classic “I haven’t read the document we’re discussing, BUT…”-comment that is a very well known faux pas inside the IETF. The processes are informally introduced in The introductory Tao of the IETF document and the RFC process is described in detail RFC 2026. Personally I think it’s best summarized in the following quote from David Clark:

We reject kings, presidents and voting. We believe in rough consensus and running code

So, for Paris I’m particularly looking forward to:

  • The dinners and hallway discussions which is always where the most exciting conversations and napkin sessions are held
  • The NETCONF and YANG contributors meeting where REST access to resources described in YANG is on the agenda
  • I’m guessing the “Overlay Networking (NVO3)” and the “Infrastructure-to-application information exposure (i2aex)” birds of feather (BoF) sessions will be crowd pleasers and will provide ample opportunity for some good grey-beard action

Reach out (@cmoberg or calle@tail-f.com) if you want to (mail|meet|tweet)up at the Le Palais des Congres de Paris starting in a couple of hours.

This post is a more of a reference note around some YANG modeling specifics. It has come up a couple of times so I thought I’d follow the DRY principle and document once and reference forever. I think the casual reader will enjoy the read (especially if interested in modeling stuff) but there are XPath predicates and NETCONF error tags ahead so be warned!

The YANG language provides a useful concept in the leafref statement. It is a way to reference a particular leaf instance in a data store. This is one of the semantic validation constructs that really adds tangible benefits above and beyond what’s available in e.g. SMI.

A common use case is to use a leafref to reference the network interface or IP address used for a particular purpose. Since leafrefs refer to instances, not nodes in the model, it also implies that there is valid configuration in place for that particular interface or IP address. Here’s an example from the CCAP YANG module:

leaf slot {
    type leafref {
        path "/ccap/chassis/slot/slot-number";
    }
 }

The slot leaf references an instance of a slot in a CCAP chassis identified by it’s slot number which is also the key in the slot list. This means that the referenced slot configuration (e.g. slot “1”) must exist in the configuration for the referencing leaf to be valid. Dangling pointers are not allowed. This is in contrast with e.g. how ifIndex is used in SNMP where there is no validation of whether the pointed-to object really exists.

Validation is performed by the server side and there is a specific error message defined for situations where a leafref would refer to a non-existing instance (from RFC 6020, Section 13.6):

error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the leafref leaf.

This post wouldn’t be any fun if it didn’t introduce a challenge though; so here goes. The CCAP model introduced above obviously goes deeper than the ‘slot’ concept. Slots are expected to contain line cards of various types and there are ports sitting on the line card. A system can contain several slots. Each slot contains a single line card (that may or may not be present) and a line card hosts several ports.

So, in order to reference an instance of, say, a port. We need to traverse the following structure with our reference:

  • A list of slot/line-card pairs that each contain a;
  • list of ports

An example of such a reference could be:

<slot>2</slot>
<upstream-rf-port>4</upstream-rf-port>

Note that we need to specify two values (slot 2 and port 4) to uniquely identify a port instance. Note that since there is a 1:1 mapping between slot and line-card (a slot may only contain exactly 0 or 1 line-cards) there is no need for a key reference to the line-card.

A more mundane example of this is how certain router vendors identify interfaces in the CLI:

  • Juniper: ge-0/0/1 for gigabit ethernet port 1 in PIC 0 in slot 0
  • Cisco: FastEthernet0/0 for fast ethernet port 0 in slot 0

The numeric components of these interface names are examples of instance identifiers, meaning that they references keys (one per list traversed) to uniquely identify a specific leaf. Now if you remember the syntax of the path-statement above:

path "/ccap/chassis/slot/slot-number";

The XPath syntax in the path statements does not include a way to provide more than a single key (in this case slot-number), so as we go further down the path we would end up with something like:

path "/ccap/chassis/slot/line-card/rf-line-card/upstream-rf-port/port-number";

The path statement above looks deceptively simple and it is both. It only identifies port-number on value, meaning that if we have several RF line cards with the same identifier (say “0”), then we’ll get a match for all of those which is not what we would be looking for in a leafref. The qualifying parent keys are missing. This requires a pretty neat trick using XPath predicates in leafrefs.

Leafref path statements (described in RFC6020, Section 9.9.2) is a subset of XPath abbreviated syntax. This opens up for the use of XPath predicates that can be used to find specific node(s) that contain a specific value. The trick that we are going to look at uses the current() predicate to pin keys while traversing trees with multiple keys. The current() predicate is specific to YANG’s application of XPath (imported from XSLT) and is described like this in RFC 6020 Section 6.4.1:

The function library is the core function library defined in [XPATH], and a function “current()” that returns a node set with the initial context node.

Now, looking at the following extended snippet from the CCAP model:

grouping upstream-physical-channel-reference {
    leaf slot {
        type leafref {
            path "/ccap/chassis/slot/slot-number";
        }
    }
    leaf upstream-rf-port {
        type leafref {
            path "/ccap/chassis/slot[slot-number=current()/../slot]/line-card/rf-line-card/upstream-rf-port/port-number";
        }
    }
}

The upstream-physical-channel-reference grouping contains two leaves. The slot leaf is a leafref with a path referring to a slot. The upstream-rf-port leaf is where the fun starts. By using the current() function in a predicate we reference the list member that have the same slot-number value as the sibling slot leafref.

So, the combination of the slot and upstream-rf-port leafs uniquely identify an upstream port. And by collecting them into a grouping with a label upstream-physical-channel-reference, we’ve made it reusable. So anytime we need to refer to a physical channel interface we can instantiate it using uses. Except in notifications, but that’s for a separate blog post.

This, by the way, can’t be done in XML Schema. Which is unexpected. All evidence to the contrary would be much appreciated.

Having worked with cisco CLIs through many maintenance windows in the early years of my career, I’ve come to not-like it as much as any other reasonably ambitious network engineer. Back in the late 90s I experienced a real eye-opener of a situation where a team of network engineers threatened to resign if the suggestion to introduce another CLI (read: JUNOS) in the network was made real. I can’t remember exactly, but I have this feeling that they wore their leather jackets during the meeting where things became agitated.

As I’ve been slowly immersing myself in network management over the recent years, I’ve had countless discussions with various makes of networking pundits on this particular topic. It’s just interesting to see how clever engineers go to extremes to maintain a form of status quo that they in any other context would understand to be a problem.

The most interesting take on this issue was conveyed to me by wise man with a lot of experience directly from the source of the problem in this example. His point was that in order to understand the proliferation of, and the lengths to which some engineers go to defend the CLI, one would benefit from understanding the concept of rent seeking. To quote Wikipedia:

In economics, rent-seeking is an attempt to obtain economic rent by manipulating the social or political environment in which economic activities occur, rather than by creating new wealth, for example, spending money on political lobbying in order to be given a share of wealth that has already been created. A famous example of rent-seeking is the limiting of access to lucrative occupations, as by medieval guilds or modern state certifications and licensures.

I could literally hear the coin drop in my own head as I read the last sentence of the above quote. Of course, the leather-jacketed engineers simply worked to maintain monopoly-like privileges and limit free competition on innovative improvements around working with router configuration. In hindsight it makes perfect sense (as always) and had I understood this at the time then I’m sure the ensuing screaming match would have turned more constructive faster.

When we eventually introduced M40s in the network one of the leather-jacketed guys told me in confidence that he wanted at least some of his IOS CLI years back now that he had been exposed to the JUNOS equivalent. At that point he understood the value of the CLI equivalent of a free enterprise approach. The good part of applying known problem definitions to your observations is that it usually comes with a set of solutions and rent-seeking is not different in that sense.

I’ll leave it as an exercise to the reader to find the most easily translated approach to breaking out of situations like this and would love to hear if people have experience with this pattern from other parts of our beloved networking industry.