Two Years of Selective Peering with RIS

RIPE RIS (Routing Information Service) is our routing data collection platform. It collects data on BGP, the protocol that controls how traffic is routed between all the tens of thousands of different networks on the Internet. By collecting this data, RIS improves our understanding of the strengths and weaknesses of the global Internet routing system.

Problem statement

For RIS to work, it has to have enough vantage points to give a good overall view of what's going on in global routing. Having said that, global routing has gotten much bigger and more complex since the RIS project started back in 1999. The number of networks in the routing system as well as address blocks routed have both increased dramatically. And while the Internet was almost exclusively IPv4 back then, we now have both IPv4 and IPv6, each with their own routing tables.

One way to keep up with all this has been to keep increasing the number of RIS peers over time. That said though, while each new peer we add gives us a little bit of extra information about Internet routing, the added value of the information gained diminishes (law of diminishing returns). The result is that we end up with redundant data in RIS, the storage of which comes at a cost.

Peering strategy

As the problem of increasing redundancy in RIS data became more evident, we started rethinking our peering strategy (we were talking about this here on RIPE Labs back in 2020). The decision we arrived at was to adopt a selective peering approach, placing greater emphasis on the quality, as opposed to quantity, of the data.

While our previous open strategy effectively sought to maximise the number of RIS peers, it’s not as if we can peer with every BGP router on the Internet. What we can do is work harder at selecting peers that capture the diversity of Internet routing while staying within the budget allocated for storage and processing of RIS data. To do this, we looked at two main approaches:

1. Try to get comprehensive coverage of the Internet core by peering with Tier-1 networks
2. Try to get good sampling coverage for parts of the network. For this we can try to divide the whole Internet by country and find representative networks for each country. Or we divide the Internet by network type - i.e. eyeball networks, content networks, academic - and find ways to better cover these. (We actually chose to partition the Internet by country - since this is what we have data for - and determine how well we cover this part of the network.)

In both cases, our overall aim has been to look for peers that help us lower the distance - in terms of AS hops - between RIS and prefix origins. The intuition behind this is that BGP is an information hiding protocol, so each extra AS hop between RIS and the origin of a prefix can (and often will) hide information about the richness of topology, or will mask interesting routes we might want to see.

Progress so far

We started putting effort into approach 1 - getting comprehensive coverage of the Internet core - back in 2021. While many of the Tier-1 networks were already peering with RIS at that time, we managed to increase the number of routes we see through them both in IPv4 and IPv6, and also to add almost all of the missing Tier-1 networks. The notable exception here is Verizon - AS701, with whom we’ve not been able to establish a direct peering yet, though we established a peering with a downstream, so we have more coverage of routes via AS701 then we had before starting with this effort.

In the table above you see the number of prefixes in routes that RIS sees via a selected set of networks. As the definition of Tier-1 network is contentious, this selection is a consciously inclusive one - i.e. it also contains networks that might not be considered full Tier-1 networks by some (some background on this here). This method of measuring “coverage” is adopted from Ben Cox who uses it for bgp.tools. As you can see the number of routes via one of these networks currently tops at around 1.1 million and there are only a few omissions.

As for approach 2, where we focus on the diversity of RIS coverage across countries, we’ve been using a tool we built in Observable to observe the average number of AS hop distance from RIS per country. This gives us a metric for measuring how well we’re doing, and quickly identifying which countries we need to focus on.

For example, at the European peering forum 2022 in Rome, we showed how distant a given set of countries were from RIS at the time:

Here we see that, apart from Italy, all of the countries in focus sit above the global average distance to RIS (then a little over 2.5 hops, as indicated by the line on the plot).

Taking this as a starting point, we started pushing for more peering with networks in these countries, or with networks much closer to them then our current set of peers. Taking another look in 2023 to see what had changed, here was the result:

As we can see here, all of the selected countries are closer to RIS in 2023, many now falling below the average, which has actually gone decreased to less than 2.5 hops. While here we see that Iraq is still quite distant from RIS, we also see a decrease in contrast to the 2022 snapshot. You can explore these visualisations yourself on Observable.

New year, new budget

As mentioned above, one of the main benefits of the selective peering strategy is that goes hand in hand with more efficient use of the budget allocated for the storage and processing of RIS data.

While we’ve effectively been using the selective peering strategy to guide how we reach out to peers for a couple of years already, recent changes in light of the RIPE NCC budget for 2024 have prompted us to take more practical steps in order to step away from open peering. As a result, for the time being, we will be removing the peering form - where people have usually submitted requests to peer with RIS - from the RIS website.

This seems to us to be a move in the right direction - but RIS is a community driven service, so if people from the community disagree with this approach, we would like to hear from them. You can leave a comment in this article or email ris@ripe.net.