Instead of thinking about developing a new BGP, maybe we should stop trying to use it as the trash can of the Internet.
From time to time, I run across (yet another) article about why Border Gateway Protocol (BGP) is so bad, and how it needs to be replaced. This one, for instance, is a recent example.
It seems the easiest way to solve this problem is finding new people — ones who don’t make mistakes — to work on BGP configuration, building IRR databases, and deciding what should be included in BGP. That said, Ivan Pepelnjak points out how hopeless of a situation this would be.
As Ivan says, you cannot solve people problems with technology. You can hint in the right direction, and you can try to make things a little saner, and a little less complex, but people cannot be fixed with technology.
Given that we cannot fix the people problem, would replacing BGP itself really help? Is there anything we could do to make things better?
Read Geoff Huston’s take onBGP in 2017
To understand the answer to these questions, it is important to tear down a major misconception about BGP: that being BGP is a routing protocol in the same sense as OSPF, IS-IS, or EIGRP.
BGP was not designed to be a routing protocol in the way other protocols were
It was designed to provide a loop-free path through a series of independently operated networks, each with its own policy and business goals. In the sense that BGP provides a loop-free route to a destination, it provides routing. But the ‘routing’ it provides is largely couched in terms of explicit, rather than implicit, policy (see the note below).
Loop-free routes are not always the ‘shortest’ path in terms of hop count, or the ‘lowest cost’ path in terms of delay, or the ‘best available’ path in terms of bandwidth, or anything else. This is why BGP relies on the AS Path to prevent loops. We call things ‘metrics’ in BGP in a loose way, but they are really explicit expressions of policy.
Consider this: the primary policies anyone cares about in inter-domain routing are, “where do I want this traffic to exit my AS?”, and “where do I want this traffic to enter my AS?”.
The Local Preference is an expression of where traffic to this particular destination should exit this AS. The Multiple Exit Discriminator (MED) is an expression of where this AS would like to receive traffic being forwarded to this destination. Everything other than these are just tiebreakers.
Read BGP more specifics: routing vandalism or useful?
All the rest of the stuff we do to try to influence the path of traffic into and out of an AS, such as messing with the AS Path, are hacks. If you can get this pair of ‘things people really care about’ into your head, the BGP best-path process, and much of the routing that goes on in the DFZ, makes a lot more sense.
It really is that simple.
How does this relate to the problem of replacing BGP?
There are several things you could improve about BGP, but ‘automatic metrics’ are not one of them. There are, in fact, already automatic metrics in BGP, but automatic metrics like the IGP cost are tiebreakers.
A tiebreaker is a convenient stand-in for what the protocol designer and/or implementer thinks the most natural policy should be. Whether or not they are right or wrong in a specific situation is a guess.
What about something like the RPKI?
The RPKI is not going to help in most situations where a human makes a mistake in a transit provider. It would help with transit edge failures and hijacks, but these are a different class of problem.
You could ask for BGPsec to counter these problems, of course, but BGPsec would likely cause more problems than it solves (I’ve written on this before, here, here, here, here, and here, to start; you can find a lot more on rule11 by following this link).
What else can be done?
Given replacing the metrics is not a possibility, and RPKI is only going to get you so far, what else can be done?
There are, in fact, several practical steps that could be taken.
You could specify that BGP implementations should, by default, only advertise routes if there is some policy configured. Something like, say… RFC8212?
Giving operators more information to understand what they are configuring — perhaps by cleaning up the Internet Routing Registries? — would also be helpful. Perhaps we could build a graph overlay on top of the Default Free Zone (DFZ) so a richer set of policies could be expressed, and policies could be better observed and understood (but you have to convince the transit providers that this would not harm their business before this could happen).
Maybe we could also stop trying to use BGP as the trash can of the Internet, throwing anything we don’t know what else to do with into it. We’ve somehow forgotten the old maxim that a protocol is not done until we have removed everything that is not needed. Now our mantra seems to be “the protocol isn’t done until it solves every problem anyone has ever thought of”. We just keep throwing junk at BGP as if it is the abominable snowman — we assume it’ll bounce when it hits bottom. Guess what: it’s not, and it won’t.
Replacing BGP is not realistic — nor even necessary. Maybe it is best to put it this way:
- BGP expresses policy
- Policy is messy
- Therefore, BGP is messy
We definitely need to work towards developing good engineers and good tools — but replacing BGP is not going to ‘solve’ either of these problems.
Author note: I have differentiated between ‘metrics’ and ‘policy’ here but metrics can be seen as an implicit form of policy. Choosing the highest bandwidth path is a policy. Choosing the path with the shortest hop count is a policy too. The shortest path (for some meaning of ‘shortest’) will always be probably loop-free, so it is a useful way to always choose a loop-free path in the face of simple, uniform, policies. But BGP doesn’t live in the world of simple uniform policies; it lives in the world of ‘more than one metric’. BGP lives in a world where different policies not only overlap but directly compete. Computing a path with more than one metric is probably at least bi-stable, and often completely unstable, no matter what those metrics are.
Original post appeared on Rule 11
Russ White is a Network Architect at LinkedIn.
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.
