The Internet Architecture Board’s (IAB) chair, Olaf Kolkman, asked the members of the IAB to provide a statement paper each on what they believe the current most pressing issues in terms of Internet architecture are. Not sure if these will be made public or not, but I decided to post mine here.

I have thought about this for the past few days, and realised that it’s hard to come up with overarching issues and even harder to come up with issues, where the IAB actually could make a difference. But I came with up with two issues.

Protocol balkanisation and engineering laziness; support of the walled gardens

I see tendencies in the Internet Engineering Task Force (IETF) that some work targets very specific use cases. This seems to me to often lead to the fact that the developed protocols makes assumptions regarding the deployment environment, effectively leading to protocols that will only work inside a given domain. These domains, more often than not, mirror the networks of the providers. This leads to a “walled garden” of protocol deployment already in the design of the protocols, rather than building on the traditional model of the Internet, where the only assumption allowed by a higher protocol is the characteristics of the IP network lower in the protocol stack. This development is probably due to a number of factors. Mostly this is seen in the cases where traditional telco behaviour is being back-ported to “Internet awareness”, or with the buzzword of the day, the Next Generation Networks. Partly I also believe that engineering laziness is to blame. Often, the simpler, limited, use case is easier to engineer for rather than a wider, Internet wide problem.

It’s also true that these applications in many cases will only ever exist inside a single domain, but we are also seeing cases where business development forces us to retrofit technology to work across the Internet, often by adding new supporting protocols and complexity, onto something existing and deployed. The risk here is that we are moving towards being the IP Engineering Task Force, rather than the Internet Engineering Task Force. This worries me as we are then on a sliding plane to an IP architecture where walled-gardens and feature lock in have been cemented, rather than the end-user centric, “pick and choose” model that to a large extent was the base for the success of the Internet. People are starting to assume Ethernet as the physical medium, just as we assume HTTP as the transport protocol.

So what can the IAB do? This seems to be much harder question, but I think that first of all we need to stress the layer independentness of TCP/IP and work together with the Internet Engineering Steering Group (IESG) on identifying problem areas, and perhaps even work with the Working Groups to help protocols to work across the wide Internet.

The scaling of BGP and IETF protocols

Tons have been written on the imminent collapse of the Internet due to the rush to multihoming with IPv6 (and in some cases—with IPv4). I don’t question the fact that the scaling properties of BGP in the global Internet is worrying in the long run, but I also believe that the cost for multihoming today is prohibitive enough that there won’t be a land rush. Current trends also seems to support that end-users rather NAT, even in IPv6—mostly for perceived benefits, and pay less than subscribe to a better service at higher cost. What DO worry me in the short run is the fact that iBGP is being used for a number of other services such as VPNs and endpoint discovery. Looking at data provided by ISPs at a number of recent Internet conferences, the number of internal routes is much higher and growing much faster than the global Internet. Most, if not all, of the proposals that have been made to help with the global routing scaling issues, does not address the internal route issue. Some of them could probably be retrofitted into dealing with this, others won’t do any better. I believe this issue will become pressing enough that it might have to be treated as a separate issue. Several large providers as far as I know are already feeling the pain and are therefore building out separate infrastructure to handle these services. While this certainly is good business for the vendors of routing equipment, it will raise deployment costs and again, build barriers between services.

I believe the IAB need to stress these issues and perhaps try and spin of separate work on the scaling of VPNs and end point discovery.