The Missing Layer

Every good mystery has a clue everyone overlooks. Ours was plugged into the wall.

For fifty years, the networking industry kept searching for the next big thing. We invented protocols, built empires, raised venture rounds and argued about standards at conferences over free coffee and terrible Wi-Fi.

I’ve spent most of my career on this case. Sometimes I was a witness. A few times, I was an accomplice.

And here’s the twist I didn’t see coming: the answer wasn’t another new protocol. It was something we’d been building around for decades.

Hiding in plain sight. At the end of a cable.

Let me take you back to where it started.

A Memo at Xerox

Palo Alto, 1973. Xerox PARC had personal computers before anyone wanted one and laser printers before anyone needed one. What they didn’t have was a way to connect them.

So Bob Metcalfe wrote a memo. He and David Boggs built a network that ran at about 3 Mbps over coax and named it after the “luminiferous ether,” the invisible medium physicists once believed carried light.

The physicists were wrong about the ether. Metcalfe was right about Ethernet.

The rules were simple. Listen before you talk. If two of you talk at once, back off and try again. No central controller. No reservations. No committee.

Just a frame with a source, a destination and something to say.

Hold on to that. It’s the first clue.

The Committee’s Favorite

Every mystery needs a red herring. Ours was ATM.

Full disclosure: I never worked on ATM. I met it in textbooks. It was a great thing to study.

The telecom world bet on it: everything chopped into 53-byte cells riding pre-built circuits with guaranteed quality of service.

And the 53 bytes? One camp wanted 64 bytes of payload. Another wanted 32. They settled on 48 and added a 5-byte header.

When even your packet size is a negotiated settlement, you know who designed it.

Ethernet didn’t negotiate. It just kept getting cheaper and faster. You know how that ended.

Labels in the Core

Then the internet happened and IP won. Not because it was the best protocol, but because it was everywhere.

Looking up every destination at every hop was expensive, so MPLS put a short label on the packet at the edge and let the core switch on the label.

This is where I walked onto the scene. At Cisco, I worked on MPLS forwarding, the unglamorous part where theory meets silicon and every nanosecond has a lawyer. Push a label. Swap a label. Pop a label. At line rate. Without dropping anything.

But look at what was riding inside those labeled packets, and a lot of it wasn’t IP.

It was Ethernet.

Many Disguises

Customers didn’t want labels. They wanted their branch to feel like it was down the hall from headquarters. Same VLANs. Same frames. Same simplicity.

Pseudowires. VPLS. MPLS-TP. OTV. VXLAN. Every one a costume.

A carrier backbone pretending to be a cable. A carrier network pretending to be a switch. Two data centers pretending to be one room. Same frame underneath, every time.

A lot of that alphabet came out of Building 300 on Cisco’s campus in Boxborough, Massachusetts. That’s where we built MPLS-TP, OTV and much of the plumbing around them. I was surrounded by brilliant minds and learned something every day, mostly how much I didn’t know.

Meanwhile, the MEF (now Mplify Alliance) gave the suspect a passport: Carrier Ethernet, with E-Line services like EPL and EVPL.

So Ethernet became a service. But crossing to another operator still meant contracts, cross-connects and weeks of calls.

The frame could travel. The service couldn’t.

Everyone Leaves for the Internet

First, a detour. Around 2010, OpenFlow promised to program networks from a central controller. It worked inside a single domain. It never crossed into anyone else’s. Another clue.

Then enterprises looked at their MPLS bills, looked at their broadband connections and asked the obvious question: why are we paying for this?

SD-WAN was the answer. Run IP over the internet, build overlays, steer traffic in software and pay a fraction of the price.

MPLS was on its way down in the branch, so I joined 128 Technology to work on SD-WAN. Software was finally eating the WAN. And for the record, none of it ran on OpenFlow. SDN and SD-WAN shared a few letters and almost nothing else.

But notice what disappeared. No Ethernet across the middle. Just IP, inside tunnels, inside the internet.

Then SD-WAN did what every great idea eventually does. It became a checkbox.

SD-WAN solved the edges. Nobody solved the middle.

The Case of the Missing Packets

Once traffic lived on the internet, it needed protecting. So we added security. Then more security. Then the industry gave the pile a name: SASE.

SD-WAN. SSE. ZTNA. CASB. SWG. FWaaS. Each one real. Each one with its own console, its own policy language and its own renewal date.

Now, the case.

A retail customer started losing packets. Not all of them. Just enough to ruin everyone’s week. Packets left one site and never arrived at the other.

It took six months. We went provider by provider, manager by manager, escalation by escalation. Every party confirmed, politely and with great confidence, that the problem was definitely not on their side. The trail ran through the internet, through someone else’s router and through multiple layers of NAT, each one rewriting the evidence on its way through.

The culprit? Somewhere in the middle, a router was quietly dropping traffic. We never found out which one, or exactly where. A software upgrade eventually fixed the problem.

The packets came back. The visibility didn’t.

We had built a Rube Goldberg machine to do what a coax cable did in 1973.

The Reveal

It was Ethernet. It was always Ethernet.

ATM tried to replace it. MPLS carried it. Pseudowires, VPLS and OTV disguised it. Carrier Ethernet gave it a passport. SD-WAN left it behind, and SASE buried it under acronyms.

Through all of it, servers, switches and GPUs kept speaking Ethernet at the port.

That’s not an accident. Ethernet is the interface operators, clouds and GPU sites already agree on. In a world of independent networks, the thing everyone agrees on is the thing you federate.

Not Ethernet as a protocol. Ethernet as the handshake between networks.

The question was never what replaces Ethernet. The question was why we keep hiding it.

So stop hiding it. Make Ethernet the service, and give it what it never had:

Extended across domains. Across independent operators, fiber owners and clouds, not trapped inside one network.
Programmable. An API call, not a purchase order and 60 to 90 days of emails.
Automated. Paths computed and provisioned by software, not by bridge calls.
Visible. Every segment of the path measured, so you know where it broke before your customer does.
Secure by default. Encrypted end to end, every time. Not an add-on SKU.

That’s Software-Defined Ethernet (SD-Ethernet). A programmable Ethernet layer over any transport: fiber, MPLS, IP or the internet.

It works provider edge to provider edge, so operators federate without BGP gymnastics. It works customer edge to provider edge, so an enterprise plugs in a port and gets a private network. Q-in-Q comes along, so it speaks the language networks already understand.

So how would that have solved the retailer’s case? Ethernet alone wouldn’t. Ethernet gives every network the same handoff. The rest is what we built at MaiaEdge.

A Path Border Controller sits at each participating operator’s boundary. In the cloud, our Path Computation Engine works out the path across those operators. Each edge device configures its part of the connection, encrypts the traffic and continuously measures its segment.

That makes the service programmable. A customer requests a connection through an API, and the software coordinates the participating networks to deliver it.

You still can’t see inside someone else’s router. You don’t have to. When packets go missing, the measurements show which segment lost them and which operator owns it. That tells you which provider to call, and gives you evidence to bring.

That case wouldn’t need a detective.

It would need a dashboard.

Here’s what it looks like in practice. A customer requests a private connection from their data center to a GPU site on another operator’s network. One API request sets that process in motion.

For our first customer, activating a private Ethernet service between already-connected sites went from 60 days to seconds.

Why Now

AI didn’t just break compute. It’s breaking networking.

Models train in one place, run inference in another and pull data from a third. The people who own that data want it private and sovereign. You can’t wrap that in six security products and hope. And you can’t wait 90 days for a circuit every time a GPU cluster comes online.

AI needs a private network that goes anywhere, over any transport, on demand.

Not a new network you move into. An extension of the one you already have.

That difference matters. A new network means new policies, new boundaries and new things to trust. An extension means your segments and your rules simply reach further.

For MSPs, this changes the business. Stop reselling pipes. Become the extension of your customer’s network, and build services on top: segmentation, security, AI gateways, reach into every cloud and neocloud.

The network stops being a pipe. It becomes the platform.

Here’s where this goes.

Enterprises won’t buy circuits. They’ll extend their network to wherever the GPUs are. Operators won’t negotiate interconnects by spreadsheet. They’ll federate in minutes.

And the network will stop being the place AI waits. It will be how AI moves.

That’s why we started MaiaEdge with Software-Defined Ethernet. After twenty-plus years of chasing the next big thing, the answer was the oldest thing in the room.

Ethernet was the answer all along. We just had to let it cross borders.