After last week’s, a reader left a comment noting “I2RS doesn’t manipulate forwarding data.” If I2RS isn’t “manipulating forwarding data,” then what, precisely, is it doing? I thought it’s worth a post to try and help folks understand the definitions in this space—except, as you’ll soon discover, there are no definitions here. In fact, it’s almost impossible to create a single set of definitions that will clarify the issues involved in understanding the various sorts of state in a network device. The following illustration might be helpful in trying to understand the vagaries of the various kinds of state, and the confusion that results from the various names used in different places.
It would be “nice” to say something like: information held in the forwarding table, that’s actually used to forward traffic through the router, is the only real “forwarding data.” This makes for a nice clean definition that clearly separates, say, what the RIB does and what the FIB does in most of the hardware based switching devices produced today. There are two problems with this clean definition, however.
First, there are, and always will be, devices produced that simply don’t have a forwarding table. Instead of a forwarding table, such devices use the routing table directly to look up forwarding information. A cardinal instance is a software based mobile device that simply doesn’t forward enough traffic to justify a separate hardware set for switching packets. The WiFi router in your house is probably an example.
Well… We could just say, “these devices have a faux FIB, kindof embedded in the RIB.” But is this really useful? Now devices with hardware forwarding have a FIB, and devices without have a virtual FIB that’s there just to make our definition work all the time. This suddenly doesn’t seem very clean.
Second, what is IS-IS doing if it’s not carrying forwarding information? We could say it’s just a link state distribution protocol, but it’s doing more than just distributing information—it’s also calculating shortest/loop free paths through the topology to specific reachable destinations. That changing the protocol can change the shortest/loop free paths illustrates that the protocol isn’t just carrying information. Rather, it’s actually building at least part of the information needed to forward packets—the shortest path isn’t calculated in the RIB.
Third, this definition sets up a nice clean separation between the RIB and the FIB, but it produces a lot of ambiguity between the routing protocols and the various configurations held in other places in the system. The canonical case is the humble static route: is this configuration, or is it forwarding state? Should information sent to an I2RS agent located on a device be processed through the device configuration manager because “it’s just like a static route?” I would argue this is a huge mistake, but what justification could I give if the only true forwarding state on a device is the FIB (which doesn’t, remember, actually exist on all forwarding devices)?
We’ve run into a thicket, as we normally do when trying to create nice clean definitions. How can we resolve these problems?
The problem here is a set description issue—we’re trying to describe self contained sets in imprecise terms. Does “forwarding data” mean only and all the data used to actually forward packets? Is the BGP table, or the IS-IS LSDB, for instance, somehow related to the forwarding of packets?
There is really only one solution here: narrow the definition of a normally broader term, creating a “technical term” that has a narrower meaning in a specific context. There is no clean way to do this, of course, because everyone has a different model in their heads, everyone has a different way of looking at the problem, and there will always be cases that just don’t fit.
But—for the sake of this blog (and for my sanity! 🙂 ), I’m going to use the terms like this:
- forwarding state: The information carried in the forwarding table actually used to switch packets. This would normally be in the FIB, but could sometimes (in some implementations) be in the RIB, as well. There is no “virtual FIB” anyplace, there are just devices without FIBs that keep their forwarding state mixed with their routing state (see below).
- routing state: The set of (hopefully) loop free paths resulting after arbitration by the RIB across the routing information injected by routing protocols, static configuration (like static routes), and other information sources (as supported by any individual implementation).
- forwarding information: Any information which contributes to the building of the routing and/or forwarding state, as defined above. This would include information injected by I2RS, a distributed routing protocol of any sort, etc.
The differentiation between state and information is an artificial one that cannot be defended from the raw meanings of the words; hence everyone might not agree with the definitions I’ve outlined here. But—and this is a huge but—we must be able to differentiate between these various kinds of information/data/state if we’re going to have a discussion around how control planes and forwarding devices actually work. If we fail too connect the loop free paths a routing protocol calculates—no matter how it calculates said paths—to the creation of routing state, and hence to forwarding state, then we have missed a crucial piece of the overall system, and I2RS itself will be difficult to understand (or rather, will end up being “just another configuration protocol”—precisely the problem the working group faces on a regular basis).
Again, these aren’t perfect, but I think them useful. There is still a term that means, “this is what is actually used to forward the packet,” but there is also still a term that means, “this information is not configuration (though it might be derived from configuration), but is used primarily for the purpose of calculating forwarding state.”
Next time I’ll return the main series, specifically considering the answer to the question I left of with last time—the speed question.