Resumo

  • A RFC 8966, de Juliusz Chroboczek e David Schinazi, trata a forma de combinar custo local e métrica anunciada por um vizinho como política local. Ela exige que custo infinito produza resultado infinito e que a métrica resultante seja estritamente maior que a recebida.
  • Essa condição preserva o argumento de não formar laços. Ela não transforma uma métrica em evidência de banda, custo financeiro, atraso percebido, rota viva ou resultado para o cliente. A RFC 9616 diz que amostras RTT podem ser corretas e ainda assim barulhentas demais para decidir uma rota diretamente.

A regra comum é menor que a interpretação comum

Uma tabela de rotas convida a uma leitura exagerada: o menor valor parece ser a melhor estrada para qualquer finalidade. Mas Babel não exige que todos os nós usem a mesma fórmula, nem que todas as interfaces valorizem perda, saltos, atraso ou custo da mesma forma. A RFC 8966 permite estratégias diferentes dentro de um mesmo domínio.

O que precisa ser comum é uma propriedade verificável pelo nó. Ao agregar o custo local à métrica anunciada, a nova métrica deve aumentar; se o custo local for infinito, o resultado deve ser infinito. Sem essa disciplina, uma escolha poderia atravessar um ciclo e apresentar-se como se não tivesse piorado. A regra protege a estrutura da decisão, não dá ao resultado uma autoridade geral sobre a rede.

Por isso uma métrica baixa só explica uma preferência local sob entradas declaradas. Não demonstra que há tráfego naquele momento, que o destino responde, que o enlace é barato ou que o serviço entregue ao usuário é melhor.

Convergir sem receber um selo de ótimo

A RFC separa monotonicidade estrita de distributividade à esquerda. A primeira é essencial para impedir laços persistentes. A segunda é recomendada, mas não é indispensável para convergir sem laços. Sem ela, Babel pode convergir e não alcançar um ótimo global; esse ótimo pode nem existir.

Essa distinção impede que a métrica seja tratada como árbitro central. Rotas infinitas ou inviáveis não podem ser selecionadas, e um número de sequência maior não deve vencer apenas por ser mais recente: a RFC alerta para oscilações e, em certas métricas, buracos negros persistentes. Para valores que variam continuamente, a histérese recomendada exige evidência sustentada antes da troca. Ela estabiliza o algoritmo; não promete desempenho.

RTT é observação antes de ser política

A RFC 9616, de Baptiste Jonglez e Chroboczek, parte do fato de que Babel não determina um algoritmo único de métrica. Ela especifica uma extensão RTT para situações em que perda ou contagem de saltos podem escolher mal em túneis ou VPNs. Contudo, não chama RTT de verdade universal: amostras precisas podem causar feedback e oscilações se usadas diretamente. Por isso define uma transformação para custo e uma histérese, e limita o método aos ambientes em que atraso simétrico prediz bem a escolha relevante.

A RFC 8965, escrita por Chroboczek, associa hipóteses fracas a robustez diante de métricas novas ou flutuantes, mas registra limites de atualizações periódicas e da necessidade de tabela completa. Seu perfil IETF liga publicamente as RFCs 8965, 8966 e 9616 a sua autoria; não prova controle sobre redes, implementações ou políticas de operadores.

Limites de evidência

As fontes não identificam um domínio Babel ativo, túnel em operação, valor RTT atual, capacidade, preço, postura de segurança ou entrega de serviço. Um recibo útil preserva versão da métrica, escopo local, janela de observação, transformação, viabilidade, histérese e condição de seleção — não uma etiqueta de “melhor rota”.

Fontes