Archive

Category Archives for "Russ White"

BGP Code Dive (1)

I often tell network engineers they need to learn to code—and they sometimes take my advice and run off to buy a book, or start an online program (which reminds me, I’m way, way behind in my own studies about right now). But learning to code, and being able to use that skill for anything are actually two different things. In fact, my major problem with my coding skills is finding projects I can undertake where I don’t feel like I’m wasting my time. Anyone want to write the world’s 25 millionth implementation of inserting the date and time into a document? No, I didn’t really think so.

code-diveSo what can you do with coding skills? One thing you can do is <em?read the source. Thus, I’m starting an entirely new feature here at ‘net Work. Every now and again (which means I don’t know how often), I’m going to poke at some routing or control plane code or another, and try to figure out what it actually does. Why not just go through a single protocol line by line? Because—honestly—it’s not a useful way to approach a protocol in code. Rather—here is my first bit of advice—you want Continue reading

On differential privacy

Over the past several weeks, there’s been a lot of talk about something called “differential privacy.” What does this mean, how does it work, and… Is it really going to be effective? The basic concept is this: the reason people can identify you, personally, from data collected off your phone, searches, web browser configuration, computer configuration, etc., is you do things just different enough from other people to create a pattern through cyber space (or rather data exhaust). Someone looking hard enough can figure out who “you” are by figuring out patterns you don’t even think about—you always install the same sorts of software/plugins, you always take the same path to work, you always make the same typing mistake, etc.

The idea behind differential security, considered here by Bruce Schneier, here, and here, is that you can inject noise into the data collection process that doesn’t impact the quality of the data for the intended use, while it does prevent any particular individual from being identified. If this nut can be cracked, it would be a major boon for online privacy—and this is a nut that deserves some serious cracking.

But I doubt it can actually be cracked Continue reading

Reaction: Complexity Sells

Over at IPSpace this last week, Ivan pointed to a paper by Dijkstra (and if you don’t know who that is, you need to learn a thing or two about the history of routing protocols—because history makes culture, and culture matters—or, as the tagline on this blog says, culture eats technology for breakfast). In this paper, Dijkstra points out some rather important things about computer science and programming that can be directly applied to the network engineering world. For instance, Ivan says—

People tend to forget that “doing away with the programmer” was COBOL’s major original objective. —Replace “programmer” with “networking engineer” and COBOL with SDN ?

I was fascinated with Ivan’s take on this paper—particularly in that complexity is an area I find interesting and very useful in my everyday life as a designer—that I went and read the original article. You should, too.

I think Ivan’s observations are spot on, but I think it’s worthwhile to actually broaden them. From where I sit, after 25 years building and breaking networks, I agree that complexity sells—but it sells for two particular reasons. The reason, as Dijkstra said all those years ago (in computer terms), is this:

Since the Continue reading

Getting to the point of dual homing

I wonder how many times I’ve seen this sort of diagram across the many years I’ve been doing network design?

dual-homing

It’s usually held up as an example of how clever the engineer running the network is about resilience. “You see,” the diagram asserts, “I’m smart enough to purchase connectivity from two providers, rather than one.”

Can I point something out? Admittedly it might not be all that obvious from the diagram, but… Reality is just about as likely to squish your network connectivity like a bug no a windshield as it is any other network. Particularly if both of these connections are in the same regional area. The tricky part is knowing, of course, what a “regional area” might happen to mean for any particular provider.

The problem with this design is very basic, and tied to the concept of shared link risk groups. But let me start someplace a little simpler than that—with the basic, and important, point that putting fiber in the ground, and maintaining fiber that’s in the ground, is expensive. Unless you live in Greenland, fiber can be physically buried pretty easily (fiber in Greenland is generally buried with dynamite by a blasting crew, or Continue reading