Note to readers: I’m currently at the IETF in Yokohama; each day I’m going to try to post something about the days events y’all might find interesting.
I don’t know why, but the faucet knobs in my hotel room seem to rotate backwards. I’m forever turning the water off when I mean to turn it on, and the other way around. Just one of those fun things about traveling to far distant lands… 🙂
Monday was a meetingful day, as always at the IETF. The morning meeting was the first I2RS WG meeting; I2RS is working on a southbound interface into the routing table, or RIB, based on YANG models and RESTCONF (I know, I’ve already put these things on my list of things to write about here at PP at some point in the future). There were a number of interesting discussions around the way various instructions to the device should interact, a problem which is mostly confusing because of the many different sets of terminology swirling around. For instance, there is the concept of “ownership,” which some people are taking to mean “ability to manage,” or “permission to manage.” In other words, one of the constructions we often find in the IT world is that if a process “owns” a piece of information, it is the “gatekeeper” on changes to that data. In fact, this is a well established principle in good coding practice.
But it just doesn’t work in the network control plane world. Instead, the idea of “ownership” is tied to “who’s information is currently installed in the database,” while changing the database revolves around the idea of “permission.” Another way this problem is being discussed is through the “panes of glass” metaphor — if you look at the current configuration of the device you see the “top pane of glass.” Below this pane of glass, however, is a set of “alternate settings” that would or might take effect if this top “pane of glass” is stripped away.
In I2RS, all of these things are tied to the concept of a priority — what you might call on a Cisco router an “administrative distance” (though some would argue this isn’t precisely the same thing, it’s a useful parallel). The entire concept of who gets to install what comes down to what the device allows any particular user and/or controller to install, and what the priority level of any particular user and/or controller is, much like different routing protocols can have filters imposed to prevent them from installing a route into the RIB, and they each have a different administrative distance.
In fact, much of the work of the IETF, in real life, is simply in trying to understand the different ways of discussing and understanding a problem, and then trying to come to either a single set of terms, or different sets of terms with a glossary so people can make sense of them. This is an aspect of technical standards work many people find “useless,” or even “boring,” but it’s actually often at the core of the discussion around any particular topic.
Another discussion of interest yesterday was around the many faces (or rather uses) of BGP Flowspec. Like many other people, once engineers try something, and it turns out to be useful, we tend to overload it ’til it dies — or at least screams “uncle.” In this case, it’s an additional set of communities added to BGP that can carry individual flow information based on various pieces of information — a useful extension with a lot of possibilities for anyone who uses BGP.
The draft that is most interesting here (at least to me) is Gunter Van de Velde’s draft on redirecting flows using BGP flowspec (draft-vandevelde-idr-flowspec-path-redirect), which would allow BGP to send what is effectively a policy route for a particular flow to all the edges of a network. This could be used to pull traffic into a tunnel, or to pull traffic to a particular device or service. I can see where this would be useful in data center fabrics based on BGP, as well in some wide area network situations, or situations where BGP peering is used to connect to an outside network.
That’s it for today — more tomorrow.