Implementação do SRv6 uSID na Infraestrutura da Telefônica VIVO

Ao associar o EVPN ao SRv6, é possível criar uma solução que integra eficientemente roteamento de camada 3 com conectividade de camada 2 sobre a infraestrutura SRv6. O SRv6 fornece um método de encaminhamento baseado em segmentos, o que é útil para otimizar o roteamento de tráfego IP. Quando combinado com o EVPN, que é capaz de lidar com requisitos de camada 2, você obtém uma solução abrangente para redes que requerem tanto funcionalidades de serviços de camada 2 quanto de camada 3.

Benefícios para a Telefônica VIVO

Eficiência de Roteamento: Reduz a complexidade das tabelas de roteamento, melhorando a eficiência na transmissão de dados. O SRv6 permite uma arquitetura de rede mais simples e escalável, utilizando o conceito de roteamento na origem. Isso pode reduzir a complexidade da rede, facilitando a implantação e o gerenciamento.

Baixa Latência: A capacidade de direcionar o tráfego de forma mais direta reduz a latência, aprimorando a qualidade dos serviços oferecidos.

Maior Controle de Tráfego: A Telefônica VIVO ganha mais controle sobre a rota do tráfego, permitindo uma alocação mais eficiente de recursos.

Flexibilidade na Programabilidade de Rede: O SRv6 fornece uma estrutura de rede programável, permitindo mais flexibilidade na definição e adaptação do comportamento da rede. Essa programabilidade pode ser benéfica para customizar a rede de acordo com as necessidades específicas do negócio, e para se adaptar rapidamente com a demanda crescente de novos requisitos do mercado.

Melhoria na Resiliência da Rede: O SRv6 suporta recondução rápida (sub-50ms) e oferece mecanismos para criar caminhos de rede altamente resilientes. Isso pode aprimorar a confiabilidade e a disponibilidade geral da infraestrutura de rede.

Balanceamento de Carga:  A solução SRv6 fornece balanceamento de carga nativo, ao contrário do MPLS, que ainda apresenta problemas com balanceamento de carga. No MPLS, a entropia para a seleção de Equal-Cost Multi-Path (ECMP) está no pacote IP interno, portanto, os roteadores devem percorrer a pilha de rótulos MPLS para obter acesso ao cabeçalho IP usado para hash.

No SRv6, o Ingress PE calcula um hash no pacote do cliente e grava o resultado no campo Flow Label do cabeçalho IPv6 externo adicionado. O resto da rede aproveita esse rótulo de fluxo para realizar a seleção de ECMP com apenas uma olhada no cabeçalho externo, sem a necessidade de se aprofundar nas camadas de encapsulamento.

Desafios e Soluções

Implementar uma mudança tão significativa não é uma tarefa fácil, tanto no âmbito técnico quanto no processual, pois mudanças tecnológicas de grande relevância na maioria das vezes requerem reestruturações nos fluxos de trabalho, capacitação das equipes, comprometimento etc.

Neste blog discutiremos potenciais obstáculos e ofereceremos soluções práticas, destacando o compromisso da Telefônica VIVO com a excelência operacional.

1. Jornada:

Nos tópicos abaixo descreverei um pouco da jornada de trabalho trilhada para alcançarmos o objetivo de implantar a tecnologia SRv6 na rede da Telefonica VIVO.

Convicto da necessita de implantar o Segment Routing na rede, iniciamos muitas discussões internas sobre estratégias de implementação sendo elas:

• Implantar SR-MPLS inicialmente e com as necessidades futuras de escalabilidade e a modernização da rede faríamos uma troca para SRv6;
• Implementar SRv6 sem fase intermediaria.

Porém esta jornada de trocar duas (2) vezes a tecnologia em um provedor do porte da Telefonica VIVO é muito traumático e custoso, então decidimos pular uma fase e irmos direto para SRv6. Neste momento houve muitas dúvidas quanto à maturidade da tecnologia para uma implementação massiva na rede, porém uma solução de evolução de rede para o seu ponto de destino seria muito mais vantajosa, assim evitamos Dupla Transição, Investimentos Não Capitalizados associados à  Potencial subutilização dos investimentos em SR-MPLS se a migração para SRv6 acontecer rapidamente, Reconfiguração da Rede e Duplicidade de Esforços, Prolongamento do Processo e mais do que nunca Obsolescência Técnica associado ao risco da tecnologia SR-MPLS se tornar obsoleta mais rapidamente com o avanço do SRv6.

Visto os pontos iniciamos um longo período de discussão com os arquitetos da Cisco, Huawei e Nokia buscando garantir que a tecnologia estava madura suficiente para uma implantação massiva.

1. Metodologia empregada

A metodologia de trabalho aplicada veio do modelo Agile, onde fazíamos reuniões curtas no primeiro horário do dia diariamente com todo o time do projeto para alinharmos pontos de maneira rápida e constante, e semanalmente nos reuníamos um dia inteiro no laboratório da Telefonica VIVO para compartilhar as realizações da semana e discutirmos mais profundamente sobre os problemas encontrados.

A figura abaixo descreve como planejamos todo desenvolvimento do trabalho.

1. Caminho trilhado

Este capítulo apresenta a trajetória formal de evolução tecnológica da rede de transporte da VIVO para a adoção de Segment Routing over IPv6 (SRv6), começando pela homologação de uma solução baseada em FULL Segment Identifiers (SIDs), evoluindo para uma arquitetura que incorpora o uso de Micro-Segments Identifiers (uSID). O uSID fornece a capacidade de compactar o cabeçalho SRv6, portanto, com apenas um cabeçalho IPv6 podemos codificar 6 uSIDs no endereço IPv6 de destino. Isto alcança melhor desempenho do que com VxLAN ou MPLS. O uSID se tornou a solução padrão do setor e é apoiado por todos os fornecedores.

Inicialmente, optamos por realizar testes abrangentes para avaliar a viabilidade de incorporar as funcionalidades essenciais necessárias para atender aos serviços atualmente em operação na rede da VIVO. A intenção é assegurar que, caso seja possível atender todas as exigências da rede atual, possamos, posteriormente, introduzir novas funcionalidades com o objetivo de aprimorar o sistema de transporte. A abordagem adotada visa realizar uma transição gradual, considerando que a substituição do MPLS por outra tecnologia é um processo delicado. Antes de nos direcionarmos diretamente para o objetivo final, é imperativo garantir que todos os serviços existentes funcionem de maneira consistente, sem interrupções para os clientes. Portanto, elaboramos uma lista abrangente dos serviços e cenários de atendimento, destacando a aplicação da tecnologia SRv6, como medida para assegurar a viabilidade e sucesso da implementação.

 A figura abaixo mostra as principais atividades realizadas para o planejamento e execução do FOA (First Office Application).

Homologação

Fase 1: Homologação Inicial em Full SIDs

• Objetivos
  • Avaliar a compatibilidade de equipamentos e a viabilidade técnica da solução SRv6.
  • Homologar a implementação de SRv6 com o uso de FULL SIDs para garantir o entendimento da tecnologia e sua aplicabilidade na infraestrutura existente.
  • Atividades Principais
  • Seleção de Equipamentos: Especificação, seleção de dispositivos de rede que suportam SRv6 e montagem do Setup de testes.
  • Ambiente de Testes: Configuração de um ambiente de laboratório representativo para simulação e validação de cenários de rede.
  • Testes de Homologação: Execução de testes rigorosos para verificar a estabilidade, desempenho e interoperabilidade da solução SRv6.
• Resultados Esperados
  • Validação da solução SRv6 com FULL SIDs.
  • Documentação técnica das configurações, procedimentos de implementação e resultados dos testes. 

Fase 2: Homologação e Implantação em uSID (Micro-SID)

• Objetivos
  • Integrar a solução uSID, visando a otimização do espaço de endereçamento e a simplificação das tabelas de encaminhamento.
  • Alcançar maior granularidade e flexibilidade no gerenciamento de rotas.
• Atividades Principais
  • Planejamento de Implementação: Desenvolvimento de um plano detalhado para a introdução de uSID na rede.
  • Atualização de Equipamentos: Assegurar que todos os dispositivos de rede estejam com o Firmware/Software atualizado para suportar uSID.
  • Configuração e Validação de uSID: Implementação de uSIDs em um setup controlado em Laboratório da rede de transporte, seguido por testes de validação de infraestrutura e serviços.

Estudo de Caso: Implementação na Prática:

Após a homologação da solução SRv6, os passos para a implantação incluem as seguintes atividades técnicas e formais:

• Workshop da Solução para as Áreas Envolvidas:
  • Realização de workshop para as áreas envolvidas, visando fornecer treinamento e compreensão detalhada da solução SRv6.
• Atualização de Documentação e Apresentação (Cluster de Agregação):
  • Revisão e atualização da documentação e apresentação técnica em três níveis de detalhes hierárquicos (Cluster de Agregação)
• Upgrade de Software dos Equipamentos Dessa Camada (Cluster de Agregação):
  • Execução do processo de upgrade de software nos equipamentos pertencentes às camadas de Cluster de Agregação.
• Atualização de Políticas de Segurança:
  • Revisão e atualização das políticas de segurança nas camadas envolvidas.
• Adequação da Infraestrutura para Suportar uSID.
• Migração de Serviço:
• Topologia Anel 1:
  • Migração dos serviços L3VPN e L2VPN – (L3VPN DualStack SRv6+MPLS).
  • Migração dos serviços L3VPN e L2VPN – (L2VPN VPLS/VLL para EVPNL2).
• Topologia Anel 2:
  • Migração dos serviços L3VPN e L2VPN – (L3VPN DualStack SRv6+MPLS).
  • Migração dos serviços L3VPN e L2VPN – (L2VPN VPLS/VLL para EVPNL2).
• Topologia Anel 3 e 4:
  • Migração dos serviços L3VPN e L2VPN – (L3VPN DualStack SRv6+MPLS).
  • Migração dos serviços L3VPN e L2VPN – (L2VPN VPLS/VLL para EVPNL2).

Essas atividades representam uma estrutura técnica e formal para a implementação bem-sucedida da solução SRv6 após a fase de homologação.

Perspectivas Futuras:

A segunda fase do projeto na VIVO consiste em integrar a tecnologia SRv6 com as plataformas de SDN e SDTN. Além desta integração iremos desenvolver estudos de caso de engenharia de tráfego e trabalhar produtos usando Flex-Algo. Também analisaremos a extensão do uSID SRv6 ao DataCenter e a adição de IPM (Integrated Performance Measurement) para ter melhor visibilidade do SLA oferecido aos nossos clientes.

Lições aprendidas:

Abaixo podemos verificar pontos importantes que foram resolvidos durante o desenvolvimento do projeto em laboratório:

• O Locator de um determinado domino de rede, deve sempre combinar com os blocos, caso contrário não existirá programação de SRV6 para o serviço;
• Deve-se observar que a Cisco suporta um Full-SID (estrutura de 128 bits composta por bloco SRv6 de 40 bits, identificador de nó de 24 bits, identificador de função de 16 bits, argumentos, preenchimento) ou uSID. Em um cenário de vários fornecedores com Full-SID, todos os SIDs instanciados devem ser consistentes com o mesmo bloco SRv6.
• A Huawei utiliza sempre next-hop IPv6 para as famílias de endereços BGP vpnv4, vpnv6 e evpn em cenários de rede com SRv6 com ou sem compactação, tivemos que subir todas as famílias BGP em uma nova sessão IPv6 com os refletores da rede;
• Descobrimos BUGs na release 16.0.R18 da Nokia que causavam grandes impactos no equipamento, a versão foi abandonada para uso no projeto da VIVO;
• Descobrimos BUGs na release V800R021 da Huawei, após habilitar SRV6 a sessão BGP cai por conta de um subcódigo não conhecido no BGP-LS.
• Para manter compatibilidade dos bits de locator e função entre equipamentos da Cisco e da Nokia, foi necessário configurar um range de MPLS dinâmico nos equipamentos da Nokia;
• Em cenários de L3VPN Gateway, a Nokia fortemente recomenda utilizar um RT (Route-Target) por tecnologia, caso contrário, pode-se encaminhar para elementos que não suportam ou suportam SRV6, parâmetros BGP que podem acabar gerando problemas na rede;
• A versão de IOS Cisco 7.3.2 não faz ISIS TAG nativo dos Locators, no que dificulta muito divulgar as rotas usando políticas baseadas em marcação de TAG, a versão 7.7.1 ou superior resolve essa questão;
• O comando advertise-ipv6-next-hop é necessário nos equipamentos da Nokia, porém ele gera muitas rotas desnecessárias, tivemos que usar políticas para controlar o anúncio das rotas diminuindo tabelas infladas;
• Para serviços com tecnologia EVPN é obrigatório ter Route-Distinguisher diferentes e type 1 <IP geralmente loopback>:<ID>)> RFC 7432;
• É necessário instalar licenças nos equipamentos da Huawei para ativar a funcionalidade de SRv6 com e sem compressão;
• Para funcionamento extended next-hop encoding é requerido habilitar na Nokia a RFC 8950 “advertise-ipv6-next-hops” (anúncio de rotas com next-hop IPv6) e “extended-nh-encoding” (habilita capability);
• Em cenários multivendor constatamos diferenças no uso do OAM, na Nokia é possível executar o comando ping com o bloco locator (/64), além das funções/SID alocadas. No caso da Cisco e Huawei, são necessárias funções/SID alocadas “TLV 27” (END-OP.SID “sub-TLV 5”) Cisco e Huawei o END-OP.SID precisa ser configurado manualmente.

Na Cisco o END-OP-SID é atribuído automaticamente, concatenando o Locator X:11:X (HEXA);

• Huawei não suporta transposition/update-packing;
• Foi necessário implementar mecanismos anti-loop para Locators em topologias em anel;
• O ASBR sumariza os Locators do CORE para dentro do Acesso e vice-versa. (funcionamento Intercluster), também recebe já sumarizado os blocos de cada Cluster. Localmente em cluster acesso, todas as loopbacks internas serão divulgadas e todas as rotas externas serão sumarizadas;
• Até que tenhamos os controladores SDN prontos escolhemos anunciar os Locators via IGP (ISIS) e rotas IPv6 unicast via BGP;
• No projeto do SRV6, foi adicionado o add-path para as famílias vpnv4/vpnv6 e EVPN em todas as camadas.
• Escolhemos anunciar as interfaces loopback dentro do ISIS com métricas diferentes para IPv4 e IPv6, sendo as melhores métricas para IPv6 e as piores para IPv4, com isso facilitamos o processo de escolha entre rotas v4 e v6. Isso foi necessário, pois no cenário de Dual Connected temos as mesmas rotas com next-hop IPv4 label e IPv6 uSID. A Cisco, sempre resolve o next-hop das rotas na tabela FIB e não checa se existe um LSP para um determinado caminho antes de instalar a rota na tabela, dessa forma, algumas vezes a resolução dos serviços era resolvida na FIB com o MPLS no lugar de SRv6;
• Para ajustar métricas IPv4 e IPv6 diferentes no protocolo ISIS na interface loopback, tivemos que usar políticas tanto na Nokia quanto na Huawei, passado um tempo, descobriu-se que os algos na Huawei não eram resolvidos, pois era necessário a informação de router-id v6 para funcionamento. Isso foi gerado, porque a Nokia não encaminhava mais a system dentro do processo ISIS, e sim via política, o que impossibilitava adicionar o router-id v6 na database ISIS.
• Para resolver o problema exposto acima, passamos a divulgar as loopbacks v4 e v6 com o mesmo valor de métrica dentro do ISIS, e a Nokia passou a acrescentar novamente a sytem no processo ISIS. Com esta configuração as loopbacks IPv4 e IPv6 voltaram a ter os mesmos custos em toda a rede, a Nokia e a Huawei possuem comando para que os equipamentos prefiram sempre o SRv6 uSID ao invés do MPLS já a Cisco não, então tivemos que manipular o atributo weight no BGP na sessão do PE com o refletor de rotas para preferir sempre o IPv6.
• Cisco ainda não tem suporte a funcionalidade de L3 EVPN (RT5) com transporte SRv6 uSID na versão 7.8 no que inviabilizou passar 100% dos serviços da rede para tecnologia EVPN; Isso é suportado em versões posteriores, mas não foi testado.

Conclusão

A implementação do SRv6 uSID representa um passo ousado para a Telefônica VIVO, destacando seu compromisso com a inovação. Este blog buscou fornecer uma visão abrangente dessa jornada, desde os conceitos fundamentais até a aplicação prática. A transformação digital está em pleno andamento, e a Telefônica VIVO está na vanguarda, moldando o futuro das telecomunicações.

Se você estiver interessado em saber mais sobre nossa implantação do SRv6, você pode assistir à palestra no Fórum IPv6 Brasileiro [Fórum Brasileiro de IPv6] 8 de dezembro de 2023 (Parte 2)].