SRv6: qué es Segment Routing para IPv6 y por qué los operadores ya están migrando
En los foros de operadores de red de los últimos años, SRv6 pasó de ser una propuesta de estándares a convertirse en una tecnología en producción. En el RIPE SEE 14 y en NANOG 96, múltiples operadores presentaron implementaciones reales: migraciones de MPLS a SRv6, despliegues de L3VPN sobre SRv6, y casos de uso de traffic engineering que antes requerían infraestructura MPLS compleja.
Para los operadores de red en Latinoamérica, el momento de entender SRv6 es ahora: no para desplegarlo mañana (en la mayoría de los casos todavía no es el momento), sino para incorporarlo al radar de planificación y entender cómo afecta las decisiones de equipamiento y arquitectura que se toman hoy.
El problema con MPLS que SRv6 viene a resolver
MPLS lleva más de veinte años siendo el protocolo de transporte dominante en los cores de los ISPs. Funciona bien para lo que fue diseñado, pero tiene fricciones operativas que se hacen más visibles a medida que las redes crecen:
Plano de control complejo: MPLS requiere protocolos adicionales para la distribución de etiquetas: LDP (Label Distribution Protocol) o RSVP-TE para traffic engineering, además del IGP subyacente. Cada uno de estos protocolos tiene su propio estado, su propio proceso de convergencia, y su propio conjunto de herramientas de debugging. La superposición de protocolos es una fuente permanente de complejidad operativa.
RSVP-TE no escala bien: Para hacer traffic engineering en MPLS (desviar tráfico por caminos específicos para optimizar la utilización), se usa RSVP-TE. El problema es que RSVP-TE es un protocolo con estado en todos los nodos de la ruta: cada router a lo largo del LSP (Label Switched Path) debe mantener información sobre ese túnel. En redes con muchos túneles de TE, esto se convierte en un problema de escala y estabilidad.
Interoperabilidad y extensiones: Agregar nuevos comportamientos en MPLS (nuevas acciones en nodos intermedios) generalmente requiere nuevos tipos de etiquetas o nuevas extensiones de protocolo, con el proceso de estandarización correspondiente.
Visibilidad de extremo a extremo: En MPLS clásico, el encabezado visible en los nodos intermedios es solo la etiqueta. El debugger de tráfico ve la etiqueta pero no necesariamente el contexto completo del flujo.
SRv6 no resuelve todos estos problemas de un golpe, pero aborda los más fundamentales de una forma elegante.
Qué es Segment Routing
Segment Routing es un paradigma de arquitectura de red basado en una idea simple: en lugar de que cada nodo del camino tome decisiones de forwarding basadas en tablas locales (el modelo MPLS clásico), el nodo de entrada especifica el camino completo codificándolo en el paquete mismo.
El camino se codifica como una lista de segmentos. Cada segmento es una instrucción: “mandá este paquete a este nodo”, “tomá esta interfaz de salida”, “aplicá este servicio”. Los nodos intermedios simplemente siguen las instrucciones del encabezado, sin necesidad de mantener estado de sesión o tablas específicas para ese flujo.
Esta idea tiene dos implementaciones principales:
SR-MPLS (Segment Routing con etiquetas MPLS): Los segmentos se codifican como etiquetas MPLS estándar en un label stack. Reutiliza el dataplane MPLS existente, con las ventajas del plano de control de SR. Es el camino de adopción para redes que ya tienen MPLS y quieren migrar gradualmente.
SRv6 (Segment Routing sobre IPv6): Los segmentos se codifican como direcciones IPv6 en una extensión de cabecera especial llamada Segment Routing Header (SRH). Usa IPv6 como dataplane, eliminando la necesidad de MPLS completamente.
SRv6 en detalle: cómo funciona
El Segment Routing Header (SRH)
SRv6 funciona agregando al paquete IPv6 una extensión de cabecera especial: el SRH (Segment Routing Header, definido en RFC 8754). El SRH contiene:
- Segment List: una lista de direcciones IPv6, ordenadas de último a primero (el primer segmento a procesar está al final de la lista)
- Segments Left: un puntero al segmento actualmente activo
- Tag y Flags: metadata adicional
El campo Destination Address del header IPv6 exterior siempre apunta al segmento actualmente activo. Cuando un nodo procesa el paquete, mira la Destination Address, ejecuta la función asociada a esa dirección, decrementa Segments Left, copia el siguiente segmento a Destination Address, y reenvía el paquete.
SIDs: los segmentos como funciones
Cada dirección IPv6 en el Segment List es un SID (Segment Identifier). Lo que hace especial a SRv6 es que cada SID no es solo una dirección de destino: es una función que el nodo que la posee debe ejecutar cuando recibe un paquete con esa dirección como Destination.
Las funciones más importantes del plano de datos SRv6:
End (Endpoint): El nodo es el endpoint del segmento. Procesa el SRH, actualiza el puntero, y reenvía al siguiente segmento. Es el SID más básico, equivalente a “pasar por este nodo”.
End.X (Endpoint con cross-connect de capa 3): Como End, pero además el nodo debe reenviar el paquete por una interfaz específica hacia un vecino específico. Útil para traffic engineering: forzar que el tráfico tome un enlace particular.
End.DT4 / End.DT6 (Endpoint con decapsulación y lookup en tabla): El nodo decapsula el encabezado SRv6 y hace un lookup de la dirección interna en una tabla de ruteo VRF específica. Esta función es la base para implementar L3VPN sobre SRv6 sin necesidad de MPLS.
T.Encaps (Tránsito con encapsulación): El nodo de ingreso encapsula el paquete original dentro de un nuevo header IPv6 con SRH. Esta es la función que usa el head-end para iniciar un camino SRv6.
La codificación de la función dentro de la dirección IPv6 no es arbitraria. La dirección SID tiene estructura:
uSID: resolviendo el problema de overhead
Una crítica legítima de SRv6 en su forma original es el overhead del encabezado. Cada SID en la lista es una dirección IPv6 de 128 bits (16 bytes). Un Segment List con 4 segmentos agrega 64 bytes de overhead al paquete. Para tráfico de baja latencia o payloads pequeños, esto puede ser significativo.
La solución es uSID (micro-SID), definida en RFC 9252 y adoptada rápidamente por los principales vendors. uSID comprime múltiples segmentos dentro de una sola dirección IPv6 de 128 bits usando los bloques de 16 bits del campo de host:
Con uSID, una sola dirección IPv6 puede codificar hasta 6 o 7 segmentos (dependiendo del tamaño del locator). El overhead baja dramáticamente: en lugar de 64 bytes para 4 segmentos, podés tener 4 segmentos en 16 bytes (una sola dirección IPv6 adicional).
La mayoría de las implementaciones en producción hoy usan uSID. Huawei VRP 8.x+, Cisco IOS-XR 7.x+, y Nokia SR OS tienen soporte de uSID en sus implementaciones SRv6.
Casos de uso operativos en producción
L3VPN sobre SRv6 (SRv6 PE)
El caso de uso que más impulso está ganando entre los ISPs es la implementación de L3VPN sobre SRv6, reemplazando la combinación tradicional de MPLS + BGP VPNv4.
En el modelo clásico MPLS L3VPN:
- El PE de ingreso hace un lookup en el VRF del cliente y encapsula el paquete con dos etiquetas MPLS: la etiqueta VPN (identifica el VRF en el PE de egreso) y la etiqueta de transporte (encamina el paquete por el core MPLS hasta el PE de egreso).
En SRv6 L3VPN:
- El PE de ingreso hace un lookup en el VRF del cliente.
- Encapsula el paquete con un nuevo header IPv6 cuya Destination es el SID
End.DT4del PE de egreso para ese VRF específico. - El paquete transita el core usando el IGP normal (el Locator del SID es enrutable).
- El PE de egreso recibe el paquete, reconoce el SID
End.DT4, decapsula el encabezado SRv6, y hace lookup en el VRF correspondiente.
No hay LDP. No hay RSVP. No hay label distribution. El estado de la VPN está encapsulado en la dirección IPv6 del SID.
Traffic Engineering sin RSVP-TE
Con SR-TE (Segment Routing Traffic Engineering), el traffic engineering se implementa sin el overhead de estado de RSVP-TE. En lugar de señalizar un túnel end-to-end con estado en cada nodo, el head-end simplemente incluye en el Segment List la secuencia de nodos o enlaces por los que quiere que vaya el tráfico.
Si querés que el tráfico de un cliente tome el camino A-B-D en lugar del camino más corto A-C-D, el head-end construye un Segment List con [End.X de A hacia B, End de D]. Los nodos intermedios B no necesitan saber nada del flujo: solo procesan el SRH.
Tráfico cliente VRF-Cliente-1:
[End.X(A→B), End.X(B→D), End.DT4(D, VRF-Cliente-1)]
Tráfico general best-effort:
[End.DT4(D, tabla global)] (camino más corto por IGP)
Service Function Chaining
SRv6 es especialmente adecuado para insertar funciones de red (firewalls, DPI, CGNATs, proxies) en el camino del tráfico de forma programática. Cada función es un SID que el tráfico debe visitar. El head-end construye el Segment List incluyendo el SID de la función.
SRv6 y los vendors: estado actual de soporte
Huawei VRP
Huawei tiene uno de los soportes SRv6 más completos entre los vendors ISP. El equipamiento NE series (NE40E, NE8000) soporta SRv6 desde VRP 8.x en producción, incluyendo:
- SRv6 BE (Best Effort, sin TE) con End y End.DT4/DT6
- SRv6 TE Policy con segmentos de nodo y adjacency
- SRv6 L3VPN (BGP VPNv4/VPNv6 sobre SRv6)
- EVPN sobre SRv6
- uSID
Los switches de acceso y distribución (CloudEngine series) tienen soporte más limitado. Para un ISP que usa Huawei en el core y distribución, el caso más realista de adopción temprana es SRv6 en los PE y P del core, con acceso manteniéndose en MPLS o tráfico plano durante una etapa de transición.
Cisco IOS-XR
Cisco fue uno de los primeros en implementar SR-MPLS en producción y ha extendido ese soporte a SRv6 en IOS-XR 7.x:
! Habilitar SRv6 en Cisco IOS-XR
segment-routing
srv6
locators
locator CORE
micro-segment behavior unode psp-usd
prefix 2001:db8:1::/48
!
!
!
!
! Configurar SRv6 para BGP VPNv4
router bgp 65001
address-family vpnv4 unicast
vrf-table-label
!
!
vrf CLIENTE-1
rd 65001:1
address-family ipv4 unicast
segment-routing srv6
locator CORE
alloc mode per-vrf
!
!
!
!
Nokia SR OS
Nokia ha construido su porfolio ISP (seria 7750 SR, 7450 ESS) con Segment Routing como eje central desde hace años. El soporte SRv6 en SR OS es extenso e incluye las funciones avanzadas de uSID y traffic engineering.
Cuándo tiene sentido considerar SRv6 para un ISP en LATAM
SRv6 no es para todos los ISPs hoy, y es importante ser honesto sobre eso. Las condiciones en las que SRv6 tiene sentido considerar en el corto plazo:
Tenés equipamiento de core que ya lo soporta: Si tu core corre en Huawei NE, Cisco ASR 9000 / NCS, o Nokia 7750, el hardware probablemente soporta SRv6 con una actualización de software. El costo de activación es bajo.
Estás planificando reemplazar el core de MPLS: Si estás en un ciclo de refresh de equipamiento, el momento de evaluar SRv6 es el diseño de la arquitectura nueva. Es mucho más difícil insertar SRv6 en una red MPLS existente que planificarlo desde el principio.
Tenés servicios VPN que querés simplificar: Si operás L3VPN para clientes corporativos y el plano de control MPLS es una carga operativa permanente, SRv6 L3VPN puede simplificar significativamente la operación eliminando LDP y RSVP.
Estás considerando ofertas de conectividad SD-WAN o servicios diferenciados: SRv6 es el plano de transporte natural para orchestración de paths programáticos, que es la base técnica de SD-WAN y slicing de red.
Las condiciones en las que SRv6 probablemente no es la prioridad correcta ahora:
- La red todavía corre MPLS estable con equipamiento de mid-life.
- El equipo técnico no tiene experiencia con IPv6 en producción (SRv6 requiere madurez en IPv6 como prerequisito).
- No hay caso de negocio concreto que justifique el esfuerzo de adopción.
Lo que vemos en el campo
En los proyectos de consultoría con ISPs en Latinoamérica, SRv6 aparece frecuentemente como una tecnología que los equipos técnicos quieren entender pero que todavía no están piloteando. El principal bloqueante no suele ser la tecnología en sí ni el equipamiento (que en muchos casos ya lo soporta), sino la curva de entrenamiento y la falta de referencia operativa local.
La adopción va a acelerar en los próximos dos a tres años a medida que los grandes carriers regionales (que sí están piloteando o ya tienen SRv6 en producción) empiecen a ofrecer servicios que asumen SRv6 en el acceso. Los ISPs regionales que entiendan la tecnología van a poder integrarse mejor a esos ecosistemas.
Conocé más sobre nuestros servicios de diseño de arquitectura de red y consultoría técnica.
¿Querés evaluar SRv6 en el contexto de tu red?
Podemos revisar tu arquitectura actual, identificar si tu equipamiento está listo para SRv6, y diseñar una hoja de ruta de adopción que se adapte a tu realidad operativa.
Hablemos sobre tu arquitectura →
¿Tenés preguntas sobre SRv6, MPLS o arquitectura de red? Escribinos a [email protected] — respondemos todos los mensajes.