Resumo

  • O estudo publicado pelo LACNIC em 27 de maio de 2026 diz considerar todos os updates de março de 2026 observados pelos coletores RRC15 e RRC24; logo depois, fala em mais de 2,222 bilhões de mensagens BGP consolidadas em 48 horas.
  • A tabela de estabilidade registra 2.222.981.835 mensagens. A tabela IPv4/IPv6 registra 159.964.848 e 693.016.987 updates, que somam 852.981.835 — exatamente 1.370.000.000 a menos.
  • Os subtotais de prefixos fecham em 1.436.539 e as quatro classes de ASN fecham em 86.398. O terceiro intervalo pode refletir escopo, tipo de mensagem ou estágio de processamento diferente; não prova erro.
  • Um recibo versionado deveria ligar relógios de observação e processamento, pares dos coletores, arquivos MRT, software, regras de contagem, números intermediários e tabelas finais, sem transformar a amostra em censo da região.

A conta que não fecha não é uma acusação

O artigo “Os irritantes Noisy BGP Speaker” oferece ao leitor duas conciliações claras. Os 1.146.937 prefixos IPv4 e 289.602 IPv6 resultam em 1.436.539, o total de prefixos únicos. Os 43.199 ASN estáveis, 41.650 inquietos, 1.530 ruidosos e 19 críticos resultam em 86.398, o total de ASN únicos.

Já os updates seguem outro caminho. A linha IPv4 informa 159.964.848 e a IPv6, 693.016.987. O total é 852.981.835. Na tabela anterior, o número de mensagens BGP é 2.222.981.835. A diferença: 1.370.000.000.

Seria irresponsável chamar isso de erro aritmético. O texto usa nomes diferentes. “Mensagem BGP” pode indicar uma contagem mais bruta; “update” pode ser uma unidade retida depois de filtros ou atribuída a uma família. Retiradas, mensagens sem prefixo aproveitado, dados multiprotocolo, duplicidades e falhas de parsing podem alterar os números. O que a página não traz é a regra capaz de mostrar qual hipótese vale.

O achado, portanto, é documental: falta a junção entre duas etapas da análise.

Março e 48 horas podem ser relógios distintos

Na origem dos dados, os autores citam RRC24 em Montevidéu e RRC15 em São Paulo e dizem tomar todos os updates do mês de março de 2026. No parágrafo de processamento, citam Python 3, mrtparser, pandas, NumPy e Matplotlib e afirmam ter consolidado mais de 2,222 bilhões de mensagens em um período de 48 horas.

As 48 horas talvez sejam tempo de computação. Talvez sejam dois dias observados dentro de março, um recorte combinado dos dois coletores ou outro intervalo. “Todos os updates de março” pode nomear o arquivo pesquisado, não a seleção final. As versões públicas nos três idiomas não resolvem a leitura.

Uma análise de dois dias ainda pode detectar outliers importantes. Mas não oferece a mesma cobertura temporal de um mês inteiro, com fins de semana, manutenção, incidentes e mudanças de pares. Se as 48 horas forem apenas duração do processamento, elas nada dizem sobre a rede. Por isso o método deve registrar separadamente início e fim da observação e início e fim do processamento.

A mesma cautela vale para a frase de que 0,02% dos speakers gera a maior parte da instabilidade. Dezenove sobre 86.398 é aproximadamente 0,02%; a proporção interna está correta. A persistência do grupo depende da janela, da coorte de observadores e da regra de atribuição. “Crítico” é uma classe estatística naquele recorte, não uma identidade definitiva do ASN.

Arquivo aberto não é recibo de execução

O RIPE RIS oferece um ponto de partida público raro. A documentação diz que os dados são armazenados por route collector, reunindo num arquivo o que chega dos seus pares. O padrão é rrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz; dumps são gerados normalmente a cada oito horas e arquivos de updates, a cada cinco minutos. Os diretórios de março de 2026 para RRC15 e RRC24 exibem bview e updates separados.

Isso não informa quais arquivos o código do estudo efetivamente leu. Não revela objetos parciais, falhas de download ou parsing, lacunas de pares, exclusões, nem se um bview serviu apenas para reconstruir estado ou entrou em alguma contagem. Disponibilidade pública é condição de reprodução, não substituto para o manifesto da execução.

Também não se deve ampliar a visão dos coletores. O RIPE NCC identifica o RRC15 com o PTTMetro-SP, em São Paulo, e o RRC24 como LACNIC Multihop, em Montevidéu. Cada um observa sua própria coorte de pares. Eles não contam todos os membros do LACNIC, roteadores, tráfego, usuários, incidentes ou impactos da América Latina e do Caribe.

“Mensagem” precisa de uma definição no método

A RFC 4271 distingue mensagens OPEN, UPDATE, KEEPALIVE e NOTIFICATION. A RFC 6396 distingue dumps de tabela, mensagens BGP4MP e mudanças de estado BGP4MP. O RIS Live ainda identifica metadados de estado dos pares. Essas fontes não dizem como o estudo foi programado; mostram que há mais de uma unidade plausível.

Um UPDATE pode levar vários prefixos sob atributos comuns, anúncios e retiradas, além de alcance multiprotocolo. Depois do parser, contar registros, mensagens, UPDATEs, elementos NLRI, ações por prefixo ou observações por par produz totais diferentes. Uma mudança de estado pode ajudar a explicar churn sem pertencer à tabela de updates por família.

IPv4 e IPv6 exigem outras escolhas. Uma mensagem que toca as duas famílias vale uma ou duas? O que ocorre quando nenhum item passa pelo filtro? Como tratar multi-origin, AS_SET e caminhos malformados? Quando o mesmo prefixo aparece nos dois coletores, em que etapa ele deixa de ser duplicado? Como a churn rate usa updates e prefixos anunciados por ASN, essas decisões definem seu numerador e denominador.

Doze campos bastariam para a conciliação

O recibo começaria com a identidade do estudo e duas janelas UTC: observação e processamento. Diria de forma inequívoca o que são as 48 horas e se março inteiro entrou na amostra.

Em seguida viria o manifesto dos MRT: nomes exatos, hashes, bytes, coletores, coorte agregada de pares, lacunas e erros. O uso de bview seria separado do uso de updates.

Um dicionário definiria registro MRT, mensagem BGP, UPDATE, anúncio, retirada, NLRI, ocorrência e prefixo único. Cada filtro mostraria contagem de entrada e saída. Regras para famílias, duplicação, mensagens vazias, falhas, multi-origin e atribuição a ASN teriam versão.

Uma tabela intermediária ligaria os registros aceitos às mensagens analisadas, aos updates retidos, às ações por família e à população de churn. Se os 2.222.981.835 e os 852.981.835 pertencem a universos diferentes, a linha dos 1.370.000.000 deve dizer onde e por quê.

Por fim, o recibo registraria Python, mrtparser e bibliotecas, revisão do código, hash da configuração, identificador da execução, data e correções. Uma nova versão pode melhorar a análise sem apagar a prova da versão antiga.

O limite protege quem foi medido

O texto cita bugs, configuração incorreta, equipamento, energia e ataques como causas possíveis de ruído. Não demonstra qual delas atingiu os 19 ASN críticos. Uma taxa alta não comprova intenção, dano a clientes ou negligência evitável.

Com a linhagem, um operador pode saber se apareceu por um ou muitos pares, por minutos ou durante toda a janela, e sob qual regra de origem. Um pesquisador pode repetir o teste com outra janela. O LACNIC pode corrigir uma transformação sem que isso seja lido como invalidação de todo o estudo.

A conclusão adequada é estreita: há uma medição valiosa, dois totais perfeitamente conciliados e um terceiro sem ponte pública. A transparência agora depende menos de outra figura e mais do recibo que mostre como os números já publicados foram produzidos.

Fontes