Resumo

  • Estudo revisado por pares de 2026 estima que UPDATEs em torno de eventos reconstruídos de RPKI ficam abaixo de 1% do volume observado.
  • O método inclui todos os UPDATEs numa janela de convergência, o que pode ampliar o volume atribuído.
  • A proporção não mede o trabalho de cada par, mudanças de caminho, Route Refresh ou acesso dos usuários.

A proporção responde a uma pergunta concreta

O achado merece crédito. Samuele Quinzi, Cristel Pelsser e Giuseppe Di Battista estimam, em artigo revisado por pares publicado na Proceedings of the ACM on Networking, o volume de UPDATEs BGP observado perto de mudanças em ROAs. O resumo informa que as atualizações associadas seguem abaixo de 1% do total observado, mesmo com o crescimento do RPKI e da tabela de rotas. A pergunta é se esses eventos dominam o fluxo de mensagens de roteamento. Na série estudada, não.

Em um artigo convidado no blog da APNIC, Quinzi explica que os autores reconstroem eventos com dados históricos e contam todos os UPDATEs numa janela de convergência como relacionados. Alguns podem ter outra causa; incluí-los tende a aumentar o numerador. O resultado é uma estimativa ampla de volume coincidente, não prova de que cada mensagem tenha sido causada pelo RPKI.

Estabilidade tem mais de uma medida

A proporção compara UPDATEs associados com o total observado. Não é a fração de roteadores afetados, prefixos com estado de validação alterado, caminhos escolhidos que mudaram ou tráfego de clientes interrompido. UPDATE transporta informação de roteamento; não mede diretamente se uma aplicação continua acessível.

O RIPE RIS coleta dados por sessões BGP. Seu coletor RRC00 fica em Amsterdã, usa sessões multihop e é descrito com escopo global. “Global” define o alcance do coletor, não um censo de todo caminho de encaminhamento, do uso de CPU de cada par ou da experiência de cada usuário. O total agregado tampouco mostra se poucas redes concentraram as mensagens.

A inferência inversa também falha: muitos UPDATEs não provam perda de serviço. Volume, carga por vizinho, mudanças de rota, tempo de convergência e conectividade são observações relacionadas, mas diferentes.

Route Refresh é outro tipo de trabalho

A RFC 9324 descreve um mecanismo distinto: depois de receber dados novos de validação, algumas implementações pediram Route Refresh aos pares para reavaliar rotas. A RFC alerta que isso pode transferir carga importante aos vizinhos e recomenda guardar as rotas afetadas para evitar pedidos desnecessários. Também relata casos de desligamento do ROV e encerramento de peerings.

É um risco operacional específico e uma mitigação, não uma descrição de toda implementação nem uma refutação da proporção de UPDATEs do estudo. O pedido de Route Refresh e a reanunciação posterior precisam de contadores próprios, separados da contagem de UPDATEs na janela de evento.

Ampliar a medição sem misturar métricas

Uma resposta mais ampla pede vários indicadores: UPDATEs por evento e por par; pedidos de Route Refresh e rotas reanunciadas; tempo até o estado ficar estável; frequência e duração de mudanças de caminho; e, se possível, sinais independentes de conectividade. Cada medida precisa declarar ponto de observação, período, denominador e tratamento de lacunas.

O arquivo histórico de RPKI do RIPE usa snapshots diários. A explicação da APNIC nota que mudanças breves podem ocorrer entre eles. O RPKI-Flutter registra eventos com mais frequência, mas num período recente mais curto; o artigo relata estimativas de UPDATE semelhantes na janela comum. Isso sustenta a reconstrução do volume comparado, não mede automaticamente carga por par ou experiência do usuário.

A conclusão equilibrada não é “RPKI não tem risco” nem “RPKI desestabiliza BGP”. O estudo tranquiliza sobre uma questão limitada: eventos associados ao RPKI não formam grande parte dos UPDATEs observados na série. Para avaliar estabilidade em sentido amplo, é preciso dizer qual recurso, caminho ou serviço se pretende manter estável.

Fontes

Fontes primárias e referências de protocolo: