The Routing Preference Protocol
Brought to you by BORDER 6, the BGP optimization company
The Internet is controlled by a single protocol: BGP. This protocol proved to be robust, fast and extremely scalable. It is not ideal, though, since it only provides a way of exchanging prefixes between peers, without any regard to how we, admins, would like the actual traffic to be distributed over our links.
Typical problem: most of my outbound traffic goes out via T1, while most of my inbound traffic comes in via T2
Half of the problem is easy to solve
Controlling the 'outbound' traffic is pretty easy - either with some smart scripting or using specialized optimization solutions. Either way, controlling the outbound traffic from my AS is no big concern. The real problem appears when it comes to controlling the *inbound* traffic. How do I force my peers to send me traffic the way I would like? Sure, some voodoo techniques exist: applying AS-Prepends to what I announce, tagging my bgp exports with some communities that my upstream would react to, or even choosing not to announce some of my prefixes to some of my neighors. All this require application of tricky logic, constant supervision and never-ending maintenance.
One could say now 'hey, but this is exactly why LISP came around!'. And that would be correct. LISP is a protocol created from ground up with the exact purpose of solving most of Internet's today troubles. LISP is, however, a quite complex protocol that requires new infrastructures to be deployed all over the planet (MAP servers, LISP-aware routers, etc...). This ain't gonna happen overnight. One of the biggest complications with LISP is that it relies on tunneling for controlling the path that packets should be sent over.
Is tunneling really necessary?
Nowadays, the Internet is a very, very meshed network. Everybody peers with everybody and their dog - not only at the big player's level, but even leaf ASes often have many direct peerings with a variety of neighbors, or at the very least a few tier-1 transit providers. During our research, we noticed that an AS equipped with several transit services often has sufficient path diversity to select an acceptable outbound path towards almost any destination.
In the above example we see that AS1 can choose multiple paths to AS2, and some of them will end up on different inbound points on the AS2 side. This means that if only AS2 had some way to tell AS1 'please do your best to send me packets over my T2 peering', AS1 could make it happen.
That's where RPP comes into play
RPP stands for 'Routing Preference Protocol'. At the current stage it's more of an idea rather than a technical reality, though. RPP is a very simple protocol that allows Autonomous Systems to communicate inbound routing preferences to each other. See the tech page for details.