Why not OSPF for the Internet Core?
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.