Layer 2 Routing—Haven’t we been here before?

We often think the entire Internet, as we know it, just popped out of “thin air,” somehow complete and whole, with all the pieces in place. In reality, there have been many side roads taken, and many attempts to solve the problem of pushing the maximum amount of data across a wire along the way. One of these ways came to mind this last week, when I ran across this story—

Also on the virtualisation list is the customer premises equipment (CPE), and this deserves a little explanation. Obviously every premises needs some sort of physical connection to the network providing the services. What CPE virtualisation refers to is making the CPE as generic as possible. —The Register

Pulling layer 2 into the network to centralize the edge—where have I heard this before? Maybe it was all those years ago, when I was in TAC, and we used to support Cisco 1001’s, or the LEX—LAN Extenders. The promise then was the same as the promise now: a lightweight, easy to manage device that would relocate all the intelligence from the network edge into the access layer of the “mother ship,” where it could be properly managed.

Remember Rule 11? If you read this blog on a regular basis, you should.

But this time we have all the problems solved, right? We have SDNs to manage the policies, so we don’t need to carry all the broadcast traffic to the network core, and we have eVPNs and other neat technologies that allow us to actually forward layer 2 packets hop by hop. It’s not really routing, of course, because the layer 2 header isn’t being rewritten at every hop (the mark of true routing, no matter whether it’s done in software or hardware), but layer 2 routing is the closest I can come to the idea of a hybrid between routing and switching simpliciter.

So why do we do this? Because somehow we’ve come to equate routing with complexity, particularly on the application side. Look at the announcement I point to above again—there will be the ability to add services without changing hardware, and chain services, etc. What the article doesn’t say is why any of this requires layer 2 forwarding, rather than layer 3 forwarding. Can we not add services without changing hardware with a plain IPv6 box? Can we not chain services?

Of course we can—but we’ve tied our applications to layer 2 forwarding, and now we must make our networks cooperate. I suspect we’re going to find, at some point, that we really haven’t solved all the problems. CAP is hard to beat in real life, just another manifestation of the complexity triangle that seems to be built into the fabric of reality.

But the thought of layer 2 routing—this seems to be somehow familiar, as well, doesn’t it? I reached way back in my memory, and discovered that yes, we have indeed done this once before. It’s called CLNS. In fact, IS-IS, the most venerable of routing protocols in actual current use today, is grounded in the concept of host addresses on the front of packets that aren’t swapped out at every hop (see my recent IS-IS LiveLesson for more). IS-IS, within a flooding domain, is actually (in a real sense) layer 2 routing.

The more things change, the more they stay the same. Rule 11, indeed.

The question now is—or rather the question we should be asking is—what did we know then that we no longer know now?

Hence the power of thinking in the context of Rule 11.