Deploy360 2 December 2015

Tribute to Rob Blokzijl

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement

RobBlokzijl20102The Deploy360 team is sad to the hear of the passing of Rob Blokzijl yesterday. Rob was a hugely influential character in the Internet community, having founded and then chaired RIPE until last year, but was also instrumental in the formation of a number of other important Internet bodies. It’s surely no coincidence that Amsterdam has become a major centre for the Internet, which can no doubt be attributed to Rob’s ability to bring different parties together in common goals.

Olaf Kolkman has posted his thoughts over on Internet Technology Matters, but I first met Rob in 1997 at TERENA Technical Committee meetings in the days when the RIPE NCC was still a ‘project’ of TERENA, albeit three times bigger than its parent. I not only found him good and humorous company, but always seeming to have time for everyone regardless of stature. He later proved to be good and supportive counsel whilst I was running the Domain Name Registration Forum at RIPE meetings in the period 2000-2001.

The R&E networking and RIPE communities somewhat diverged after this, so I had much less contact with RIPE and Rob in the years afterwards. However, I was pleased to be invited as a representative of TERENA to his investiture into the Dutch Order of Oranje-Nassau in 2010, which I think demonstrated his ability to remember everyone he met!

Perhaps though, this extract from “Exploring the Internet” by Carl Malamud about an early RIPE meeting provides a better testimony to his achievements…

The meeting was about to start, so I gathered my badge and one each of the dozens of handouts and went into a university-style lecture hall. Down at the bottom of the hall sat three serious-looking RIPE officials facing a room of 50 or so equally serious-looking engineers.

Rob Blokzijl was going through a long agenda, reviewing action items from the previous meeting and making announcements. I propped my jet- lagged eyes open with toothpicks and started leafing through the materials I had picked up.

RIPE was formed as a sort of anti-organization, a reaction to the total ineffectiveness of other groups in setting up a pan-European Internet. At the time RIPE was formed, there had been several years of thrashing while people tried to figure out how to make OSI into something real.

Meanwhile, several organizations with work to accomplish had been putting together TCP/IP networks. An Internet was being formed, but on an ad hoc basis. Networks were touching and accidents were starting to happen.

“What kinds of accidents were happening?” I naively asked Rob the next day while we were hiding in his office during a slack time in the working group sessions.

“Routing loops, black holes, the usual,” Rob said. To try and solve the problems, Rob had convened a group of six people from the real networks in Europe. Nuclear physics was the lead player, so in addition to Rob there were representatives from CERN in Geneva and the Italian physics community. The Italians were operating the only 2 Mbps international link in Europe at the time. To supplement the physicists, representatives from NORDUnet and EUnet also came.

At first, the six tried to work through the Réseaux Associés pour la Recherche Européenne (RARE), the association of research networking groups in Europe. RARE wouldn’t touch this issue, though. The six researchers were operating TCP/IP networks and RARE was exclusively and officially an OSI group.

Borrowing a phrase from Daniel Karrenberg of CWI that the “time was ripe for networking in Europe,” an extremely lightweight organization was founded in September 1990 with the mission of helping to ensure cooperation among European IP networks. Rob Blokzijl formally announced the formation of the group in RFC 1181, a very carefully worded one-page document.

In Europe, careful wording is crucial and I’ve seen more than one group spend several hours wordsmithing seemingly innocuous phrases. Rob proudly pointed out the triumphs in the RFC, such as the sentence that “RIPE serves as a focal point for other common activities of the participants related to IP networking.”

Apparently meaningless to the untrained eye, this sentence is rife with subtleties meant to steer a course through the shoals of politics. RIPE is a focal point, not an operational unit. It worries about only its own voluntary participants and is not trying to impose solutions on others. It deals only with IP networking and is thus not advocating against OSI but merely serves as a forum for those who have already chosen.

By the time of the eleventh meeting, RIPE had grown to nearly 30 organizations and was meeting quarterly. NIKHEF hosted many of the meetings and acted as the organization’s secretariat. In terms of developing new standards, RIPE was a pretty sleepy forum. Those wanting a marathon of 50 working groups producing mountains of paper were directed instead to the IETF. RIPE was much more collegial and informal.
The week before the meeting, two days had been set aside for informal tutorials to bring new participants in TCP/IP up to speed. At the same time, a bake-off had been held featuring equipment from various vendors and even including an ISDN switch. People worked together to form different network topologies and see what types of problems arose.
The meeting itself was a one-day plenary, followed by a day of working groups, followed by another day of plenary meetings. There were only a few working groups, devoted to issues like routing and European connectivity.
In addition to representatives from most of the central European countries, there was a heavy contingent of East Europeans, including delegations from Czechoslovakia, Poland, Hungary, and Yugoslavia. Most of the representatives from Eastern Europe migrated to the working group session on connectivity. After a brief review of who was coming on line, the conversation turned to problems of mutual interest.
One of the biggest issues was simply getting equipment. All the countries were on the U.S. export restrictions list and the Poles told how it had taken them a year just to get a Cisco router. Various suggestions were bandied about on just exactly how the U.S. wanted the myriad forms filled out, but it was obvious that the rules the U.S. imposed remained mysterious and arbitrary.

Another working group was devoted to the issue of routing coordination. Routing was the single biggest technical issue at the meeting, and it is in this area that RIPE made its biggest contribution. In the U.S., there was a single backbone which used the EGP protocol to announce available routes to the second-tier regional networks. The backbone was centrally managed, so all the regionals got fairly consistent information. In Europe, there was no backbone, so it was pretty much guaranteed that conflicting routing information would be propagated, leading to routing loops and black holes. RIPE took a look at the map of Europe and it became clear that four sites acted as the main hubs.

These four sites, in Stockholm, Amsterdam, CERN, and Bologna, served as the centers for large numbers of secondary networks. Stockholm was the center of NORDUnet and Bologna was the center of the Italian network. Amsterdam and CERN had huge numbers of links going out to different countries.

The four sites agreed to take the lines running from Stockholm to Amsterdam to CERN to Bologna and turn them into a de facto European backbone. The routers at the four sites were combined into a single routing domain, thus presenting a consistent view of the world. To make the backbone a reality, all four sites agreed that transit traffic could traverse their links.

This was certainly not a centrally managed, fault resilient, highly designed backbone, but it did the job of connecting the European Internet. Since the four main sites also had links to the U.S., the European Internet was well connected to NSFNET and the rest of the world.

In a centrally managed backbone environment like NSFNET, low-level networks that wish to make their availability known to the world (and thus enable communications with said world) simply have to inform the NIC or NOC running the backbone. If the low-level network doesn’t fill out the appropriate forms or jump through the appropriate hoops, the network is simply not announced and thus is effectively isolated. It would be as if a road existed into a country but there was no indication of the road on any map.

In Europe, maintaining the name space was a trickier situation. RIPE came up with a novel plan to keep information up to date. A European WHOIS service was put into place containing network names, domain names, IP addresses, and the like.

The incentive to keep this information up to date was quite simple. The four backbone sites used the WHOIS database to load their routers. Sites that didn’t keep information up to date were simply not announced over the de facto backbone.

RIPE was a simple, effective tool for coordination and instruction, all done on a shoestring. The informal nature of the group and the advocacy of the heretical TCP/IP was too much for the networking establishment and RIPE came under heavy attack at first from officially sponsored groups like RARE.

To understand why RARE would object, one has only to remember that TCP/IP continues to be referred to by many as “DoD IP.” In contrast, OSI, developed with very heavy participation from European academics and PTTs, was the open way to do networking.

While RIPE was under attack, it was also clear that IP networking was gaining a strong hold in Europe. In one of those bizarre twists of European politics, RIPE became an official RARE “activity.” Not an official working group, mind you, with the connotations of European Commission financial support, official voting by one participant per country, and a chairman appointed by the RARE Council of Administration. Simply an activity.

Under the merger and acquisition agreement, RIPE would continue as an independent group and would elect its own chairman. RARE got to bring the renegades under its umbrella and unity once again reigned, at least on the surface.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...