Resumo

  • A revisão 13 propõe consultar o forwarding database do plano de dados escolhido e permite que uma checagem OAM do mesmo plano influencie a candidatura ao best path.
  • Em uma malha de PEs, uma sessão por next hop pode representar muitas rotas; flapping ou sobrecarga de medição pode amplificar-se em retiradas e novos anúncios.
  • Escala precisa ser medida como raio de decisão: sessões, rotas dependentes, updates, tempo de reavaliação e impacto real no tráfego e no serviço.

A primeira sessão expirou por congestionamento no processo de controle. Duzentas mil rotas compartilhavam aquele next hop. Todas perderam elegibilidade, escolheram alternativas e geraram updates. A carga adicional atrasou outras sessões de liveness, que também expiraram. Em poucos segundos, o sistema criado para detectar falhas no plano de dados passou a produzir a evidência de falha que ele próprio consumia.

O encaminhamento original não tinha caído. A malha de medição entrou em colapso antes dele.

Esse é um cenário de controle derivado dos riscos levantados nas revisões, não o relato de uma implantação identificada. draft-ietf-idr-bgp-bestpath-selection-criteria-13, de 14 de setembro de 2026, é um Internet-Draft ativo do grupo IDR, destinado a Proposed Standard e proposto como atualização do RFC 4271. Ainda não é RFC. O Datatracker registra questões de revisão que exigem nova versão; as diretorias de Routing, Operations, Security e BGP consideram que o texto precisa de mais trabalho.

O ponto de partida é sólido. BGP qualifica uma rota antes da seleção de best path com a Route Resolvability Condition. Em redes que usam MPLS para alcançar o next hop, uma rota IP pode continuar presente enquanto a entrada MPLS, o label binding ou o LSP deixa de funcionar. O PE segue atraindo tráfego e o descarta no core.

A revisão 13 sugere resolver o next hop no forwarding database do plano escolhido por política. Também permite uma checagem de path availability por um mecanismo OAM associado ao mesmo plano. A intenção é fazer a candidatura refletir não só uma rota abstrata, mas a capacidade funcional do transporte.

O documento, porém, deixa mecanismo, política e detalhes operacionais fora do escopo. Diz que a checagem pode ocorrer sob demanda ou existir a priori. Não define custo, default, comportamento de startup, escala, histerese nem resultado quando o mecanismo está indisponível. A revisão de Operations chama a atenção para o custo de checagens por next hop em uma malha de PEs. A de Routing acrescenta churn, oscilação, route flap damping e reavaliação.

Uma sessão não tem raio unitário

Um painel costuma mostrar uma sessão como uma linha: next hop, estado, tempo. Para BGP, a mesma sessão pode sustentar centenas ou centenas de milhares de caminhos. Quando ela muda, o raio não é “uma sonda”; é o conjunto de candidatos que a política liga àquele resultado.

Esse raio depende de AFI/SAFI, vizinho, VRF, compartilhamento de túnel e política. A revisão 13 imagina políticas por neighbor, por SAFI ou por ambos. Uma única mudança pode excluir todos os caminhos daquele contexto, obrigar nova seleção, alterar o forwarding local e enviar withdraw ou replacement a muitos peers.

Por isso a capacidade não deve ser calculada apenas em probes por segundo. É preciso medir sessões ativas, rotas dependentes por sessão, fan-out de peers, número de best paths que mudariam, updates estimados, tempo da decision process, uso de CPU, filas de controle e consequência em CE. A unidade de escala é a decisão amplificada.

Também há uma correlação perigosa. Se OAM e BGP compartilham recursos de CPU, fila ou transporte, a carga causada pela primeira onda de updates pode prejudicar as sondas restantes. Novos timeouts geram novos updates. O observador e o objeto observado entram num loop. Mesmo sem recurso compartilhado, uma falha de control plane pode deixar data traffic saudável e produzir falso negativo.

Histerese não é um número universal

Uma resposta comum ao flapping é adicionar hold-down ou exigir múltiplas falhas. Isso reduz ruído, mas também retarda a reação ao blackhole real. Route flap damping pode interagir com a oscilação e prolongar consequências depois que o caminho volta. Um threshold bom para um next hop com dez rotas pode ser inadequado para outro que concentra serviços críticos.

A política precisa separar pelo menos quatro condições: falha confirmada do forwarding selecionado; falha apenas do mecanismo OAM; estado ainda não inicializado; e evidência contraditória. A terceira e a quarta são indeterminate, não down. Um sistema binário desloca o custo da incerteza para a rede inteira.

O tempo também deve estar ligado à geração do objeto. Uma checagem a priori pode envelhecer após recomputação do LSP ou troca de tabela. Uma checagem sob demanda pode atrasar a decisão e aumentar a carga exatamente durante convergência. É preciso registrar início, fim, validade, forwarding generation e instante em que BGP consumiu o resultado.

Os RFCs de mecanismos específicos ajudam a compreender limites, mas não os removem. RFC 5880 discute falso up e falso down em BFD. RFC 8029 trata riscos de spoofing, replay e tampering em LSP Ping. A revisão 13 não escolhe nenhum mecanismo. Mesmo uma checagem autenticada pode ser bloqueada por um atacante on-path ou passar enquanto production traffic sofre tratamento diferente.

Convergência não pode ser presumida

O texto diz que as mudanças não devem afetar negativamente a convergência, salvo particularidades de implementação. Os reviewers pedem justificativa ou remoção dessa afirmação. A ressalva contém justamente o problema: quantidade de sessões, fan-out de rotas, frequência de reavaliação e mecanismo OAM são particularidades que definem a convergência observada.

Um cálculo completo acompanha a cadeia: resultado de liveness muda; caminhos são reclassificados; decision process roda; FIB é atualizada; anúncios saem; vizinhos processam; tráfego muda; aplicação confirma ou rejeita o resultado. Medir apenas o tempo do primeiro evento ou do update BGP não prova recuperação de serviço.

Há ainda o caso de implantação parcial. Speakers com a checagem ligada podem retirar caminhos que outros mantêm. Eles passam a anunciar escolhas diferentes sem expor no update a origem dessa diferença. Uma oscilação local cria assimetria de candidato e pode deslocar tráfego repetidamente entre pontos da malha.

Um rollout começa sem poder de exclusão

O primeiro estágio deve ser shadow. O equipamento calcula qual caminho excluiria, mas não altera a lista de candidatos. A organização coleta, por sessão, a quantidade de rotas afetadas, divergência com tráfego real, idade, flaps e updates que teriam ocorrido. Compara também equipamentos equivalentes para descobrir diferenças de tabela e política.

O segundo estágio limita enforcement a um conjunto pequeno, com caminhos alternativos verificados e rollback testado. A equipe injeta falha real de MPLS mantendo IP reachability; depois quebra somente OAM; em seguida gera flapping controlado. Mede não apenas detecção, mas amplification factor: quantas rotas, updates e mudanças de serviço surgem de uma transição.

O terceiro estágio só avança quando os limites são explícitos. Uma sessão que sustenta rotas além do teto requer aprovação adicional ou arquitetura de isolamento. Uma discrepância entre probe e production traffic muda o estado para indeterminate. Uma taxa de transição acima do limite bloqueia novos withdraws automáticos até revisão.

Rollback restaura a versão de policy, limpa resultados derivados, reavalia rotas e confirma forwarding e serviço. Desligar OAM pode reduzir a carga, mas não garante que estados ineligible já armazenados desapareçam. A lista de caminhos excluídos e o reason code devem sobreviver à reversão.

A revisão 13 tenta impedir que reachability IP represente falsamente um transporte MPLS quebrado. Essa correção merece avançar com uma condição: a medição não pode ser tratada como fonte de custo zero e autoridade infinita. Quando uma sonda influencia muitas rotas, sua escala, falha e recuperação pertencem ao desenho de routing tanto quanto o algoritmo de best path.

Fontes