> ## Content Index
> Fetch the complete content index at: https://www.bitsinflight.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Networking Is Too Complex
- URL: https://www.bitsinflight.com/networking-is-too-complex-roundtable/
- Published: 2022-06-24T12:00:00.000Z
- Updated: 2026-09-16T17:11:09.000Z
- Description: An On-Premise IT Roundtable recorded at Networking Field Day 28 with Tom Hollingsworth, Jordan Villarreal and Martin Duggan. Overlays on overlays, stretched layer 2 that nobody wants, and the uncomfortable idea that a lot of our complexity exists because network engineers never pushed back.
- Author: Jason Gintert
- Tags: media, podcast, video, Gestalt IT, network design, NFD, nfd28

*Gestalt IT's On-Premise IT Roundtable, recorded at Networking Field Day 28\. Published 24 June 2022\. Host: Tom Hollingsworth, with fellow delegates Jordan Villarreal and Martin Duggan.*

Tom's premise was that networking is too complex, and he opened with the history: Metcalfe's Ethernet, Radia Perlman's bridge, the first person who plugged a bridge into itself, and spanning tree as the first time we added complexity to solve a human problem. Forty years later a conversation between network engineers is 85% acronyms, and the only other people who talk like that are doctors.

## Overlays on overlays

My explanation was layers of abstraction. We built a layer 2 underlay, put layer 3 on top of it, then encapsulated layer 2 back on top of that so we could do EVPN and VXLAN. Every one of those layers is something an engineer has to understand to troubleshoot, and a lot of people who came up in a conventional layer 2 and layer 3 world are having a hard time keeping pace. Tom traced the same story through TRILL, FabricPath and SPB, each a proprietary answer to the same problem, until the network stopped being a network and became a stack of protocols riding on Ethernet.

The reason we keep doing it is the requirement to stretch layer 2, which every engineer hates and most have to live with. I told the story of a large organization with an enormous layer 2 environment that kept going down from loops. Their fix was an overlay, which stopped the outages and then created a new problem: they could not find anyone who could operate it. They removed the old complexity by adding a kind nobody on staff understood.

## Whose problem is it?

Tom's sharpest point was that vMotion across coasts, OTV and stretched clusters exist because we agreed to solve problems that were never ours. The application is a tenant of the network the way UPS is a tenant of the interstate, and if UPS has a truck problem it is not the highway department's job. I agreed that engineers have not pushed back hard enough on application teams, and passed along advice I had been given about EVPN-VXLAN: even now that stretching layer 2 works, push back every single time and use it only when there is genuinely no other option. Martin noted how hard that is when the business owns a twenty-year-old application, the developers are gone, and "we know you can make the network do it" is the cheaper answer on someone else's cost center.

## What Amazon got right

Tom asked why an AWS VPC is so simple when enterprise networks are not. My answer was that we gave people too many options. Amazon went Henry Ford: any colour you like as long as it is black. Because cloud was greenfield, applications had to conform to the platform's rules instead of the network bending to the application, and lift-and-shift breaks precisely because those safety nets are gone. Martin's counterpoint was that designers rarely get a clean sheet, so the job is keeping brownfield as simple as it can be for the people who have to support it afterward.

## The Sith Lord problem

Tom put on the black robe: some people make networks complex so that only they can run them. It is the Brent problem from The Phoenix Project, and it is more common than anyone admits. The panel's answer was to treat it as a time bomb, raise it as a risk at the right level, and let management choose between a controlled fix and an uncontrolled failure.

Asked for one thing people can do today, Jordan said let the past go and stop dragging legacy protocols and designs along. Martin quoted Russ White on separating complexity from complexity and containing what you cannot remove. Mine was the plain one: focus on simple designs, push back on other teams where needed, keep it as simple as the objective allows, and educate the people who will inherit it.

[Watch on YouTube →](https://www.youtube.com/watch?v=yy3Mdzzo2TE&ref=bitsinflight.com)