Resumo

  • No planejamento RIS do quarto trimestre de 2026, o RIPE NCC prevê uma alteração de software para incluir timestamps subsegundo nos arquivos MRT, com suporte à extensão descrita na RFC 6396. A atividade segue marcada como em andamento; não há data de entrada em operação.
  • Uma amostra de cinco minutos do RRC03 contém 188.592 registros MRT distribuídos em 300 segundos inteiros, todos com vários registros. Mais resolução pode preservar diferenças dentro de um segundo, mas não demonstra a precisão do relógio, o instante capturado nem a sincronização entre coletores.

O que o arquivo deixa ver

Às 04:00 UTC de 16 de outubro de 2026, o arquivo updates.20261016.0400.gz do RRC03 registra uma janela de cinco minutos. A leitura do cabeçalho comum MRT encontrou 188.592 registros em 300 valores de segundo. Cada segundo aparece mais de uma vez; o maior agrupamento tem 2.432 registros.

O número pode chamar atenção, mas não equivale a 2.432 mudanças de rota. São registros BGP4MP, que podem representar tipos de mensagem diferentes. A análise parou no cabeçalho de 12 bytes e não decodificou as mensagens nem os prefixos. Portanto, ela não prova que uma rota mudou, que a ordem se perdeu ou que o arquivo tornou a reconstrução impossível. Mostra apenas que registros separados compartilham o mesmo valor de segundo inteiro nessa janela.

Esse é um ponto de partida melhor para ler o planejamento do RIPE NCC do que uma promessa ampla de “mais precisão”. No item 2 do plano RIS para Q4 2026, “Melhorar a qualidade dos arquivos MRT”, a organização diz que uma mudança de software permitirá timestamps subsegundo por meio do suporte à RFC 6396. O status é “Em andamento”. A página, atualizada em 17 de setembro de 2026, não informa data, quais coletores participarão, erro medido ou resultado de uma migração.

O item seguinte não é uma explicação para esse trabalho. Ele propõe adicionar um hold timer BGP sintético ao processamento para prevenir um tipo específico de rota travada em arquivos RIB/bview. São duas mudanças com finalidades diferentes, e a evidência disponível não autoriza misturá-las.

Resolução não é atestado de precisão

A RFC 6396 define o cabeçalho comum do MRT com um timestamp inteiro de quatro octetos, em segundos desde a época UTC e sem segundos intercalares. Nos tipos estendidos, um desvio de microsegundos sem sinal e com 32 bits é somado ao timestamp. BGP4MP_ET é um tipo que usa essa representação ampliada.

Se a aplicação que produz o arquivo atribuir deslocamentos diferentes a registros que hoje dividem um segundo, os leitores poderão conservar uma ordem temporal mais detalhada dentro daquele fluxo. O benefício é real: uma ferramenta pode mostrar diferenças que o arredondamento anterior escondia. Também pode evitar que o analista descarte a sequência original ao transformar cada valor em um segundo inteiro.

O campo, no entanto, descreve a granularidade que o formato comporta. Não informa a proximidade da leitura em relação a uma referência, nem a diferença entre relógios distintos. Tampouco diz em que ponto o RIS atribuiu o instante: chegada da mensagem, processamento ou outro evento. Essas três perguntas — resolução, precisão e semântica de captura — precisam de respostas próprias.

O modelo de desempenho do NTP separa offset, jitter, dispersão e distância de sincronização. A referência não sugere que o relógio do RIS esteja errado; ela ilustra que um valor com mais casas decimais não equivale a uma medição com incerteza conhecida. A extensão pode melhorar a representação sem fornecer, ela mesma, um certificado de tempo.

O limite de cada observação

Os arquivos do RIS são registros de observação de coletores e pares. Não constituem uma visão completa da Internet. Para interpretar uma linha, importam o coletor, o tipo e o subtipo MRT, o intervalo do arquivo e a etapa em que o timestamp foi aplicado. Acrescentar frações de segundo fortalece uma dimensão do contexto, não transforma vários pontos de observação em uma linha do tempo global já sincronizada.

A amostra do RRC03 foi mantida pequena e reproduzível: um arquivo de cinco minutos, recuperado depois do horário Last-Modified, com hash local e contagem feita apenas no cabeçalho comum. O total de registros não mede rotas únicas, anúncios, prefixos ou impacto operacional. O máximo por segundo não demonstra congestionamento, falha ou comportamento de outros coletores. O leitor pode baixar o mesmo arquivo e refazer a contagem.

Uma diferença de microsegundos também não basta para afirmar que um evento causou outro. Se o campo marca um momento de processamento, e não necessariamente a mesma etapa em todos os pontos, comparar as horas pode produzir precisão aparente. Entre coletores, entram ainda as diferenças entre relógios e caminhos de observação. A representação mais detalhada deixa a comparação mais legível, mas não verifica a hipótese que o pesquisador constrói sobre ela.

Como tornar o lançamento auditável

Quando a mudança entrar em operação, o anúncio precisa identificar os coletores e tipos MRT cobertos, a data de corte e o modo de distinguir os arquivos novos dos antigos. Deve definir qual evento o timestamp representa e dizer se os analisadores, bancos e exportações posteriores retêm os microsegundos.

O estado do relógio precisa ser apresentado em separado. Uma descrição da forma de monitorar sincronização e incerteza, com escopo e período de observação, permite decidir que tipo de comparação está apoiado. Se o RIPE NCC não divulgar determinada métrica, explicitar a ausência evita que o formato seja lido como garantia implícita.

Um exemplo verificável pode acompanhar a cadeia inteira: baixar, descompactar, analisar e exportar, mostrando que o timestamp não é arredondado e que a ordem do arquivo é preservada. Uma nota de compatibilidade pode cobrir o período de formatos mistos. Nada disso exige prometer precisão de microsegundos para cada evento arquivado. O objetivo é que o usuário conheça o alcance da medida que está usando.

É razoável melhorar a resolução dos arquivos MRT. Mas uma melhoria de formato só vira evidência interpretável quando seus limites também estão documentados. Por enquanto, a página do Q4 confirma uma tarefa em andamento, enquanto o arquivo do RRC03 confirma somente quantos registros distintos receberam os mesmos segundos inteiros em uma amostra de cinco minutos.

Fontes