Resumo

  • RFC 9972 acrescenta Gauges BMP de 64 bits para o número corrente de rotas em pre-policy e post-policy Adj-RIB-In, em escopos específicos de Adj-RIB-Out e, em alguns tipos, em Loc-RIB.
  • O valor confirma somente uma contagem no escopo declarado. Não mostra qual rota foi afetada, por qual regra, se foi anunciada, instalada na FIB ou usada por pacotes.

Todo total tem uma posição no processo BGP

Dizer que um roteador tem determinado número de rotas oculta as decisões que antecedem o número. Adj-RIB-In guarda a informação recebida de pares; a visão pre-policy é anterior à política de entrada. A post-policy já passou por ela, mas ainda vem antes da seleção que forma a Loc-RIB. A Loc-RIB contém rotas escolhidas pelo processo local e pode receber também rotas de IGP ou estáticas. Adj-RIB-Out é a visão preparada para anunciar a um par específico.

RFC 9972, publicado no Standards Track da IETF, acrescenta estatísticas a BMP sem alterar o formato de Statistics Report de RFC 7854. Mukul Srivastava e Changwang Lin são seus editores, ao lado de Yisong Liu e Jinming Li. O objetivo é tornar manutenção e diagnóstico mais precisos, não declarar que uma métrica consegue observar toda a cadeia entre recebimento BGP e experiência do usuário.

Os tipos 18 e 19 contam o Adj-RIB-In pre-policy globalmente e por AFI/SAFI; 20 e 21 fazem a mesma distinção após a política. O tipo 22 conta rotas atualmente rejeitadas pela política de entrada durante mudanças de configuração, por AFI/SAFI. Ele é um Gauge corrente, diferente de um contador cumulativo de eventos. O tipo 23 conta as aceitas após a política. A pergunta permanece limitada: quantas existem agora nesta visão?

O total não substitui a evidência da rota

Uma subida no total post-policy não informa prefixo, next hop, AS_PATH, comunidades, par, versão de política nem regra que levou à aceitação. Não comprova que a rota venceu a seleção para a Loc-RIB, passou por uma política de saída, chegou ao par em um UPDATE, foi programada na FIB ou encaminhou tráfego.

Uma contagem de rejeições também não explica as rejeições individuais. Para isso, são necessários atributos, prefixo, par, regra, instante e resultado. Para afirmar seleção, anúncio, programação ou entrega, é necessário juntar o registro da camada que observou esse evento. O Gauge orienta a investigação; não preenche os campos ausentes por inferência.

Partições e séries têm condições próprias

RFC 9972 permite enviar uma estatística global e suas versões por AFI/SAFI, mas proíbe presumir dependência estrita entre elas. Corridas e falhas parciais podem fazer a soma das partições divergir do total. A divergência deve virar aviso, não interromper a operação. Ela pede verificação de horário, ordem de atualização e integridade do relatório; não prova, sozinha, ataque ou falha de roteamento.

Além disso, Gauges podem reiniciar por limpeza manual ou overflow. Produtores e coletores devem rastrear e registrar a descontinuidade. Sem esse marcador, uma linha que cai pode ser erroneamente descrita como retirada de rotas, quando o que terminou foi a série de medição.

A norma dá vocabulário; a operação conserva o contexto

O RFC padroniza um valor global de 64 bits ou uma estrutura AFI, SAFI e Gauge de 64 bits, e manda ignorar Types desconhecidos. Alguns Types só devem ser gerados se GR, LLGR, RPKI ou outra função correspondente estiver habilitada. A existência de um Type não demonstra que uma função está em execução em um roteador.

Frequência, limitação de relatórios, subconjuntos habilitados, limiares e reação permanecem locais. RFC 9972 recomenda limitar atualizações e habilitar só o necessário para proteger o plano de controle. Pela Running-Code Primacy de Heng Lu, o padrão torna a observação comparável; o sistema em execução deve mostrar fonte, hora, configuração, continuidade e demais provas para uma conclusão maior.

Sources