Cisco Live: Midweek Impressions

I’m at Cisco Live this week in Las Vegas; forthwith, some observations, thoughts, and… a long rant.

First, if you’re here, look me up. I normally hang out around the Certification and/or Social areas when I’m not in meetings/etc. I’m pretty easy to find, so drop by and say hi. It’s been like old home week for me—reconnecting with people I’ve not seen in years, catching up and friendships, etc. I can’t tell you how much I appreciate the people I’ve worked with over the years in terms of friendships offered and skills learned. Seriously.

Second, I’m speaking on Thursday afternoon about understanding and managing network complexity. I’m pretty certain the session isn’t full yet, so come by and listen. It’s a 90 minute investment that could change the way you think about network design and operation. Seriously.

Third, The content seems to be deep and interesting this year, as always. This brings me to my first contrary point, though—this industry needs a show that compares with Live in depth of technical material, but isn’t tied to a particular vendor. Are you listening, Interop? I know, it’s hard to talk deep technology in the modern networking world—which leads me to my final point.

As I wandered the show floor, I noticed something odd. Maybe this is something that’s always been true, but I don’t remember this from prior years at Live (I’ve missed speaking at Live/US twice in the last 19 years—and yet I’ve never been a NetVet… the injustice! 🙂 ).

The largest, fanciest booths on the floor, other than the common “large brands,” are companies that map, discover, and (in some sense) manage networks. I can remember back when the training companies had the largest booths, or product vendors, or even partners. But this year, the most common name you will encounter hanging above the show floor is the name of one company or another that maps your network. Look—these people and products are, I’m certain, very good. I was actually quite impressed with a number of them. But there’s something that just bothers me about this.

Maybe it’s this: we’ve imbibed in complexity for a long while, and now we’re suffering from the hangover.

rant on

Yes, I know how much fun it is to “geek out,” and revel in a new product that has fourteen layers and ten protocols and five hundred nerd knobs. I know how much entertainment value there is in knowing the latest and greatest product, stumping your family with your deep questions about bits and configuration commands, and amazing your family with your in depth knowledge of 500 pages of stuff about a single “solution.”

But moving from vendor (Cisco) to provider (Verisign) to vendor in a different space (Ericsson) to a hyperscale content provider (LinkedIn) has pressed into my mind two lessons that we, as an industry, seem to forget time and time again.

Elegance matters. I’m not going to rant about complexity, because I know complexity is required to solve hard problems. But we’ve moved, as an industry, from carefully thinking through problems and finding elegant ways to solve them, to various forms of brute force. We cover all this up with a GUI and a “go” button, but we’re going to have to do better than this. Let me give you an example by way of a story if I may.

Many years ago, in a lifetime far away, I worked on VORs. One of the problems in VOR land is that you must somehow pulse the signal going to the antenna at a certain frequency—once every 60th of a second, if I remember right. I well remember walking into the VOR shelter the first time. For there, slicing through the middle of the waveguide, was a thin bladed fan. “What,” I inquired, “is that doing in the middle of the waveguide?”

“Final modulation.”

The designers literally put a fan, a physical fan with spinning blades, in the signal path to pulse the output signal. Years later, when we replaced the VOR, the fan was replaced with a deeply complicated digital system that caused the transmitter to shut on and off at the appropriate rate—and hence caused us no end of replacements in the final transmitter tube (a thyratron).

The fan was engineering. An elegant solution to a hard problem. Maybe not perfect, but effective and simple. The folks who made the original digital circuit, because it was just “so easy to change a bit of code,” brute forced the problem instead.

Folks, this is how we build our networks today. Not happy with that old data center or campus network? Throw an overlay on it and make it all shiny and new again. Need to deploy something new on the network? Install a new overlay, or a few new bits of “shiny,” add a few tens of line to your config, maybe toss a Python script at it to make it “simple.” Go to a trade show and see something you really want to learn? Well, figure out how to justify it, buy it, and put it on your resume. Sure, Mr./Mrs. Application Developer, feel free to use IP addresses to identify a physical piece of hardware. Sure, we’ll give you layer 2 mobility without breaking ARP across the country—no problem.

This isn’t engineering. This is a bunch of thinly veiled hacks. A hack behind a GUI and a bunch of fancy names is still a hack.

Which leads to my second point: engineering matters.

I know I’ve said this before, but we’ve gotten to the point where we want to be button pushers with engineering titles rather than real engineers. This isn’t good for us as an industry, nor for us as people. When I worked in TAC, there wasn’t a person on the phone who couldn’t explain EIGRP, OSPF, BGP, and IS-IS in levels of detail that would (probably) put most every engineer on the show floor at this week’s Live to shame. Maybe it was a different time, and a different place, but nonetheless—

We need to learn how to be good engineers again. If you want to get past vendor dependence, then you need to learn how to stop outsourcing your thinking to a vendor. If you want to build elegant networks that work, then you need to learn to be an engineer, rather than being the equivalent of someone who just happens to know about every last feature of the latest smart phone.

Elegance matters, and engineering matters.

rant off

Maybe, just maybe, we need to adapt the old rule of protocol design to our networks.

The design isn’t finished when the problem is solved. The design is finished when every part of the design that isn’t necessary to solving the problem has been removed from the network.