Most of us will know that the Internet, true to its name, is a network of networks. Each network, whether a local ISP or a global content provider, must connect with others to enable the worldwide flow of data we know as the Internet. We have two ways to interconnect: Transit, where one network pays another for connectivity to the rest of the Internet, and peering, where networks agree to exchange traffic directly.
Peering policies
As a network operator, your willingness to peer is stated in your peering policy. There are three types of policies:
- Open — the network peers with everyone.
- Selective — the network has defined a set of rules that describes who they peer with and how.
- Restrictive — these networks have very little interest in expanding their peering.
The set of rules is (also) called a peering policy and a set of rules that allows you to say ‘no’ for the more open end of the spectrum, or a set of very hard requirements to meet for the more restrictive end. A common policy, often difficult to meet, is a requirement for balanced traffic exchange between the networks. This is popular among transit networks and removes the discussion with potential customers who want to be a peer instead.
Why say no to peering?
There are other valid reasons to want the ability to decline peering with a specific network, even when your business doesn’t sell Internet access to other networks. A wish or need to reduce operational overhead is one example, load on edge routers is another. As every network and organization is different, so are the specific reasons.
What we do at RouteViews
RouteViews exists to collect BGP routing tables and updates, archive them, and make the data available to the Internet operations and research communities. We call this taking snapshots of the Internet. From that perspective, we have operated with an open peering policy until now, since more peering would give us more data.
However, the landscape of Internet routing data collection is evolving, as demonstrated by our sister project. The Routing Information Service (RIS), maintained by RIPE NCC, introduced a selective policy some years ago. Along with that came a proactive approach to ensure that collected data would still be useful.
RIS’s choice of metrics for the usefulness is:
- The number of routes — do we have every prefix on earth?
- Closeness to the origin of prefixes, grouped economy — what is the local reach per economy?
These are good metrics. And it looks like RIS is successful with their approach. With this context in mind, let’s understand why we’re making changes to our peering policy.
What is a snapshot of the Internet?
Key aspects, of course, are which prefixes are announced by who, the messages that are sent between the peers. Another consideration used by peering coordinators and network planners is who is connected to who and how.
Why is this interesting? Folks in the peering community work hard every day to safeguard the resilience and security that densely connected networks have because it is widely accepted that this gives the best control of how your originated traffic reaches its destination and how the traffic into your network arrives the best possible way. When you want to analyse and evaluate a new potential peer, or even a new market for your services, information on how everyone is connected is in high demand.
The changing Internet landscape
In the old-fashioned Internet, where traffic flowed up and down in the ‘tier 1’, ‘tier 2’, and ‘access network’ hierarchy, it was easier to take a snapshot of the connections where the Internet traffic flows than now. Today the large traffic volumes flow on the edges of the Internet, to and from Content Delivery Networks (CDNs) and clouds that are deployed close to consumers. This interconnectivity information does not propagate up in the old hierarchy but must be collected directly from the edge players and on the edge.
In the traditional hierarchical Internet, RouteViews’ open peering policy captured the most relevant routing relationships. However, today’s flat Internet architecture requires us to be more strategic about where and with whom we peer to capture what is happening on the edge.
How RouteViews data is used by the community
RouteViews data is widely used by researchers, vendors and operators throughout the world. Debugging routing issues, monitoring prefixes to discover and mitigate hijacks, understanding the evolution of the Internet, the deployment of new protocols and security technologies and the evolution of the topology of the Internet are just some of the ways our data is being used. The data is freely available for everyone — peers as well as non-peers.
RouteViews Peering Policy
With these considerations in mind, here is RouteViews’ new Peering Policy:
General requirements:
- Peers must operate stable equipment — RouteViews will shutdown BGP sessions that disturb the stability of the RouteViews platform.
- Peers must have a routable Autonomous System Number (ASN).
- Peers must not be a hobby network.
- Peer’s full view of the global routing table is preferred.
- Routes should be aggregated as much as possible (no longer than /24 for IPv4 and /48 for IPv6).
- Peers must be present with up-to-date information in PeeringDB — including the Network Operations Centre email address.
- Peers must filter RFC 6890 space.
- RouteViews does not accept addpath-RX or TX.
- Peers must not send default routes.
IXP peering:
- We happily accept everyone’s routes from the route servers.
- We will set up bilateral sessions with anyone who meets the general requirements and will send us their full table.
- We will peer at all mutual exchanges if requested.
Multihop peering:
- We will accept multihop peers who are not on any mutual IXPs.
- Peers must provide their full view of the Internet as they see it.
- We accept two sessions for redundancy; more than two sessions can be set up if the feeds are sufficiently different.
Peering is ultimately at the discretion of the RouteViews peering coordinator. Policy and peering availability are subject to change without notice. The RouteViews peering coordinator may also decide in exceptional circumstances to agree to set up, for example, bilateral sessions with peers who will only send us peering routes at exchanges, or multihop sessions with peers who can only provide partial routes.
Key considerations
We believe this policy will help us balance valuable data for the community and a stable and reliable platform. Let’s examine some key requirements that are specific to RouteViews and why they matter:
No hobby networks: We love that people run networks to learn and experiment. However, hobby networks often need extensive support and disproportionately impact collector stability. To maintain reliable service for everyone, we’re focusing on production networks.
Full tables: This is the requirement that lets us see more than the customer cones of transit networks and the originating prefixes of everyone else (a customer cone is the customers and their downstreams of a transit network). The full tables are a requirement in order to be able to derive who is connected to who and how, as the usual peering configuration does not show any peering connections.
If you can’t announce full tables and you are on the routeserver, we do not want to use resources on bilateral sessions since we are already getting all the information that you can provide. If you are not able to announce the full table and are not using the routeserver, but have an interesting set of routes, we will consider peering with you.
What makes a peer interesting?
‘Interesting’ can mean many things. It could be:
- Networks in regions where we have limited visibility.
- Networks demonstrating new interconnection patterns.
- Networks using innovative routing practices.
- Networks that help us understand emerging market dynamics.
Or, maybe something we haven’t thought about yet.
How to get started with peering with RouteViews
If you want to support us by peering, please let us know by writing to: help@routeviews.org.
What else is new?
Over the past year, we have hired more people for our team. Every aspect of the project is being modernized and upgraded. We are working on the backend architecture, upgrading storage hardware, developing new ways to make the data available for our community using modern technologies, and expanding the collector network and our peering. So stay tuned — more news will come.
Nina Bargisen is the RouteViews Peering Coordinator.
This post is adapted from the original at RouteViews Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.