Rethinking BGP on the DC Fabric
Everyone uses BGP for DC underlays now because … well, just because everyone does. After all, there’s an RFC explaining the idea, every tool in the world supports BGP for the underlay, and every vendor out there recommends some form of BGP in their design documents.
I’m going to swim against the current for the moment and spend a couple of weeks here discussing the case against BGP as a DC underlay protocol. I’m not the only one swimming against this particular current, of course—there are at least three proposals in the IETF (more, if you count things that will probably never be deployed) proposing link-state alternatives to BGP. If BGP is so ideal for DC fabric underlays, then why are so many smart people (at least they seem to be smart) working on finding another solution?
But before I get into my reasoning, it’s probably best to define a few things.
In a properly design data center, there are at least three control planes. The first of these I’ll call the application overlay. This control plane generally runs host-to-host, providing routing between applications, containers, or virtual machines. Kubernetes networking would be an example of an application overlay control plane.
Controversial Reading 013021: Freedom of Speech
In the past, I have blended links of a more controversial nature about culture, technology, and governance into my weekend reads posts. There has been so much, however, on the situation with social media platforms blocking prominent people, and the Parler takedown, that it seemed worth setting aside an entire post containing some of the interesting things I’ve run across on these topics. I may, from time to time, gather up more controversial sets of reading into separate posts in the future, so people can skip (or read) them if they want to.
Infrastructure companies much closer to the bottom of the technical “stack”— including Amazon Web Services (AWS), and Google’s Android and Apple’s iOS app stores—decided to cut off service not just to an individual but to Continue reading
The Hedge Podcast #66: Daniel Migault and the ADD Working Group
The modern DNS landscape is becoming complex even for the end user. With the advent of so many public resolvers, DNS over TLS (DoT) and DNS over HTTPS (DoH), choosing a DNS resolver has become an important task. The ADD working group will, according to their page—
In this episode of the Hedge, Daniel Migault joins Alvaro Retana and Russ White to discuss Requirements for Discovering Designated Resolvers, draft-box-add-requirements-02.
Agglutinating Problems Considered Harmful (RFC2915, Rule 5)
In the networking world, many equate simplicity with the fewest number of moving parts. According to this line of thinking, if there are 100 routers, 10 firewalls, 3 control planes, and 4 management systems in a network, then reducing the number of routers to 95, the number of firewalls to 8, the number of control planes to 1, and the number of management systems to 3 would make the system “much simpler.” Disregarding the reduction in the number of management systems, scientifically proven to always increase in number, it does seem that reducing the number of physical devices, protocols in use, etc., would tend to decrease the complexity of the network.
The wise engineers of the IETF, however, has a word of warning in this area that all network engineers should heed. According to RFC1925, rule 5: “It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.” When “conventional wisdom” and the wisdom of engineers with the kind of experience and background as those who write IETF documents contradict one another, it is worth taking a deeper look.
A good place to begin is Continue reading
Focus is a Virtue
The modern world craves our attention—but only in short bursts. To give your attention to any one thing for too long is failing, it seems, because you might miss out on something else of interest. We have entered the long tail of the attention economy, grounded in finding every smaller slices of time in which the user’s attention can be captured and used.
The problem is obvious for anyone with eyes to see. What is the solution? The good news is there are solutions. The bad news is these solutions are swimming upstream against the major commercial interests of our day, so it’s going to Continue reading
Weekend Reads 012221
or perhaps the friday fifteen …
Defining and measuring programmer productivity is something of a great white whale in the software industry. It’s the basis of enormous investment, the value proposition of numerous startups, and one of the most difficult parts of an engineering manager or Continue reading
The Hedge Podcast 67: Daniel Beveridge and the Structure of Innovation
Innovation and disruption are part the air we breath in the information technology world. But what is innovation, and how do we become innovators? When you see someone who has invented a lot of things, either shown in patents or standards or software, you might wonder how you can become an innovator, too. In this episode of the Hedge, Tom Ammon, Eyvonne Sharp, and Russ White talk to Daniel Beveridge about the structure of innovation—how to position yourself in a place where you can innovate, and how to launch innovation.
The History of the Cisco TAC
The Cisco Technical Assistance Center, or TAC, was as responsible for the growth of computer networking as any technology or other organization. TAC trained the first generation of network engineers, both inside Cisco and out, creating a critical mass of talent that spread out into the networking world, created a new concept of certifications, and set a standard that every other technical support organization has sought to live up to since. Join Joe Pinto, Phil Remaker, Alistair Woodman, Donald Sharp, and Russ White as we dive into the origins of TAC.
IPv6 Buzz: Is IPv6 Baked Enough?
I was recently a guest on the IPv6 Buzz podcast. Ed, Scott, Tom, and I talk about IPv6 operational maturity, IPv6 standards, and the IETF process. This was a great episode, you should really listen to it … and listen to IPv6 Buzz in general.
God Objects Considered Harmful
Every software developer has run into “god objects”—some data structure or database that every process must access no matter what it is doing. Creating god objects in software is considered an anti-pattern—something you should not do. Perhaps the most apt description of the god object I’ve seen recently is you ask for a banana, and you get the gorilla as well.
We seem to have a deep desire to solve all the complexity of modern networks through god objects. There was ATM, which was going to solve all our networking problems by allowing the edge device (or a centralized controller) to control the path its traffic takes through the network. There is LISP, which is going to solve every mapping and tunneling/transport problem in the entire networking world (including mobility and security). There is SDN, which is going to solve everything by pushing it all into a controller.
And now there is BGP, which can be a link state protocol (LSVR), the ideal DC fabric control plane, the ideal interdomain protocol, the ideal IGP … a sort-of distributed god object that solves everything, everywhere, all the time (life in the fast lane…).
The problem is, a bunch of people Continue reading
Webinar: How the Internet Really Works Part 1
On the 22nd, I’m giving a three hour course called How the Internet Really Works. I tried making this into a four hour course, but found I still have too much material, so I’ve split the webinar into two parts; the second part will be given in February. This part is about how systems work, who pays for what, and other higher level stuff. The second part will be all about navigating the DFZ. From the Safari Books site:
This training is designed for beginning engineers who do not understand the operation of the Internet, experienced engineers who want to “fill in the gaps,” project managers, coders, and anyone else who interacts with the Internet and wants to better understand the various parts of this complex, global ecosystem.
Hedge #66: Tyler McDaniel and BGP Peer Locking
Tyler McDaniel joins Eyvonne, Tom, and Russ to discuss a study on BGP peerlocking, which is designed to prevent route leaks in the global Internet. From the study abstract:
Technologies that Didn’t: ARCnet
In the late 1980’s, I worked at a small value added reseller (VAR) around New York City. While we deployed a lot of thinnet (RG58 coax based Ethernet for those who don’t know what thinnet is), we also had multiple customers who used ARCnet.
Back in the early days of personal computers like the Amiga 500, the 8086 based XT (running at 4.77MHz), and the 8088 based AT, all networks were effectively wide area, used to connect PDP-11’s and similar gear between college campuses and research institutions. ARCnet was developed in 1976, and became popular in the early 1980’s, because it was, at that point, the only available local area networking solution for personal computers.
ARCnet was not an accidental choice in the networks I supported at the time. While thinnet was widely available, it required running coax cable. The only twisted pair Ethernet standard available at the time required new cables to be run through buildings, which could often be an expensive proposition. For instance, one of the places that relied heavily on ARCnet was a legal office in a small town in north-central New Jersey. This law office had started out in an older home over a Continue reading
Master Class: DC Fabrics
I’m teaching another master class over at Juniper on the 13th at 9AM PT:
Spine-and-leaf fabric is the “new standard,” but how much do you know about this topology, its origins, and its properties? This session will consider the history of the Clos, explain the butterfly and Benes, look at why a fabric is a fabric and why “normal networks” are not, and cover some key design considerations when building a fabric.
The Hedge Podcast #65: Jacquelyn Adams and the Future of Work
Everyone in networking—and beyond networking, in fact—thinks about what the future of work might look like. Jacquelyn Adams joins Eyvonne Sharp, Tom Ammon, and Russ White on this episode of the Hedge to discuss what work might look like based on this era of rapid change, and how you can prepare for that future.
George Sadowsky on the History of Networking
George Sadowsky was a pioneer in recognizing the importance of networking technology for economic development, particularly in developing economies. He has worked in over 50 countries to bring training and networking infrastructure to the local population. In this episode of the History of Networking, George recounts some of the early, pre-Internet, work in computer networking, and the development of many of the organizations that make the Internet work today. His web site can be found here.
The OSI Model: STOP IT!
The OSI model is perhaps the best-known—and perhaps the most-loved—model in the networking world. It’s taught in every basic networking course, and just about every blog (other than this one) has some article explaining the model someplace or another (for instance, here is one of the better examples).
The reality is, however, that I’ve been in the networking business for 30’ish years and I’ve never once used the OSI model for anything practical. I’ve used the model when writing books because just about every book on networking has to have a section on the OSI model. I’ve used the model when writing a paper comparing two different protocols, back in the multiprotocol days (VIP versus IPX versus IP), but we don’t have those kinds of arguments very often any longer.
So, we all learn the OSI model, and yet I don’t know of anyone who actually uses the OSI model in understanding how protocols work, or how to troubleshoot a network. There’s the “it’s a layer two problem” statement, and that’s about the end its useful life, it seems.
Let me make a suggestion—learn, use, and teach the RINA model instead. Okay, so what is the RINA model? It is Continue reading