Power Prefixes Prioritization for Smarter BGP Reconvergence Juan Brenes Marcelo Bagnulo Alberto García-Martínez Andra Lutu Cristel Pelsser

Wait... What!? We propose a simple change over the convergence algorithm to reduce the impact of BGP failure events. Our proposal does NOT require any change in the protocol The traffic losses are reduced by one order of magnitude. The what I think is clear from the title. We are going to talk about BGP or Border Gateway Protocol which is a protocol designed to exchange routing information between different Autonomous Systems (or Ases) This is the protocol that glues Internet together nowadays, and considering the size and complexity of this network we can safely say that BGP is really doing a good job distributing the routes. However, when it comes to failures, BGP is known to converge extremely slow. It takes around 15 seconds for a router to inform its neighbors a about the routes involved in a failure, and it may even take tens of minutes to Internet in general to convey this failure.

OK...But why? MONEY: Service Level Agreements. CDNs & other Internet services ISPs Service Level Agreements. Delay sensitive services in Internet.

Lot of previous research… but Most of them are based in: Decrease the time it takes to converge. Decrease the amount of information exchanged. Usually require changes in the protocol Not universally aplicable: PIC and ADD-PATH with Next-hop self

We follow a completely different approach based on 3 observations.

1) A single BGP event may affect a large number of prefixes. The first one...Most of the times when a link fails in BGP, the amount of routes involved is hughe. We are talking about hundreds of thousands of routes. Around 600k for BGP in the internet and worst for BGP-MPLS Vpns The second one… the routes involved in a large failure converge at different times. Every time there is a failure the routes has to iterate through its routing table and this is a sequential operation. Even if we somehow solve this, the routes are sent as a list which is inherently sequential. And the third one...The traffic to the routes is not evenly distributed. For instance, lets imagine Im a Finish ISP, for sure there is going to be much more traffic towards routes in USA, than traffic towards Uruguay. It has largely been assessed that this traffic distribution follows a zipf (which is a power-law).

2) The time it takes for BGP to restore reachability after a BGP event that affects a large number of routes is different for each of the prefixes affected.

3) In practice only a small number of prefixes are relevant for the AS operation.

PPP proposes to significantly reduce the impact of a failure event by ensuring that the most relevant routes converge before routes to less relevant prefixes. So based in these three observations, our idea is very simple. We propose to reduce the amount of… Basically this means to have a list which will determine the order in which each router is going to send the updates. Let me show just a quick animation illustrating how everything works right now, and which is the change that we propose.

The implementation is just a list!!! ...it is giving control in the order …we wanted results

We verified the results of our algorithm using real ISP traces 2 datasets (2014 and 2015) containing traces from a ISP to its transit provider. We used the amount of traffic as the ranking parameter. BGP dumps to match the destinations.

Variables For how long can we use the same ranking? (validity period) Does the time of taking the samples affect? (measuring interval) Is it efficient to sample the traffic? (sampling rate)

We use the ratio of traffic loss . We calculate the traffic losses at a given moment using lexicographical order. We calculate the traffic losses at a given moment using a PPP rank. We use the ratio between these two numbers as a comparing mechanism.

Validity period

Validity period 100pps

Sampling rate analysis

We modified bgp quagga BGP-PPP uses a list of prefixes to establish the orders of the updates. Prefix ranks obtained from the 24-hour measuring interval, using different sampling rates. 15-second bins from the 3 days after the predictor dataset.

Topologies – Full-mesh

Topologies – Route-reflector

Results

Conclusions We can do better without changing the protocol itself! PPP is universally applicable. It is feasible to automatically generate the ranks using the amount of traffic.

It is my turn now! Suggestions in how to follow? IETF? Shall we extend this?