Resumo

  • A revisão 02 de draft-ietf-bfd-rfc5883-bis troca a proibição geral do BFD Echo em múltiplos saltos por uma regra condicional: o uso segue proibido se houver retorno intermediário e só é permitido quando o ambiente o evita.
  • O texto ainda é um Internet-Draft do grupo de trabalho, não um substituto aprovado do RFC 5883. A nova tabela de implementação da HPE reúne declarações de um colaborador que o IETF não verificou.

Um Echo que volta ao remetente pode confirmar apenas metade do caminho. Se um roteador intermediário devolver o pacote antes do destino, a sessão aparenta estar ativa mesmo que o trecho restante esteja indisponível.

Foi para eliminar essa ambiguidade que o RFC 5883, de 2010, proibiu a função Echo do Bidirectional Forwarding Detection em caminhos com vários saltos. A revisão 01 do possível sucessor manteve a regra sem exceção. A revisão 02, disponibilizada em 19 de agosto, passa a olhar para o comportamento do ambiente.

O novo parágrafo ainda determina que Echo não deve ser usado quando o encapsulamento ou o encaminhamento puder levar um nó intermediário a devolver o pacote. Mas acrescenta que ele pode ser usado quando o ambiente garante que isso não ocorrerá. Encapsular o pacote como uma rota de origem é apresentado como exemplo de como evitar a devolução antecipada, não como solução universal.

A mudança é mais estreita do que uma liberação geral. O número de saltos deixa de ser o único critério, mas a obrigação central permanece: uma resposta só vale como teste de conectividade se o pacote tiver atravessado todo o percurso pretendido.

Uma comparação estrutural dos XMLs oficiais mostra que esse parágrafo é a única alteração normativa no corpo entre as revisões 01 e 02. A versão nova também inclui uma declaração de implementação da HPE, ao lado de um registro anterior da ZTE. São elementos para revisão técnica, não medições independentes.

A HPE classifica uma implementação proprietária, Junos OS BFD Implementation, como Mature e declara suporte a caminhos arbitrários, encapsulamento e autenticação. A sinalização fora de banda do discriminador e os links unidirecionais aparecem como parciais, restritos a LSPs MPLS. Não é apresentada experiência de implementação.

O próprio rascunho limita o peso dessas afirmações. O IETF não verificou as informações fornecidas pelos colaboradores; a inclusão não representa endosso; a seção não é catálogo. Assim, o rótulo de maturidade não equivale a certificação, adoção de mercado ou interoperabilidade.

A revisão anterior já continha um relato da ZTE sobre Echo BFD não afiliado. Ele descrevia pacotes dentro de um Segment Routing Header e dizia que, dessa forma, Echo poderia operar em múltiplos saltos, embora a regra normativa ainda proibisse o uso sem ressalvas. A nova redação adota um teste dependente do ambiente, mas nenhuma fonte atribui a mudança diretamente à contribuição da ZTE.

O rascunho complementar sobre aplicações genéricas de BFD também avançou para a revisão 02 no mesmo dia. A única adição material é outra tabela HPE/Junos. Ela declara cobertura ampla, mas informa que OSPF Virtual Links não está implementado e não apresenta experiência operacional. O conjunto ajuda a comparar as alegações genéricas e multihop, sem mostrar comunicação entre produtos independentes.

As páginas do Datatracker para o documento multihop e o documento genérico mantêm ambos como Internet-Drafts ativos do grupo BFD, com estado IESG I-D Exists. Eles só substituirão o RFC 5883 e o RFC 5882 se forem aprovados.

Outras salvaguardas permanecem. BFD é uma ferramenta de operação, administração e manutenção de rede, não um teste geral entre aplicações na Internet. A taxa de pacotes precisa ser dimensionada para não criar congestionamento e falsos alarmes. Em multihop, o aumento da superfície para falsificação também reforça o uso de autenticação criptográfica forte.

As fontes oficiais desta revisão não demonstram que a condição nova foi habilitada em um produto, testada entre fornecedores ou medida em produção. Também não definem um encapsulamento seguro para todos os casos. A evidência necessária agora é uma captura que prove o percurso completo — inclusive depois de mudanças de rota, falhas e alterações de política — e não apenas a chegada de uma resposta.

Fontes