¿SRv6 está listo para producción en una red de operador?

Por Javier Bamio, CEO de Telecom District.

Desde que contamos que operamos un backbone SRv6 en producción, la pregunta se repite en cada conversación con peers, en cada mesa técnica, en cada pasillo de evento. La hacen operadores regionales, arquitectos de red de empresas, equipos de ingeniería de carriers que llevan años evaluando la transición. Casi siempre es la misma: ¿está SRv6 listo para producción en una red de operador?

Es una buena pregunta. Y casi siempre viene mal planteada.

Debajo de ella hay una preocupación más real, que rara vez se dice en voz alta. No es si el protocolo funciona. Es si mi equipo va a poder operarlo. Si voy a poder migrar sin apagar la red que ya tengo encima. Y si esto me va a dar algo que hoy no tengo, o solo una arquitectura nueva sobre los mismos problemas de siempre.

Mi respuesta, después de operar este backbone durante el tiempo que llevamos en Telecom District y de comparar notas con peers de varias regiones, es esta. No es “sí”. Tampoco es “no”. Es “depende de qué carga le vas a poner encima, y depende, sobre todo, de quién la va a operar”.

Vale la pena contar cómo llegamos hasta aquí, porque no fue un plan.

Telecom District nació hace ocho años en México como integrador de telcos. Pasamos años implementando, integrando y operando redes de operador: las tradicionales, las de core. Cuando decidimos construir nuestro propio backbone, no nos sentamos a decir “vamos a ser los primeros en SRv6 en Latinoamérica”. Necesitábamos empezar de cero, y empezar de cero te obliga a elegir la tecnología de enrutamiento más avanzada que haya sobre la mesa. Elegimos SRv6 en lugar de MPLS. Tiempo después descubrimos que éramos el primer backbone SRv6 greenfield de la región. No estaba planeado. Salió de una decisión más simple: si arrancas hoy, arranca bien. Lleva en producción desde marzo de 2025.

Ese punto de partida es también el que nos dio la respuesta a la pregunta. Porque operar SRv6 en producción no se decide en la capa que casi todos miran primero.

El cuello de botella no es el silicio. Es la preparación de tu equipo.

Cuando un operador empieza a evaluar SRv6, la conversación arranca casi siempre por el hardware. Qué ASIC soporta SRv6 nativo, qué linecards, qué plataforma, qué versión de IOS-XR, qué feature parity con el resto del portafolio. Es una conversación legítima y necesaria.

Pero no es la que decide si SRv6 va a operar bien en producción. Esa es otra, y nadie la pone en la primera reunión.

Si tu staff senior de redes no entiende SR-Policy con SBFD, no entiende cómo se comporta el plano de control bajo falla, no ha hecho troubleshooting real de un path computation que se torció en un punto específico de la red, no va a operar SRv6 bien. Da igual el ASIC. Da igual la plataforma. Da igual cuánto invertiste en silicio.

Lo digo así de directo porque en más de una conversación con peers escuché el mismo patrón. Inversión fuerte en hardware moderno, despliegue lento, problemas operativos que el equipo no sabe diagnosticar porque la herramienta cambió pero la formación no. El resultado es una red moderna operada con reflejos viejos, y eso se nota en la calidad de servicio.

La inversión que se subestima siempre en una transición a SRv6 es la inversión en gente. Cursos formales, laboratorios internos, tiempo de los seniors para acompañar a los menos seniors en los primeros incidentes en producción, documentación operativa propia construida sobre la marcha. Eso cuesta y eso tarda. Sin eso, el SRv6 es teórico.

Nosotros lo aprendimos antes de tener que aprenderlo bajo presión. Construir el backbone desde cero con SRv6 desde el primer día no nos dio un atajo. Nos dio un equipo que opera la red moderna como si fuera natural, porque para ellos lo es. No cargan reflejos de MPLS tradicional encima. Y por eso hoy operamos este backbone con un equipo de ingeniería deliberadamente pequeño: una red programable de punta a punta lo permite.

Si tu equipo viene de operar MPLS durante una década, no le pidas que opere SRv6 la semana próxima.

La compatibilidad con MPLS es la ruta de migración

Esta es la parte que más fricción genera en conversaciones con vendors. Y es la más importante para cualquier operador que ya tenga red en producción.

Hay dos formas de hablar de SRv6 en la industria ahora mismo. Una habla de SRv6 “puro”, limpio, sin legacy, como si la transición fuera apagar MPLS un viernes y prender SRv6 el lunes. La otra, más honesta, habla de SRv6 como protocolo destino y de MPLS como protocolo de transición que va a convivir varios años.

Cualquier operador con base instalada vive en la segunda. La primera solo existe en presentaciones.

Una red de operador no se apaga. Los clientes enterprise pagan SLA, los mayoristas tienen rutas en BGP que no se mueven sin coordinación. Migrar significa convivir. Significa que SRv6 y MPLS tienen que hablar entre sí en el mismo backbone durante el tiempo que dure la transición, que en una red real son años, no meses.

Quien te vende SRv6 “puro” desde el día uno te está vendiendo un brownfield problemático disfrazado de greenfield. No es que mienta. Está describiendo un escenario que solo existe en operadores nuevos como nosotros, que construimos sin deuda heredada. Para un operador con red ya en producción, ese discurso lleva a un proyecto de varios años con un riesgo operativo que no necesitas asumir.

La ruta sensata es otra. Diseñar SRv6 desde el principio para coexistir con MPLS, con interworking limpio en los nodos de borde, con un plan de retiro de MPLS por dominio y no por evento único, con telemetría que cubra ambos planos de datos para que la operación no quede ciega durante la convivencia. Eso coincide con lo que discutimos con los equipos técnicos de Cisco, que este año nos invitaron a presentar nuestro backbone como caso de referencia regional en su LATAM Service Provider Summit. Y coincide con lo que vivimos operándolo.

La compatibilidad con MPLS es la única ruta realista a una red moderna operable.

El verdadero argumento para SRv6 es el underlay programable

Esta es la parte más incómoda, porque va contra la narrativa de marketing del momento.

El razonamiento que se escucha en cada keynote es este. La inteligencia artificial demanda más tráfico, más calidad, más determinismo. SRv6 es la arquitectura que permite servir cargas de IA con la calidad que demandan. Por lo tanto, si estás pensando en IA, necesitas SRv6.

La primera parte es cierta. La segunda también, con matices. La conclusión implícita está mal planteada.

Lo que justifica una transición arquitectónica completa no es la IA. Es la necesidad de un underlay programable, observable y operable de forma asistida. SRv6 es una de las opciones que cumplen esa necesidad. Es la más madura y estandarizada en este momento, y por eso es la que adoptamos. Pero el argumento no es “SRv6 porque IA”. El argumento es “tu tráfico está cambiando y necesitas un underlay moderno, y SRv6 es hoy la mejor opción para construirlo”.

Hago la distinción porque cambia la decisión. Si un operador o una empresa se queda con la idea de que SRv6 es la respuesta a la pregunta de IA, va a comprar una arquitectura sin entender qué está resolviendo. Cuando llegue la primera carga que no se comporta como esperaba, no va a saber dónde mirar, porque la decisión de arquitectura nunca estuvo conectada a la pregunta real.

La pregunta real es esta. Tu underlay, tal como está hoy, ¿puede recibir telemetría continua de cada flujo? ¿Puede expresar intención de servicio en código en lugar de en un ticket? ¿Puede integrarse con un plano de operación que asista a tu equipo en detección y respuesta? Si la respuesta es no, tienes un problema de arquitectura. SRv6 te puede ayudar a resolverlo, pero la decisión tiene que partir del problema, no del protocolo.

Lo que realmente cambia para el cliente

Un backbone moderno no es un fin en sí mismo. Para el que está del otro lado, el que paga la conectividad, el cambio se siente en algo mucho más concreto que un protocolo de enrutamiento: por fin ve lo que pasa en su red.

El cliente enterprise en LATAM rara vez puede medir la conectividad que paga. El proveedor le dice que el enlace está bien. Cuando algo falla, la conversación se vuelve un intercambio de tickets cerrados sin explicación, y le toca a él justificarlo internamente sin tener los datos. Ese es el dolor real, y es anterior a cualquier discusión sobre IA.

Sobre este backbone corre Kontrol Edge, nuestra plataforma NaaS, con AI-assisted operations integradas en el día a día. Lo digo con cuidado porque importa la palabra: la IA asiste la operación, no la opera de forma autónoma. Hay personas detrás, decisiones humanas, y agentes que aceleran la detección, la correlación de eventos y la respuesta a incidentes. No es marketing. Es la diferencia entre detectar un problema en segundos o en horas, y entre que el cliente nos llame para reportar una falla o que nosotros le llamemos avisando que ya la resolvimos.

Esa operación asistida no funcionaría sobre cualquier red. Funciona porque el backbone se construyó con un underlay programable y observable desde el origen, porque el equipo lo opera con reflejos nuevos, y porque MPLS y SRv6 hablan limpio en los nodos de borde durante la convivencia. Equipo, migración y underlay son las tres caras del mismo dado. Cuando una falla, la operación asistida deja de tener sustento, y una red moderna mal operada es peor que una red tradicional bien operada.

Dónde estás tú

El mensaje que domina la industria este año es que hay que liderar en la era de los agentes. Es una dirección clara y no la voy a parafrasear. Lo que me llevo de los eventos de este año no es el anuncio. Es la distancia entre el anuncio y la operación. La dirección que la industria anuncia hoy ya es operación para algunos.

La pregunta útil para cada operador y cada arquitecto es esta: tu red, hoy, ¿está lista para que esa dirección sea operación el año próximo, o vas a estar empezando a evaluar cuando los demás ya estén ejecutando? Esa conversación no se tiene en una pizarra de keynote. Se tiene mirando tu propio backbone, tu propia operación, tu propio equipo, y siendo honesto sobre dónde estás.

Si tu red sigue corriendo sobre MPLS tradicional sin un plan de migración, vale la pena tenerla ahora. Tres años desde hoy, el costo de migrar tu red heredada será mayor que el de empezar bien hoy, y la distancia con quienes ya operan así habrá dejado de ser una ventaja de otros para volverse un problema tuyo.

‍

‍