Is SRv6 ready for production in an operator network?

By Javier Bamio, CEO of Telecom District.

Ever since we announced that we’re operating an SRv6 backbone in production, the same question comes up in every conversation with peers, at every technical panel, and in every event hallway. It’s asked by regional operators, enterprise network architects, and carrier engineering teams that have been evaluating the transition for years. It’s almost always the same: Is SRv6 ready for production in an operator’s network?

That's a good question. And it's almost always phrased incorrectly.

Underneath that lies a more pressing concern, one that is rarely voiced aloud. It’s not whether the protocol works. It’s whether my team will be able to operate it. Whether I’ll be able to migrate without taking down the network I’m already running. And whether this will give me something I don’t have today, or just a new architecture built on top of the same old problems.

My answer—after operating this backbone for as long as we’ve been at Telecom District and comparing notes with peers from various regions—is this: It’s not “yes.” Nor is it “no.” It’s “it depends on what traffic you’re going to run on it, and it depends, above all, on who’s going to operate it.”

It's worth explaining how we got here, because it wasn't part of a plan.

Telecom District was founded eight years ago in Mexico as a telecom integrator. We spent years deploying, integrating, and operating carrier networks—both traditional and core networks. When we decided to build our own backbone, we didn’t sit down and say, “We’re going to be the first to implement SRv6 in Latin America.” We needed to start from scratch, and starting from scratch forces you to choose the most advanced routing technology available. We chose SRv6 over MPLS. Some time later, we discovered that we were the region’s first greenfield SRv6 backbone. It wasn’t planned. It stemmed from a simpler decision: if you’re starting today, start right. It’s been in production since March 2025.

That starting point is also what gave us the answer to the question. Because the decision to deploy SRv6 in production isn't made at the layer that almost everyone looks at first.

The bottleneck isn't the silicon. It's your team's preparation.

When an operator begins evaluating SRv6, the conversation almost always starts with the hardware. Which ASIC supports native SRv6, which line cards, which platform, which version of IOS-XR, and what feature parity exists with the rest of the portfolio. It’s a legitimate and necessary conversation.

But that's not what determines whether SRv6 will work well in production. That's a different matter, and no one brings it up at the first meeting.

If your senior networking staff doesn't understand SR-Policy with SBFD, doesn't understand how the control plane behaves during a failure, and hasn't actually troubleshot a path computation that went wrong at a specific point in the network, they won't be able to operate SRv6 properly. It doesn't matter what ASIC you use. It doesn't matter what platform you use. It doesn't matter how much you invested in silicon.

I'm putting it this bluntly because I've heard the same pattern in more than one conversation with peers. Heavy investment in modern hardware, slow deployment, and operational problems that the team can't diagnose because the tool has changed but their training hasn't. The result is a modern network operated with outdated practices, and that shows in the quality of service.

The investment that is always underestimated in a transition to SRv6 is the investment in people. Formal training courses, in-house labs, time spent by senior staff mentoring junior staff during the first production incidents, and in-house operational documentation developed as we go. That costs money and takes time. Without that, SRv6 remains theoretical.

We learned this before we had to learn it under pressure. Building the backbone from scratch with SRv6 from day one didn’t give us a shortcut. It gave us a team that operates the modern network as if it were second nature—because for them, it is. They aren’t burdened by the habits of traditional MPLS. And that’s why today we operate this backbone with a deliberately small engineering team: an end-to-end programmable network makes it possible.

If your team has been operating MPLS for a decade, don't ask them to start operating SRv6 next week.

MPLS compatibility is the migration path

This is the part that causes the most friction in conversations with vendors. And it's the most important aspect for any operator that already has a network in production.

There are two ways of talking about SRv6 in the industry right now. One refers to “pure,” clean, legacy-free SRv6, as if the transition were simply a matter of turning off MPLS on a Friday and turning on SRv6 on Monday. The other, more honest approach, refers to SRv6 as the target protocol and MPLS as a transitional protocol that will coexist for several years.

Any operator with an installed base falls into the second category. The first category exists only in theory.

A carrier network doesn't just shut down. Enterprise customers pay for SLAs, and wholesalers have BGP routes that can't be moved without coordination. Migration means coexistence. It means that SRv6 and MPLS have to communicate with each other on the same backbone for the duration of the transition—which, in a real-world network, takes years, not months.

Anyone who sells you “pure” SRv6 from day one is selling you a problematic brownfield project disguised as a greenfield one. It’s not that they’re lying. They’re describing a scenario that only exists for new operators like us, who are building from scratch without legacy debt. For an operator with a network already in production, that pitch leads to a multi-year project with operational risk that you don’t need to take on.

The sensible approach is different. Design SRv6 from the outset to coexist with MPLS, with seamless interworking at edge nodes, with a plan to phase out MPLS on a per-domain basis rather than through a single event, and with telemetry covering both data planes so that operations are not left in the dark during the coexistence phase. This aligns with what we discussed with Cisco’s technical teams, who invited us this year to present our backbone as a regional reference case at their LATAM Service Provider Summit. And it aligns with our experience operating it.

MPLS compatibility is the only realistic path to a modern, operational network.

The real case for SRv6 is the programmable underlay

This is the most uncomfortable part, because it goes against the current marketing narrative.

The argument you hear at every keynote is this: Artificial intelligence demands more bandwidth, higher quality, and greater determinism. SRv6 is the architecture that enables AI workloads to be delivered with the quality they require. Therefore, if you're thinking about AI, you need SRv6.

The first part is true. The second part is too, with some caveats. The implied conclusion is flawed.

What justifies a complete architectural transition is not AI. It is the need for a programmable, observable, and assist-operable underlay. SRv6 is one of the options that meets that need. It is the most mature and standardized option at this time, which is why we are adopting it. But the argument is not “SRv6 because of AI.” The argument is “your traffic is changing, and you need a modern underlay—and SRv6 is currently the best option for building it.”

I make this distinction because it changes the decision. If an operator or a company gets the idea that SRv6 is the answer to the AI question, it will purchase an architecture without understanding what problem it’s solving. When the first traffic load arrives that doesn’t behave as expected, it won’t know where to look, because the architecture decision was never tied to the actual problem.

The real question is this: Can your underlay, as it stands today, receive continuous telemetry from each flow? Can it express service intent in code rather than in a ticket? Can it integrate with an operations plan that assists your team in detection and response? If the answer is no, you have an architectural problem. SRv6 can help you solve it, but the decision must be based on the problem, not the protocol.

What Really Changes for the Customer

A modern backbone is not an end in itself. For the person on the other end—the one paying for connectivity—the change is felt in something much more tangible than a routing protocol: they can finally see what’s happening on their network.

Enterprise customers in Latin America are rarely able to measure the connectivity they’re paying for. The provider tells them the connection is fine. When something goes wrong, the conversation turns into an exchange of closed tickets with no explanation, and it’s up to them to justify it internally without having the data. That’s the real pain point, and it predates any discussion about AI.

Kontrol Edge, our NaaS platform, runs on this backbone, with AI-assisted operations integrated into day-to-day operations. I say this carefully because the wording matters: AI assists operations; it does not operate them autonomously. There are people behind the scenes, human decisions, and agents who accelerate detection, event correlation, and incident response. This isn’t just marketing. It’s the difference between detecting a problem in seconds or hours, and between the customer calling us to report an outage and us calling them to let them know we’ve already resolved it.

That assisted operation wouldn’t work on just any network. It works because the backbone was built with a programmable and observable underlay from the outset, because the team operates it with a fresh approach, and because MPLS and SRv6 communicate seamlessly at the edge nodes while coexisting. Team, migration, and underlay are three sides of the same coin. When one fails, the assisted operation loses its foundation, and a poorly operated modern network is worse than a well-operated traditional network.

Where are you?

The message dominating the industry this year is that we must lead in the age of agents. It’s a clear direction, and I’m not going to paraphrase it. What I took away from this year’s events isn’t the announcement itself. It’s the gap between the announcement and its implementation. The direction the industry is announcing today is already being implemented by some.

The key question for every operator and every architect is this: Is your network, as it stands today, ready for that initiative to go live next year, or will you be just starting to evaluate it when everyone else is already implementing it? That conversation doesn’t happen on a keynote whiteboard. It happens by looking at your own backbone, your own operations, your own team, and being honest about where you stand.

If your network is still running on traditional MPLS without a migration plan, it’s worth having one now. Three years from now, the cost of migrating your legacy network will be higher than the cost of getting it right today, and the gap between you and those who already operate this way will no longer be an advantage for others—it will become a problem for you.

‍

‍