RESPONSE

Every now and again (not often enough, if I’m to be honest), someone will write me with what might seem like an odd question that actually turns out to be really interesting. This one is from Surya Ahuja, a student at NC State, where I occasionally drop by to do a guest lecture.

We were recently working on an example design problem in one of our courses, and like a dedicated student I was preparing the State, optimisation, surface sheet 🙂 One of the design decisions was to explain the selection of the routing protocol. This got me thinking. When BGP was being created, were there modifications to OSPF itself considered? … it could have been made possible to just use OSPF across enterprise and the internet. Then why not use it?

A quick answer might go somethign like this: OSPF did not exist when BGP was invented. The IETF working group for OSPF was, in fact, started in 1988, while the original version of BGP, called EGP, was originally specified by Eric Rosen in 1982, some 6 years earlier. The short answer might be, then, that OSPF was not considered because OSPF had not been invented yet. 🙂

But this quick answer is really more tongue-in-cheek than useful, because the concept of a link state protocol is actually much older than the concept of a path vector protocol. EGP and BGP are, in fact, the very first path vector protocols, while the fundamental algorithms that underpin link state protocols were invented in the mid-1950’s into the 1960’s. For instance, Dijkstra’s shortest path first algorithm was initial invented in 1956.

So I’m going to back up a little and rephrase the question: if link state protocols existed at the time EGP and BGP were invented, why didn’t the original designers create a link state protocol, like OSPF, to run the core of the ‘net?”

The initial response is likely to be: because link state protocols just won’t scale to the point of supporting the core of the ‘net. This answer, however, is wrong. With optimized flooding, topology summarization, and route aggregation, it is quite possible to scale a link state protocol to the scale of the DFZ. Simply force the entire ‘net into a hierarchical model—the topology of the ‘net was, in fact, largely hierarchical in the early days—intelligently assign addresses, and you could, in fact, scale a link state protocol to the entire Internet. It would have been difficult, and it would have constrained the development of the Internet in several important ways, but it would have been possible.

To understand why a link state protocol was not chosen, you have to dig into the design considerations behind BGP. Go back to “the napkin” and consider what is drawn there.

Click to enlarge, if you need to.

Mostly what you will see is policy. The original design of BGP was primarily concerned with implementing interdomain policy.

Now step back one level, and ask a simple question: how good is a link state protocol at implementing policy, especially on a per-node basis? Before answering, consider the way in which link state protocols operate. Each router must have a complete copy of the Link State Database (LSDB) in order to calculate loop free paths through the network. To go even a bit deeper in theory, the “shortest path” is really just a short hand for a “loop free path.” Once you inject policy into the decision process, you are implying it is okay to take a slightly longer path (a stretched path) instead of the shortest path—so long as it is still loop free. How would you implement policy on a protocol in which every router (or node) in the network must share a common view of the network, when the concept of policy itself implies different views of the available paths for different nodes?

You don’t.

So the primary reason a link state protocol was not ultimately used to build the core of the Internet is not scale. It’s policy.

I know people pooh-pooh theory and history in the networking world, but … perhaps this will serve as a simple illustration of how understanding the protocols themselves, and how they work, can help you understand what to deploy where and why.

Recently, I posted a video short take I did on BGP optimal route reflection. A reader wrote in the comments to that post:

…why can’t Router set next hop self to updates to router E and avoid this suboptimal path?

To answer this question, it is best to return to the scene of the suboptimality—

To describe the problem again: A and C are sending the same route to B, which is a route reflector. B selects the best path from its perspective, which is through B, and sends this route to each of its clients. In this case, E will learn the path with a next hop of A, even though the path through C is closer from E’s perspective. In the video, I discuss several ways to solve this problem; one option I do not talk about is allowing B to set the next hop to itself. Would this work?

Before answering the question, however, it is important to make one observation: I have drawn this network with B as a router in the forwarding path. In many networks, the route reflector is a virtual machine, or a *nix host, and is not capable of forwarding the traffic required to self the next-hop to itself. There are many advantages to intentionally removing the route reflector from the forwarding path. So while setting nexthop-self might work in this situation, it will not work in all situations.

But will it work in this situation? Not necessarily. The shortest path, for D, is through C, rather than through A. B setting its next hop to itself is going to draw E’s traffic towards 100::/64 towards itself, which is still the longer path from E’s perspective. So while there are situations where setting nexthop-self will resolve this problem, this particular network is not one of them.