Resumo

  • A RFC 8210 define o serial como uma versão lógica crescente e circular dentro da linhagem de um cache; seriais de caches, sessões ou versões de protocolo diferentes não são comparáveis.
  • O recebimento completo pelo roteador, a sessão, os temporizadores e as observações de validação a montante são provas distintas que não podem ser deduzidas do serial.
  • O monitoramento de atualidade deve manter um livro-razão de sincronização com tempos de observação, e não ordenar caches globalmente pelo número do serial.

A comparação parece óbvia: o cache A informa 90.000 e o cache B, 12.000. Um painel ordena os valores e chama A de mais recente. Cada número pode estar correto, mas a conclusão continua sem fundamento.

A RFC 8210 define Serial Number como um inteiro sem sinal de 32 bits, estritamente crescente e sujeito a retorno circular. Ele representa a versão lógica de um cache. O cache só incrementa o valor depois de obter com sucesso uma atualização de um cache pai ou dos dados RPKI primários, e não pode expor o conteúdo do novo serial antes de concluir essa obtenção.

Isso estabelece uma ordem apenas dentro do escopo certo. A própria RFC afirma que seriais não são comensuráveis entre caches ou versões do protocolo e não precisam sobreviver a uma reinicialização. O Session ID identifica uma instância do cache e vincula a sequência produzida por ela. A comparação exige, em conjunto, versão do protocolo, sessão e serial.

O serial é, portanto, uma posição numa sequência local, não um relógio universal. Um cache recém-iniciado pode ter dados atuais num número baixo. Um cache antigo pode exibir um número alto embora sua última atualização a montante seja mais velha. Comparar apenas os números elimina a identidade que lhes dá sentido.

Há outra fronteira na troca entre roteador e cache. O roteador envia um Serial Query para pedir alterações posteriores ao seu valor atual. Se houver histórico suficiente, o cache envia o menor conjunto combinado necessário à sincronização. Caso contrário, pede Cache Reset e transfere o conjunto completo. O roteador só adota o serial do End Of Data PDU depois de receber toda a resposta.

Esse evento de conclusão importa. O cache pode ter avançado enquanto o roteador ainda não recebeu a nova versão. Uma notificação é apenas um sinal para consultar. O serial atual do roteador prova qual foi o último conjunto completo recebido daquele cache, não qual é o estado mais novo disponível em outro lugar.

A RFC 8210 também separa tempo e sequência. Refresh e Retry orientam consultas posteriores; Expire limita por quanto tempo dados anteriores podem continuar em uso sem nova consulta bem-sucedida. A contagem começa no recebimento do End Of Data. O serial não mostra quanto desse prazo resta.

Os manifestos de repositório reforçam a distinção. A RFC 9286 combina um manifestNumber monotonicamente crescente com campos explícitos thisUpdate e nextUpdate, além de regras para manifestos vencidos ou emitidos cedo demais. Mesmo numa linhagem de publicação, ordem sequencial e validade temporal são evidências diferentes.

Um registro útil deve guardar identidade do cache, versão, Session ID, serial, hora do End Of Data bem-sucedido, valores de Refresh, Retry e Expire, última observação de validação a montante e contexto de âncoras de confiança e política. Tempos de manifestos do repositório devem ficar em campos próprios, nunca ser inferidos do serial RTR.

Isso também preserva a incerteza. Um roteador pode provar que completou o serial 200 da sessão X às 10h04 e que os dados não expiraram. Esses fatos não provam que outro cache não possuía estado a montante posterior, que todos os repositórios convergiram ou que outro roteador recebeu o mesmo conteúdo naquele instante.

Não se alega aqui falha real de cache ou incidente de dados antigos. O ponto é probatório: o serial é confiável porque ordena estados dentro de uma linhagem comparável. Usá-lo como tempo global remove exatamente esse escopo.

Fontes