Resumo

  • Um mecanismo de sinalização de falhas pode estar especificado sem estar implementado, e implementado sem ser verificado de forma independente.
  • Erratas documentadas — inclusive uma reportada pelo próprio Jeffrey Haas — mostram que o texto normativo em si carrega defeitos.
  • Os relatórios de conformidade existentes são autorreportados por dois fornecedores; nenhum teste independente foi localizado.

Em redes IP, o Bidirectional Forwarding Detection (BFD) é o mecanismo que avisa o BGP quando um caminho morre. RFC 9384, de autoria de J. Haas (Juniper Networks), define o subcódigo 10 "BFD Down" para o NOTIFICATION Cease do BGP, tornando observável a causa de um encerramento disparado pelo BFD. Quando um alto-falante BGP encerra uma conexão porque uma sessão BFD caiu, ele DEVE enviar um NOTIFICATION com o erro "Cease" e o subcódigo "BFD Down"; quando a perda total de conectividade impede o envio, o motivo deve ser registrado no estado operacional.

A pergunta desta reportagem não é se o mecanismo existe, mas qual evidência prova que seu conserto é durável. A hierarquia encontrada tem cinco degraus, cada um provando algo diferente:

  1. Texto normativo. RFC 5882 (2010) define a interação BFD/BGP e adverte que executar BFD para IBGP quando o IGP subjacente já interage com BFD é geralmente inapropriado. Mas o próprio texto contém defeitos documentados: as erratas 8921 e 8922 corrigem referências cruzadas de seção, e a errata 8921 foi verificada pelo IESG (Ketan Talaulikar) — a verificação cobre a citação, não o comportamento em execução.
  2. Erratas 'held for document update'. A errata 5205, técnica, descreve um defeito real de sinalização: quando um sistema sinaliza AdminDown e o enlace falha unidirecionalmente em seguida, o par não apresenta indicação de timeout. A errata 7240, reportada por Haas, documenta que várias implementações redefinem bfd.LocalDiag a zero quando a sessão volta a Up — um desvio de implementação em que o texto normativo foi considerado correto.
  3. Relatórios de implementação autorreportados. O relatório do rascunho do subcódigo BFD lista duas implementações conformantes: Juniper 22.3R1 (contato Jeffrey Haas) e Arista 4.29.0 (contato Bill Fenner). São autorrelatos, sem metodologia de teste independente.
  4. Slides de interop. Os materiais da sessão IDR no IETF 118 reportam interop bem-sucedida entre Junos e SRoS para o modo estrito BFD (capability opção 74), ao lado de uma implementação proprietária que não suporta sinalização dinâmica e exige configuração estática em ambos os lados — um defeito residual de implantação documentado pelos próprios slides.
  5. Documentação de produção. A documentação do Junos descreve o comportamento completo: o BGP aguarda a sessão BFD reportar Up dentro do intervalo de espera (padrão 30 segundos, faixa de 10 a 255 s); no vencimento, a sessão é reiniciada e o roteador envia um NOTIFICATION com o subcódigo BFD Down. A documentação do FRR descreve o comando neighbor <peer> bfd strict [hold-time] com comportamento equivalente.

O que falta no topo da hierarquia é um teste independente. O RFC 9978 (BFD Stability), que mediria a estabilidade das sessões, é explicitamente Experimental: "não há implementações conhecidas ou prova de conceito", segundo o próprio RFC. O grupo de trabalho BFD está revisando as RFCs 5880–5883 (rfc5880bis, rfc5881bis, rfc5882-bis, rfc5883-bis) com um marco de Dez 2026 para avançar a RFC 5880/5882 ao Internet Standard — o veículo natural para incorporar as correções documentadas nas erratas.

A conclusão intermediária: a sinalização de falha BFD/BGP está especificada e parcialmente implementada, mas não verificada de forma durável por evidência independente. A cadeia de custódia do conserto termina em autorrelatos de fornecedores.

Fontes