Looking at the capabilities of any given protocol running in our networks today, it certainly seems there are few use cases left the protocol cannot support. In fact, modern interior gateway protocols have become so capable that it almost seems like we only need one to support everything. This is not reality, of course—there are many places where a specialized protocol would do better than a general purpose one, and there are still many use cases current protocols cannot support. One such use case, for OSPF, illustrated below, uses a two part metric to solve a very specific problem, as illustrated below.
On the left side of this diagram you can see the “typical” broadcast network. Originally common in what used to be called local area networks, these sorts of broadcast segments are actually more common on metro edges and wireless networks today than in a campus or data center. Anyone familiar with OSPF should already know what the problem is with this sort of configuration—if you build an adjacency between every pair of routers illustrated here, you end up with just too much state. For instance—
- Each pair of routers in the network will form an adjacency, and hence exchange a full copy of the link state database. This means each change in the network topology or reachability information will cause at least three different flooded packets to cross this segment to report the change (and it is likely more!).
- When building the shortest path tree (SPT), each router in the network will need to find the path through each one of the routers connected to this broadcast segment. This means the SPT will show three possible paths through this single network from the perspective of every router in the network.
This problem is resolved in OSPF through the creation of a pseudonode (pnode), as shown on the right side of the illustration above. One of the routers connected to the network is elected to advertise a network node Link State Advertisement (LSA). Each of the routers connected to the network then advertises a link to this network LSA (a type 2 LSA in OSPFv2, for reference). The pnode then advertises a zero cost link back to each router connected to the network.
So far, so good—this is all fairly standard stuff.
How is the total cost through this network calculated? When moving from any node to the pnode, the cost the node is advertising is used to calculate the cost. Moving from the pnode to the other side of the network, however, the cost is set to zero.
But what if the cost from, say, router A to the network is different from the cost from router B? In some situations, it is quite possible for these two routers to have different speed links onto the common broadcast network. Think metro Ethernet, for instance, or a wireless network, or perhaps a satellite link.
In this situation, there is no way to express the reality that the cost from A to B is different than the cost from A to C because B and C have different access speeds. The only metric calculated into the cost to cross the network is from A to the pnode; the cost from the pnode to either B or C is always 0.
RFC8042 provides a fix for this problem. But before getting to the fix, there is one more problem to be addressed. Assume A is elected to build and transmit the pnode (A is the designated router). How should A discover the cost to every other router connected to the network from to perspective of the pnode? This, in fact, is a major problem.
How does RFC8042 fix this problem? By adding a new TLV into the OSPF router advertisment that allows a router to advertise its cost to reach the pnode. This is called a two part metric. When B advertises its connection to the pnode, then, it can include the cost from the pnode to itself in this new TLV. In the case of OSPFv2, this new information is carried in a TLV in an opaque LSA; in the case of OSPFv3, this new metric is carried as part of the traffic engineering TLV.
When a router calculates the cost through the network, when it encounters a network LSA (which represents a pnode), it will—
- Calculate the cost to the pnode using the metric advertised by the node pointing to the pnode. This is the “entry point” into the broadcast network; this cost is already included in the calculation of the SPT today.
- Add the cost from the new TLV in the information provided by the router the pnode points to. This is the new information that allows the calculating router to determine the best path through the network including the cost from each node to the network itself.
This might not be really useful in a lot of networks, but where it is useful, it is almost essential to properly calculating a truly optimal shortest path through the network. From a complexity perspective, state has been added to increase optimization; that these two are being traded off here is no surprise.
Some folks over at the Network Collective thought it would be cool to sit around with folks who invented various networking technologies and just talk about the where, why, and how of those technologies were invented. Donald Sharp and I, while not officially a part of the collective, are hosting this new video cast, and the first edition just published.
For this videocast, we’re sitting down with Fred Baker to talk about the origins of Quality of Service. Hopefully we will have Fred on again in the future to talk about Raven and some of the history around network surveillance. You can watch it here, or you can jump over to the main Network Collective site and watch it there.
I sat with Greg, Kathleen, and Alia to talk about “ordinary engineers” getting involved in the IETF while we were in Prague. Believe it or not, this time I didn’t get out into the city at all other than walking between the hotel I was staying at and the venue hotel. I try to always take “one day off” and do something around the city we are in, but the schedule didn’t allow it this time. Anyway, here is the link—
Greg Ferro attended the IETF 99 meeting in Prauge in July 2017. In this Priority Queue show, he sits down with Kathleen Moriarty, an IETF Security Area Director; Alia Atlas, a Routing Area Director; and Russ White, a co-chair of a variety of working groups and all-around community leader; to discuss opportunities for IT professionals to get directly involved with the IETF in networking, security, and other areas. —Packet Pushers
As I spend a lot of time on Oak Island (not the one on television, the other one), I tend to notice some of those trivial things in life. For instance, when the tide is pretty close to all the way in, it probably is not going to come in much longer; rather, it is likely to start going back out soon. If you spend any time around clocks with pendulums, you might have noticed the same thing; the maximum point at which the pendulum swings is the point where it also begins swinging back. Of course my regular readers are going to recognize the point, because I have used it in many presentations about the centralization/decentralization craze the networking industry seems to go through every few years.
Right now, of course, we are in the craze of centralization. To hear a lot of folks tell it, in ten years there simply are not going to be routing protocols. Instead, we are going to all buy appliances, plug them in, and it is “just going to work.” And that is just for folks who insist on having their own network—for the part of the world that is not completely consumed by the cloud.
But remember, when the tide seems highest…
This last week an article in another part of the information technology world caught my eye that illustrates the point well enough that it is worth looking at. Almost everyone in IT knows, of course, that Moore’s law is dying; there is not much hope that we will be able to double the number of transistors in a processor forever. Not that there ever was any hope that this could go on forever, but it does seem like there was a long stretch there where all you had to do was wait a couple of years, and you could buy a processor that was twice as fast, and twice as powerful.
Note: I wonder how many people have considered that maybe the PC is not “going away,” but rather that sales are slowing down, at least in part, because unboxing a new one no longer means a major performance boost?
The problem is, of course, that processing needs are not slowing down in line with the death of Moore’s law. What is the solution to this problem? Bespoke processors.
It’s a well-known and necessary truth: In order to have programmability and flexibility, there’s simply going to be more stuff on a processor than any one application will use. —Samuel K. Moore @ IEEE Spectrum
What is happening is no less than a revolution in the idea of how a processor is built. Rather than building a processor that can do anything, companies are now starting to build a processor that can do one thing really well, with a minimum of overhead (such as power and cooling).
What really set me to thinking about this is the news that the Apple iPad actually carries a specialized processor, the most current version of which seems to be the A11 and A11X. This isn’t quite a bespoke processor, of course, because tablets are still designed to do a wide range of tasks. But lets not forget the Network Processing Units (NPUs, which we normally just call ASICs) housed in most routers and switches. Nor the Graphics Processing Units (GPUs) housed in most video systems and electronic currency mining operations.
What we are actually seeing in the processor world is the beginning of the end of the centralized model. No longer will one processor solve “every” problem; rather computers will need to become, must become, even more of a collection of processors than they have ever been in the past. But this is the key, isn’t it? The centralized model will continue alongside the decentralized model, each solving different sorts of problems. There will be no “one processor to rule them all.”
Now let’s turn to the networking world. Once you build a single network that can solve every problem, you will no longer need the “others,” correct? Isn’t this just what we were promised in the processor world? One processor that could solve “every” problem?
If it doesn’t work for processors, why do we think it will work for networks? There is no analog to Moore’s Law in the networking world, but perhaps there should be—because unlike the processing world, we cannot see when we are about to “hit the wall,” and a new wave of decentralization is going to take place.
But it will, at some point. Bespoke networks are not, contrary to the current hype, a thing of the past, any more than the GPU and the NPU seemed to be things of the past just a few short years ago. In the real world, there is always value to be had in removing functionality that does not need to be there, just as much as there is value to be had in adding functionality.
The question is not whether or not there will still be bespoke networks in five years. The question is: what will these networks look like? This new wave of decentralization will not look like the current appliance based model—this much is a given—just like modern bespoke processors are not going to look like the older generations of purpose built processors.
The task of network engineers is not to simply jump ship into the centralized world. The job of network engineers is to figure out just what the “new” decentralized is going to look like, and help build it.