Implementación de SRv6 uSID en la infraestructura de Telefônica VIVO

Al combinar EVPN con SRv6, se puede crear una solución que integre con eficiencia el enrutamiento de capa 3 con la conectividad de capa 2 sobre la infraestructura SRv6. SRv6 proporciona un método de enrutamiento basado en segmentos que resulta útil para optimizar el enrutamiento del tráfico IP. Cuando se combina o con EVPN —que puede manejar los requisitos de capa 2— se obtiene una solución integral para redes que requieren funcionalidades de servicio tanto de capa 2 como de capa 3.

Beneficios para Telefônica VIVO

Eficiencia del enrutamiento: Reduce la complejidad de las tablas de enrutamiento, mejorando así la eficiencia de la transmisión de datos. Al utilizar el concepto de enrutamiento de origen, SRv6 permite una arquitectura de red más simple y escalable. Esto puede reducir la complejidad de la red, facilitando su implementación y administración.

Baja latencia: La capacidad de enrutar el tráfico de forma más directa reduce la latencia, mejorando así la calidad de los servicios ofrecidos.

Mayor control del tráfico: Telefônica VIVO obtiene mayor control sobre la ruta del tráfico, lo que permite una asignación más eficiente de los recursos.

Flexibilidad en la programabilidad de la red: SRv6 ofrece una estructura de red programable, lo que permite una mayor flexibilidad a la hora de definir y adaptar el comportamiento de la red. Esta programabilidad puede ser útil para personalizar la red según las necesidades específicas del negocio y para adaptarse rápidamente al mercado, que demanda cada vez más nuevos requisitos.

Mejor resiliencia de la red: SRv6 soporta reenrutamiento rápido (menos de 50 ms) y ofrece mecanismos para crear rutas altamente resistentes. Esto puede mejorar la confiabilidad y disponibilidad general de la infraestructura de red.

Balanceo de carga: La solución SRv6 proporciona balanceo de carga nativo, a diferencia de MPLS, que todavía tiene problemas con el balanceo de carga. En MPLS, la entropía para la selección de rutas Equal-Cost Multi-Path (ECMP) está en el paquete IP interno, por lo que los enrutadores deben atravesar la pila de etiquetas MPLS para obtener acceso al encabezado IP utilizado para el hash.

En SRv6, Ingress PE calcula un hash en el paquete del cliente y escribe el resultado en el campo Flow Label del encabezado IPv6 externo agregado. El resto de la red aprovecha esta etiqueta de flujo para realizar la selección ECMP con solo un vistazo al encabezado externo, sin necesidad de profundizar en las capas de encapsulamiento.

Desafíos y soluciones:

Implementar un cambio tan significativo no es una tarea sencilla ni desde el punto de vista técnico ni desde el punto de vista operativo, dado que, en la mayoría de los casos, los cambios tecnológicos de gran relevancia requieren una reestructuración de los flujos de trabajo, la capacitación de los equipos, compromiso, etc.

En este artículo discutiremos potenciales obstáculos y ofreceremos soluciones prácticas, destacando el compromiso de Telefônica VIVO con la excelencia operativa.

Trabajo realizado

En los siguientes apartados describiré un poco el trabajo que hicimos para lograr el objetivo de implementar la tecnología SRv6 en la red de Telefônica VIVO.

Convencidos de la necesidad de implementar Segment Routing en la red, iniciamos muchas discusiones internas sobre posibles estrategias de implementación. Estas estrategias eran:

• Implementar SR-MPLS inicialmente y, luego, con las futuras necesidades de escalabilidad y la modernización de la red, cambiar a SRv6;
• Implementar SRv6 sin fase intermedia.

Sin embargo, este trabajo de cambiar de tecnología dos (2) veces en un proveedor del tamaño de Telefônica VIVO es demasiado traumático y costoso, por lo que decidimos saltarnos una fase y pasar directamente a SRv6. En ese momento existían muchas dudas sobre la madurez de la tecnología para su implementación masiva en la red. Sin embargo, la evolución de la red hacia su punto de destino sería una solución mucho más ventajosa, dado que se evitarían la doble transición, las inversiones no capitalizadas asociadas a una potencial subutilización de las inversiones en SR-MPLS si la migración a SRv6 se produce rápidamente, la reconfiguración de la red y la duplicación de los esfuerzos, la prolongación del proceso y, más que nunca, la obsolescencia técnica asociada al riesgo de que la tecnología SR-MPLS se vuelva obsoleta más rápidamente con el avance de SRv6.

Una vez analizados estos puntos, iniciamos un largo período de discusión con los arquitectos de Cisco, Huawei y Nokia, buscando asegurarnos de que la tecnología estuviera lo suficientemente madura para un despliegue masivo.

Metodología utilizada

La metodología de trabajo aplicada partió del modelo Agile, para lo cual diariamente manteníamos reuniones breves a primera hora con todo el equipo del proyecto para alinear los puntos de forma rápida y constante. Además, semanalmente nos reuníamos durante un día entero en el laboratorio de Telefônica VIVO para compartir los logros de la semana y discutir más profundamente los problemas encontrados.

La siguiente figura describe cómo planificamos todo el desarrollo del trabajo.

Camino recorrido

Este capítulo presenta la trayectoria formal recorrida para la evolución tecnológica de la red de transporte de VIVO hacia la adopción de Segment Routing over IPv6 (SRv6), que comenzó con la homologación de una solución basada en FULL Segment Identifiers (SIDs) y evolucionó hacia una arquitectura que incorpora el uso de Micro-Segment Identifiers (uSID). uSID proporciona la capacidad de comprimir el encabezado SRv6, lo que significa que con un solo encabezado IPv6 podemos codificar seis uSID en la dirección IPv6 de destino. Con esto se logra un mejor desempeño que con VxLAN o MPLS. uSID se ha convertido en la solución estándar del sector y cuenta con el respaldo de todos los proveedores.

Inicialmente, optamos por realizar pruebas integrales para evaluar la viabilidad de incorporar las funcionalidades básicas necesarias para soportar los servicios que actualmente operan en la red de VIVO. La intención es asegurarnos de que, si es posible cumplir con todos los requisitos de la red actual, en un futuro podamos introducir nuevas funcionalidades con el objetivo de mejorar el sistema de transporte. El enfoque adoptado pretende realizar una transición gradual, dado que sustituir MPLS por otra tecnología es un proceso delicado. Antes de avanzar directamente hacia el objetivo final, es fundamental garantizar que todos los servicios existentes funcionen de manera consistente y sin interrupciones para los clientes. Por lo tanto, elaboramos una lista exhaustiva de servicios y escenarios de servicios, destacando la aplicación de la tecnología SRv6, como medida para asegurar la viabilidad y el éxito de la implementación.

La siguiente figura muestra las principales actividades realizadas para la planificación y ejecución del FOA (First Office Application).

Homologación

Fase 1: Homologación inicial en Full SIDs

• Objetivos 
  • Evaluar la compatibilidad de los equipos y la viabilidad técnica de la solución SRv6.
  • Homologar la implementación de SRv6 con el uso de FULL SIDs para garantizar la comprensión de la tecnología y su aplicabilidad en la infraestructura existente.
  • Principales actividades
  • Selección de equipos: Especificación, selección de dispositivos de red que soporten SRv6 y armado de la configuración de prueba 
  • Entorno de prueba: Configuración de un entorno de laboratorio representativo para la simulación y validación de escenarios de red.
  • Pruebas de homologación: Realización de pruebas rigurosas para verificar la estabilidad, el rendimiento y la interoperabilidad de la solución SRv6.
• Resultados esperados
  • Validación de la solución SRv6 con FULL SIDs.
  • Documentación técnica de las configuraciones, los procedimientos de implementación y los resultados de las pruebas.

Homologación e implementación en uSID (Micro-SID)

• Objetivos
  • Integrar la solución uSID, con el objetivo de optimizar el espacio de direccionamiento y simplificar las tablas de enrutamiento.
  • Lograr una mayor granularidad y flexibilidad en la gestión de rutas.
• Principales actividades
  • Planificación e implementación: Desarrollo de un plan detallado para la introducción de uSID en la red.
  • Actualización de los equipos: Asegurar que todos los dispositivos de red tengan su firmware/software actualizado para soportar uSID. 
  • Configuración y validación de uSID: Implementación de uSIDa en una configuración controlada en un laboratorio de redes de transporte, seguida de pruebas de validación de la infraestructura y los servicios.

Estudio de caso: implementación práctica

Después de la homologación de la solución SRv6, los pasos de implementación incluyen las siguientes actividades técnicas y formales:

• Taller de soluciones para las áreas involucradas:
  • Realización de un taller para las áreas involucradas, con el objetivo de ofrecer capacitación y una comprensión detallada de la solución SRv6
• Actualización de la documentación y presentación (clúster de agregación):
  • Revisión y actualización de la documentación y presentación técnica en tres niveles de detalle jerárquicos (clúster de agregación)
• Actualización del software de los equipos de esta capa (clúster de agregación):
  • Ejecución del proceso de actualización del software en los equipos pertenecientes a las capas del clúster de agregación
• Actualización de las políticas de seguridad:
  • Revisión y actualización de las políticas de seguridad en las capas involucradas.
• Adecuación de la infraestructura para soportar uSID
• Migración del servicio:
  • Topología Anillo 1:
    • Migración de los servicios L3VPN y L2VPN – (L3VPN DualStack SRv6+MPLS)
    • Migración de los servicios L3VPN y L2VPN – (L2VPN VPLS/VLL a EVPNL2)
  • Topología Anillo 2:
    • Migración de los servicios L3VPN y L2VPN – (L3VPN DualStack SRv6+MPLS)
    • Migración de los servicios L3VPN y L2VPN – (L2VPN VPLS/VLL a EVPNL2)
  • Topología Anillos 3 y 4:
    • Migración de los servicios L3VPN y L2VPN – (L3VPN DualStack SRv6+MPLS)
    • Migración de los servicios L3VPN y L2VPN – (L2VPN VPLS/VLL a EVPNL2)

Estas actividades representan una estructura técnica y formal para la implementación exitosa de la solución SRv6 luego de la fase de homologación.

Perspectivas futuras

La segunda fase del proyecto en VIVO consiste en integrar la tecnología SRv6 con las plataformas SDN y SDTN. Además de esta integración, desarrollaremos estudios de casos de ingeniería de tráfico y trabajaremos en productos que utilicen Flex-Algo. También estudiaremos la extensión de uSID SRv6 al centro de datos y la adición de IPM (Integrated Performance Measurement) para tener una mejor visibilidad del SLA ofrecido a nuestros clientes.

Lecciones aprendidas

A continuación, podemos ver aspectos importantes que fueron resueltos durante el desarrollo del proyecto en el laboratorio:

• El Locator de un dominio de red determinado siempre debe coincidir con los bloques, de lo contrario no existirá programación SRV6 para el servicio.
• Cabe señalar que Cisco soporta un Full-SID (estructura de 128 bits compuesta por un bloque SRv6 de 40 bits, un identificador de nodo de 24 bits, un identificador de función de 16 bits, argumentos, relleno) o uSID. En un escenario de múltiples proveedores con Full-SID, todos los SID instanciados deben ser coherentes con el mismo bloque SRv6.
• Huawei siempre utiliza next-hop IPv6 para las familias de direcciones BGP vpnv4, vpnv6 y evpn en escenarios de red con SRv6 con o sin compresión; tuvimos que subir todas las familias BGP en una nueva sesión IPv6 con los reflectores de la red.
• Descubrimos bugs en la versión 16.0.R18 de Nokia que causaban importantes impactos en los equipos; la versión se abandonó para su uso en el proyecto de VIVO.
• Descubrimos bugs en la versión V800R021 de Huawei; después de habilitar SRV6, la sesión BGP falla debido a un subcódigo desconocido en BGP-LS.
• Para mantener la compatibilidad de los bits de locator y función entre los equipos de Cisco y Nokia, fue necesario configurar un rango MPLS dinámico en los equipos Nokia.
• En escenarios de L3VPN Gateway, Nokia recomienda fuertemente utilizar un RT (Route-Target) por tecnología; de lo contrario, se podría enrutar a elementos que no soportan o soportan SRV6, parámetros BGP que podrían terminar provocando problemas en la red;
• La versión de IOS Cisco 7.3.2 no dispone de ISIS TAG nativo para los Locators, lo que dificulta mucho la publicidad de rutas utilizando políticas basadas en TAG; las versiones 7.7.1 o superiores resuelven este problema.
• El comando advertise-ipv6-next-hop es necesario en los equipos Nokia, pero genera muchas rutas innecesarias, por lo que tuvimos que utilizar políticas para controlar el anuncio de rutas reduciendo las tablas infladas.
• Para los servicios con tecnología EVPN, es obligatorio tener Route-Distinguisher diferentes y tipo 1 <IP generalmente loopback>:<ID>)> RFC 7432.
• Es necesario instalar licencias en los equipos Huawei para activar la funcionalidad SRv6 con y sin compresión.
• Para que funcione extended next-hop encoding, es necesario habilitar en Nokia las opciones RFC 8950 “advertise-ipv6-next-hops” (anuncio de rutas con next-hop IPv6) y “extended-nh-encoding” (habilita capability).
• En escenarios multiproveedor, constatamos diferencias en el uso de OAM; en Nokia es posible ejecutar el comando ping con el bloque locator (/64), además de las funciones/SID asignadas. En el caso de Cisco y Huawei, se requieren funciones/SID asignadas “TLV 27” (END-OP.SID “sub-TLV 5”). Para Cisco y Huawei, END-OP.SID se debe configurar manualmente.
  • En Cisco, END-OP-SID se asigna automáticamente, concatenando el Locator X:11:X (HEXA).
• Huawei no soporta transposition/update-packing.
• Fue necesario implementar mecanismos anti-loop para los Locators en topologías de anillo.
• El ASBR resume los Locators de CORE dentro de Access y viceversa (funcionamiento interclúster), también recibe los bloques de cada clúster ya resumidos. A nivel local, en el clúster acceso se divulgarán todos los loopbacks internos y se resumirán todas las rutas externas.
• Hasta que tengamos listos los controladores SDN, optamos por anunciar los Locators vía IGP (ISIS) y las rutas IPv6 unicast vía BGP.
• En el proyecto de SRV6, se agregó el add-path para las familias vpnv4/vpnv6 y EVPN en todas las capas.
• Optamos por anunciar las interfaces loopback dentro de ISIS con diferentes métricas para IPv4 e IPv6, siendo las mejores métricas para IPv6 y las peores para IPv4, lo que facilita el proceso de elección entre rutas v4 y v6. Esto fue necesario porque en el escenario de Dual Connected tenemos las mismas rutas con next-hop IPv4 label y IPv6 uSID. Cisco siempre resuelve el next-hop de las rutas en la tabla FIB y no verifica si existe un LSP para un camino determinado antes de instalar la ruta en la tabla, por lo que a veces la resolución de los servicios se hacía en la FIB con MPLS en vez de SRv6.
• Para ajustar las diferentes métricas de IPv4 e IPv6 en el protocolo ISIS en la interfaz loopback, tuvimos que usar políticas tanto en Nokia como en Huawei. Después de un tiempo, descubrimos que los algoritmos en Huawei no se resolvían, ya que se necesitaba la información de router-id v6 para su funcionamiento. Esto se generó porque Nokia ya no enrutaba el sistema dentro del proceso ISIS, sino a través de políticas, lo que hacía imposible agregar el router-id v6 a la base de datos de ISIS.
• Para resolver el problema antes expuesto, empezamos a publicar los loopbacks v4 y v6 con el mismo valor de métrica dentro de ISIS, y Nokia empezó a agregar nuevamente el sistema al proceso de ISIS. Con esta configuración los loopbacks IPv4 e IPv6 volvieron a tener los mismos costos en toda la red. Nokia y Huawei tienen comandos para que los equipos siempre prefieran uSID SRv6 antes que MPLS, mientras que Cisco no, por lo que tuvimos que manipular el atributo weight en BGP en la sesión PE con el reflector de ruta para que prefiera siempre IPv6.
• Cisco aún no soporta la funcionalidad L3 EVPN (RT5) con transporte SRv6 uSID en la versión 7.8, con lo cual no es posible cambiar el 100% de los servicios de red a la tecnología EVPN. Las versiones posteriores la soportan, pero esto no se ha probado.

Conclusión

La implementación de SRv6 uSID representa un paso audaz para Telefônica VIVO y destaca su compromiso con la innovación. El propósito de este artículo fue compartir una descripción general completa de este trabajo, desde los conceptos fundamentales hasta la aplicación práctica. La transformación digital está en plena marcha y Telefônica VIVO va a la vanguardia, dando forma al futuro de las telecomunicaciones.

Si te interesa conocer más sobre nuestra implementación de SRv6, puedes ver la presentación en el Foro Brasilero de IPv6 [Foro Brasilero de IPv6] 8 de diciembre de 2023 (Parte 2)].