Funny enough, much of the food you will find in Yokohama is Chinese, rather than Japanese — another odd fact you probably didn’t need to know. I’m going to cover day 4 and 5 here, as I’m leaving tomorrow morning to head back to the “real world.”
Wednesday is a “slow day” in terms of working group meetings because the afternoon is largely taken up by the plenary. There used to be two plenaries, one covering administrative issues, and the second covering new technical ideas, but these have been combined in recent years into one single plenary. The administrative part of the plenary generally revolves around where meetings are being held (more on this in a moment), the way the lines are handled at the mic during meetings, how mailing lists are handled, and things of this sort. The technical portion is always the more interesting piece (at least for me) — this year that was a talk on measurement drive protocol engineering. The recording for this session should be available at some point in the future: it’s well worth watching.
While a number of working groups met on Wednesday and Thursday, several are worth highlighting. For instance, the Network Function Virtualization Research Group (NFVRG) met. The IRTF is a little less familiar to most people; it’s an organization explicitly built around looking at future work that might be brought to the IETF and to supporting basic research in networking technologies. The first presentation that caught my attention is a draft that is working through how to put policy around sets of services deployed in a network using the NFV model. The interesting thing here is not just the NFV piece, but the actual process of trying to understand how policy can be broken up into multiple pieces, and each piece described in some detail. The second presentation of interest was a draft on the relationship between DevOps and NFV deployments.
In the OSPF working group, two drafts of interest to just about every network were presented: stub neighbors and prefix/link attribute tags. The first is designed to help OSPF scale in larger networks with a lot of leaf nodes; the second is designed to allow OSPF to carry human readable descriptions that would be visible in the database of any router in the network. The second would be a huge boon to engineers troubleshooting network failures or misconfigurations, as you wouldn’t need to jump to the router that originated a link advertisement to discover information about it beyond the originating router, IP address, and other information that might be really useful to humans.
I would be remiss if I didn’t mention a draft I’m co-authoring that was presented in the Routing Area Working Group (RTGWG); while the draft itself is a shell, the idea is simple: we need to develop and standardize a common set of Operation and Maintenance (OAM) tools for all the new transport layers being invented. For instance, BIER is a new multicast routing mechanism, VXLAN is a somewhat new tunnel encapsulation, and there are many others. The IETF generally creates a new set of ping, traceroute, and other tools for each of these new transports, a situation that causes a lot of trouble for network operators. This draft is pointing this problem out, and suggesting the development of a set of extensible, common tools for all transport mechanisms.
Finally, I attended a small meeting that is looking at IETF culture, and how to make the IETF work better in the modern world. The interesting thing about this meeting is that it’s even happening in the first place. Many people think of the IETF as some sort of geekfest, made up of people who really just want to get technical work done, and don’t much care about social issues. In reality, the IETF is probably one of the most self-conscious organizations you will encounter. For instance, a lot of people look at the IETF meeting locations and think, “wow, I wish I could plan vacations like that three times a year.”
The reality is far different — there are specific rules in place about where the IETF can meet, such as which continent must be held on, etc. These rules aren’t in place to maximize frequent flier miles, but rather in the name of making certain the IETF places the burden of travel equally on everyone within what is truly a global organization. It’s not really fair to always have meetings in the US, for instance, because many people fly from Japan, China, Africa, and the Middle East three times a year to attend. The location of the IETF meeting is therefore intentionally moved in a specific pattern to encourage as much participation as possible in at least two meetings a year for anyone who wants to participate. Beyond all of this, it’s good to be immersed in different cultures, to hear from local voices, and to become better attuned to the many people who rely on the Internet across the world.
The IETF is intentional in its attempts to include as many people as possible in the process. That’s something you might not expect out of a geekfest.