Resumo

  • draft-ietf-idr-bgp-rpki-yang-02 distribui medidores de validação de origem por cinco superfícies BGP. O caminho YANG, o vizinho e a família de endereços fazem parte da medição.
  • O mesmo total pode representar conjuntos diferentes. Validação também não comprova seleção, exportação, aceitação pelo par nem o caminho efetivo dos pacotes.

Às 2h, havia 10 mil rotas com origem válida. Depois da mudança, continuavam sendo 10 mil. A linha ficou reta; o conjunto por trás dela pôde mudar por completo.

Se um prefixo crítico saiu e outro entrou, a contagem está correta e a conclusão “nada mudou” está errada. Essa diferença entre cardinalidade e identidade é o ponto de gestão mais importante de draft-ietf-idr-bgp-rpki-yang-02, publicado em 30 de setembro de 2026.

O documento do grupo IDR define modelos separados para validação do AS de origem, BGPsec e ASPA. No primeiro, estados não verificado, desconhecido, inválido e válido aparecem como gauge32 em cinco superfícies.

Cinco lugares, cinco limites de afirmação

Os caminhos são adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre e adj-rib-out-post, para IPv4 e IPv6.

O primeiro registra o que o vizinho ofereceu antes da política de entrada; o segundo, o que restou. O RIB local contém a visão selecionada no equipamento. As duas superfícies de saída delimitam a política aplicada para um vizinho.

Uma contagem recebida não prova o RIB local. O RIB local não prova o anúncio a um par. O pós-política de saída não prova que o par aceitou. Nenhum deles, isoladamente, prova encaminhamento.

Por isso, remover caminho, AFI/SAFI ou vizinho para simplificar um painel remove a fronteira da evidência. Um agregado pode esconder a troca de dependência entre provedores, regiões ou domínios de falha.

Cardinalidade não é continuidade

gauge32 informa quantos elementos estão em um estado. Não informa quais são. Dois conjuntos de mesmo tamanho podem ter membros distintos; uma saída e uma entrada se anulam na curva.

Se a organização precisa provar continuidade, deve preservar uma identidade de conjunto: uma impressão digital canônica de prefixo, origem, AS_PATH e próximo salto; uma lista limitada; ou testes de presença para rotas protegidas. O formato depende do risco. A obrigação é saber o que foi contado.

O instante da coleta também pertence ao recibo. O rascunho não promete que leituras de cinco caminhos formem um snapshot transacional. Durante convergência, segundos de diferença podem produzir uma comparação enganosa.

Válido é uma resposta estreita

A validação RPKI de origem compara prefixo e AS de origem com dados ROA validados. RFC 6811 estabelece o mecanismo; RFC 8481 esclarece o escopo e evita tratar validação como política automática.

Uma rota válida não é necessariamente a melhor, a mais barata, a mais rápida ou livre de vazamento. Não é automaticamente válida em BGPsec ou ASPA. Não prova cache recente, vitória no best path, exportação, aceitação remota ou entrega de pacotes.

Os três modelos existem porque as perguntas são diferentes. Um único selo verde destruiria essa informação.

A política pode mudar sem mover o total

A validação pode ser habilitada por família e limitada por eligible-prefix-policy. Outro contêiner decide se o estado participa do best path. allow-invalid e allow-not-found controlam elegibilidade, com padrões diferentes e possível política adicional.

Anunciar a comunidade estendida da RFC 8097 é uma decisão própria. Considerar validação na exportação é outra, com tratamento específico para not-found e política de prefixos, conforme a referência à RFC 8893.

Logo, a mesma distribuição de estados pode produzir decisões diferentes. Uma alteração em allow-invalid, allow-not-found ou na política de exportação pode trocar rotas selecionadas e anunciadas enquanto a contagem válida continua igual.

O recibo precisa guardar a configuração efetivamente aplicada, não só a intenção no controlador. A arquitetura NMDA da RFC 8342 distingue esses mundos porque processamento, hardware e protocolos podem fazê-los divergir.

O encadeamento que falta no painel

Uma trilha defensável separa: entrada e atualidade da validação; configuração aplicada; caminho e horário do medidor; identidade do conjunto; decisão de seleção; conjunto e UPDATE exportados; aceitação pelo vizinho; e alcance observado.

Nenhum passo prova o seguinte. Dados frescos não provam política aplicada. Contagem não prova membros. Membros não provam seleção. Seleção não prova exportação. Exportação não prova aceitação. Aceitação não prova serviço.

Essa separação melhora a investigação. Quando o serviço falha com uma linha plana, a equipe procura a primeira fronteira divergente. O painel talvez esteja certo sobre uma pergunta pequena e mudo sobre a promessa maior.

Estado do documento

O Datatracker registra a revisão 02 como Internet-Draft ativo, destinado ao Standards Track, em I-D Exists. Não é RFC. As fontes congeladas não demonstram implementação por fornecedor ou rede em produção.

Isso limita alegações de compra e conformidade, mas não impede melhoria imediata. Telemetria existente já pode guardar estágio, par, família, época de política e identidade do conjunto.

A Minimum Initial Specification e a Running-Code Primacy de Heng Lu oferecem o enquadramento: regras determinísticas podem ser comuns, enquanto seleção e exportação continuam decisões locais verificáveis. Publicação não cria operação. Código, configuração e uso criam.

A pergunta de encerramento não deve ser “o total ficou verde?”. Deve ser: quais rotas, em qual estágio e política, foram escolhidas e anunciadas—e o que os pacotes fizeram?

Fontes