Beyond Open Standards

The Register recently published a long piece on the 30th anniversary of the founding of the Internet Engineering Task Force. It's an interesting read; the author interviewed a number of key people who've been in the IETF since the beginning (I only started attending IETF meetings in the late 1990's, so I'm still considered "new blood" in IETF terms). The writer ends the article by posing some key questions about the future of the IETF:

That covers one of the two most common questions I encounter when encouraging engineers to participate in the IETF: What is the long-term value proposition of the IETF? Or rather, in a larger sense: What is the future of open standards? The open source movement poses one set of challenges to the future of open standards; this is a topic I discussed in a blog series last fall. Disaggregation, or the separation of network software from hardware, raises a related set of questions. For instance, the New IP Agency, which is dedicated to forming consensus around network functions virtualization (NFV), states on its website:

Traditionally, open standards organizations (particularly the IETF) have been populated by vendors selling software embedded in hardware. What happens to open standards when the software is separated from the software through a trend like NFV? Does this mean the end of open standards? As we are currently moving towards disaggregation at LinkedIn, the relationship between open standards and the disaggregation process has become for me a matter that requires some serious thought.

The need for collaboration

But I’m not certain the NIP has it quite right in pinning the problem of increased uncertainty on open standards organizations. Of course the IETF has issues to resolve, and there is competition between the standards bodies, but is the IETF a source of uncertainty or is it simply reacting to uncertainty that is already there? Abandoning open standards isn’t going to solve the problem of finding new ways to build networks that are more economical and adaptable to the real world. To put it another way, abandoning open standards isn’t going to reduce the uncertainty, and open standards actually can be a vehicle to help control and manage it.

As with open source, the effort to split software and hardware into two different realms requires a foundation of open standards. Without open standards, we will end up with fragmented and overlapping technologies, which are ultimately bad for the Internet, and bad for business. On the other hand, the simple truth is that open standards aren't enough any longer. To put it in terms better suited for one of my philosophy classes, they're necessary, but not sufficient, to creating and building a healthy networking technology industry.

interop-las-vegas-small-logo.jpg

Hear more from Russ White live at Interop Las Vegas, where he'll discuss how engineers can navigate network complexity. Don't miss out -- register now for Interop May 2-6.

The problem seems to be that we've moved beyond the day when we could simplify things by just pitching an open standard at the vendors, and placing it in RFPs. We're at the point now where we need more than a standard -- and this is where the open source community, and the commercialization of open source software, comes in.

The IETF, then, doesn't just need to work with the open source folks (which the IETF already does to a large degree). Instead, the IETF, and all the standards bodies, need to learn to work within an ecosystem that contains open standards, but also  open source, disaggregation groups, and others. All of these different groups need to work together to make the Internet what it needs to be, as well as feeding the technology that every operator, from the smallest to the largest, needs to bring networking technologies to bear on human-scale problems.

The role of open standards

At the same time, the open source community needs to see the continued value of open standards. The IETF is starting to see a large influx of new work that is already implemented in open source, has several interoperating implementations, and is deployed in some number of networks. What should the IETF do with this work? Simply accept it? Or is there some need here to channel common problems towards common solutions to preserve some sort of cohesion within the networking community? If the latter, then what set of organizations are likely to be able to play this sort of channeling function? Open standards organizations, such as the IETF, should spring immediately to mind.

This channeling effort is, of course, bound to be seen by some as blocking useful work that could be done much faster. But what is the alternative? To allow a “thousand flowers to bloom,” and hence have a thousand systems to learn, support, and manage? Are we better off deploying an entirely new solution for every problem or building on existing solutions? Of course, the answer is going to be, “It depends.”  

But this isn’t an academic question. Rather, it’s a question that needs to be answered urgently if we’re to prevent the networking industry from breaking into an almost unlimited number of different solutions tailored to narrow problems. The problem disaggregation poses is precisely its strength: It allows a particular network to solve a particular set of problems in a way that is unique to that individual network. This is a double-edged sword that must be managed with care.

Somehow we must balance between the particular and the general, between reusing common solutions where possible, inventing new ones where needed, and knowing when to share. This last point — knowing when to share — also requires something else: a place to share. The best place is bound to be a strong community of people who have been working on similar problems across many years, who know how to integrate new ideas and to simply say “no thanks” when a solution seems  too narrowly focused..

This, to me, seems like the way forward. That doesn't mean I know how it should work; it just means there is a connection between yet another problem area and open standards that wasn’t readily apparent before. It also means, however, that if you want to be part of the solution, you need to be involved in these organizations.

Get involved

The Register questioned whether the IETF old guard will step aside, and also whether there will be new blood to carry the work forward.  I hope the answer is that the old and the new are blended in a way that successfully transfers the wisdom of the old guard to the new. If we can’t accomplish this, then our work may not be in vain, but it will need to be repeated. It would be a shame if there wasn't new blood. In fact, this is where you, dear reader, come into the picture.

The IETF doesn’t have a secret initiation rite designed to only select geniuses who are then allowed to consider the problems of the networking world. Rather, it’s actually made up of normal, everyday engineers who care about the future of the Internet and the ecosystem that surrounds it. Why aren’t you the new blood we need to help build better networks?

Join an IETF mailing list today. Jump in and participate. It doesn't matter if you can't come to the meetings. It doesn't matter if you make a fool of yourself a couple of times—feel free to look through the archives; I’ve been making a fool of myself on IETF lists for 15 years, and I’m likely to continue doing so for the foreseeable future.

But we all need to participate if we want to move the industry forward.