Resumo

  • No relato de 13 de outubro, a LACNIC recomenda receber todas as rotas BGP pela fibra e apenas uma rota padrão via LEO, para que o satélite assuma o tráfego quando a conexão de fibra falhar.
  • A regra não detecta o rompimento de um cabo. O relato registra exercícios, mas não identifica implantação em operadora, temporizador de retirada, teste de capacidade ou resultado de recuperação.

Uma recomendação depois do encontro

O CaribNOG 32 ocorreu em Willemstad, Curaçao, de 7 a 9 de outubro. Em publicação do dia 13, a LACNIC informa que Alejandro Acosta e Nicolás Antoniello conduziram uma sessão técnica, precedida por uma introdução de Mark Kosters, CTO da ARIN. O relato diz que a orientação considerou a exposição a cabos submarinos, tempestades e outros riscos regionais. É uma descrição da própria LACNIC, não um levantamento independente das redes das ilhas.

A recomendação é específica: conectar-se a pelo menos uma rota submarina de fibra, de preferência a mais de uma; receber a tabela BGP completa pela fibra; e aceitar apenas uma rota padrão em um enlace de satélite de órbita baixa. O satélite levaria tráfego quando a rota de fibra falhasse. A LACNIC alerta que um enlace LEO pode não dar conta do tráfego de muitos ISPs, mas não publica capacidade, perfil de carga ou teste para quantificar o limite.

Falta definir quando as rotas serão retiradas

Uma rota padrão atende destinos sem entrada mais específica; ela não detecta falhas. As rotas de fibra mais específicas continuam sendo usadas para seus destinos. O tráfego só chega à rota padrão via satélite depois que essas rotas são retiradas ou a política muda. Se a falha deixar rotas antigas instaladas, o backup pode não entrar e os pacotes seguem por um caminho interrompido.

O ponto decisivo é o sinal que provoca a retirada. A queda da interface basta? A rede espera a sessão BGP cair, usa BFD ou monitora o serviço com uma sonda? Quanto tempo uma rota pode permanecer? Como evitar comutações sucessivas quando a fibra oscila? A publicação descreve a topologia desejada, mas não informa esses parâmetros nem relata teste em rede de produção.

Cada mecanismo cobre uma parte

O texto aborda validação de origem com RPKI, filtros contra vazamentos BGP e BFD. A RFC 6811 verifica se o AS de origem está autorizado para um prefixo; não valida todo o caminho AS_PATH. O mecanismo da RFC 9234 depende de vizinhos eBGP concordarem sobre os papéis e marcarem as rotas, além da política do operador. Nenhum deles comprova sozinho que uma rota está alcançável ou que a configuração foi implantada.

A LACNIC afirma que BFD pode reduzir a detecção de cerca de 90 segundos para milissegundos. Pela RFC 5880, o prazo depende dos intervalos negociados e do multiplicador de detecção; o relato não dá os temporizadores. A descoberta da MTU de caminho IPv6 também exige que mensagens ICMPv6 passem, como descreve a RFC 8201. Os exercícios de DNSSEC e validação RPKI comprovam formação, não adoção em produção.

O registro público sustenta uma recomendação e exercícios. Não revela quantas redes a adotaram, se a capacidade LEO suporta uma interrupção nem o tempo de recuperação.

Fontes: relato posterior da LACNIC; agenda do CaribNOG 32; RFC 6811; RFC 9234; RFC 5880; RFC 8201.