Resumo

  • draft-ietf-bier-ping foi aprovado pela IESG como Proposed Standard em 21 de setembro de 2026. A revisão 29 está na fila do RFC Editor; número RFC e porta finais não são presumidos.
  • Packet-Forward-Success confirma o processamento do BFER que respondeu. Em uma consulta com vários BFR-ID, não comprova que o conjunto inteiro respondeu.
  • A execução auditável liga o BitString original a cada alvo, resposta ou timeout, código, DDMAP, classe de entropia e modo de retorno; a entrega do tráfego real permanece uma medição separada.

O recibo tem um emissor

BIER associa cada BFER a uma posição de bit. Assim, um BitString carrega uma lista de destinatários sem exigir que o núcleo mantenha uma árvore multicast por fluxo. BIER Ping aproveita essa representação para obter evidência ativa do plano de encaminhamento.

O registro da IESG confirma a aprovação em 21 de setembro. O Datatracker mostra a revisão 29, de 19 de setembro, no RFC Editor. É avanço normativo, não comprovação de implementação. Enquanto edição e registros não terminarem, não há base para inventar número RFC ou porta definitiva.

O erro começa quando uma interface resume uma consulta múltipla em um único indicador verde. O BFER pode retornar Packet-Forward-Success depois de processar corretamente sua busca local. Esse recibo não é emitido pelos outros BFR-ID presentes no pedido.

O próprio draft explica que, com mais de um BFR-ID, é difícil perceber a ausência de um deles. Talvez seja necessário repetir a consulta isolando o BFER que não respondeu. O protocolo permite construir uma verificação de completude; não permite deduzi-la da primeira resposta.

A lista original precisa sobreviver às consultas

Original SI-BitString registra o conjunto inicial. Target SI-BitString seleciona os respondedores de uma etapa. Conforme chegam respostas, o iniciador pode limpar os bits correspondentes nos pedidos seguintes. Sem guardar original e sequência, a última consulta já não mostra o objetivo completo.

Cada bit requerido precisa terminar associado a uma resposta ou timeout explícito. Mesmo um timeout de alvo isolado ainda não atribui causa. Caminho de ida, seleção, parser, punt ao controle, policer, construção da resposta e retorno continuam em aberto.

Reply mode também delimita a evidência. IP/UDP demonstra uma resposta que voltou por IP, não um caminho BIER reverso. Uma resposta BIER pode exercitar a direção inversa. Nenhuma delas, sozinha, demonstra que a aplicação consumiu o multicast de produção.

Códigos diferentes preservam diagnósticos diferentes

No matching entry in the forwarding table indica falha na busca local. Set-Identifier Mismatch revela desacordo de SI que pode atravessar uma fronteira errada de subdomínio. DDMAP Mismatch mostra desvio entre o mapa esperado e o observado, tornando loop ou duplicação riscos concretos. Packet-Forward-Success continua sendo uma afirmação positiva local.

Reduzir tudo a sucesso ou falha elimina o valor operacional. Código, BFR-ID, BitStrings de entrada e saída, interface, DDMAP, label e SI devem ficar unidos. Só assim estado do controle e comportamento do encaminhamento podem ser comparados sem serem confundidos.

Cada BFER abre uma grade de ECMP

Para BIER sobre MPLS, a consulta de multipath entropy identifica um BFER específico e retorna uma máscara dos valores de entropia associados aos caminhos downstream. Uma consulta multipath com mais de um BFER é inválida.

Logo, obter uma resposta e cobrir os caminhos relevantes são afirmações distintas. Cada saída crítica precisa de sua grade de classes de entropia, execuções e caminhos. BFIR-id, BitString, BIFT-id, BSL, SI, Entropy e DSCP também devem espelhar o fluxo observado; qualquer diferença pode mudar o tratamento.

RFC 10014 organiza a metodologia de OAM ativo e RFC 9974 os requisitos de OAM para BIER. Ambos exigem rigor, mas não transformam um pacote de teste em prova de resultado para o cliente.

Proteção do controle pode silenciar a medição

Como o BIER Ping chega ao plano de controle, o draft recomenda limitar a taxa destinada ao controle e à porta do protocolo. A defesa evita exaustão, porém cria uma causa adicional de silêncio.

Taxa oferecida, contadores de punt e policer, erros do parser e carga do respondedor precisam acompanhar a execução. Sem isso, uma equipe pode alterar encaminhamento saudável ou elevar limites perigosamente para fazer o teste “passar”.

Nas camadas de realidade de Heng Lu, aprovação é processo, o draft é descrição simbólica, configuração é capacidade e a execução é observação. Tráfego de produção e recebimento pela aplicação vêm depois. A força do BIER Ping está em não permitir que uma camada finja ser todas as outras.

Fontes