Resumo

  • O draft-ietf-bier-source-protection-11 mostra que o caminho entre o BFIR backup e o BFIR selecionado pode falhar enquanto os caminhos do selecionado até os BFER continuam funcionando. A promoção do backup nesse caso é desnecessária e pode duplicar pacotes.
  • Um Ping no sentido inverso também não representa automaticamente o multicast de ida. Sem coencaminhamento, pode falhar com o serviço saudável ou responder quando o caminho do serviço está quebrado.
  • Identidade da observação, resultado do detector, modo de standby, autoridade para trocar, duplicação ou perda, recepção e resultado da aplicação exigem recibos separados. A revisão 11 é um Internet-Draft Informational, não prova de operação.

O backup possuía um dado correto: a sessão usada para observar o primário havia parado de produzir os sinais esperados. O sistema transformou esse dado em uma narrativa maior: o nó primário morreu, todos os receptores perderam o fluxo e o backup devia assumir.

O nó continuava ativo. Seus caminhos para os receptores também. O defeito existia apenas entre os dois roteadores de entrada. Quando o backup começou a enviar, a disponibilidade deixou de ser defesa e passou a ser a origem de uma segunda cópia do mesmo fluxo.

Essa cena aparece de forma explícita na revisão 11 de BIER Redundant Ingress Router Failover. O documento oferece uma lição maior que sua lista de mecanismos: uma observação só pode governar a superfície que ela realmente mediu.

A palavra primário não define um único caminho

Na arquitetura de RFC 8279, o BFIR coloca o pacote no domínio BIER e os BFER o recebem. O núcleo encaminha segundo o BitString sem estado multicast por fluxo. Ainda existe, porém, uma escolha de upstream multicast hop para cada fluxo. Protocolos de overlay distribuem a informação; o transporte BIER carrega os pacotes.

O rascunho chama a entrada escolhida de S-BFIR e a alternativa de B-BFIR. BFER diferentes podem escolher entradas diferentes, e duas entradas podem responder por subconjuntos distintos. “O primário caiu” não é um evento global sem o nome do fluxo e dos receptores.

Há pelo menos três superfícies direcionais:

  1. B-BFIR para S-BFIR, usada pelo backup para observar o selecionado;
  2. S-BFIR para cada BFER, usada pelo tráfego protegido;
  3. BFER para S-BFIR, usada por uma solicitação Ping de retorno.

Elas podem compartilhar enlaces, mas não existe autorização para presumir isso. A primeira superfície pode falhar enquanto a segunda permanece saudável. Ela também pode permanecer saudável enquanto um caminho para um BFER falha.

No exemplo de warm standby, BFIR2 perde BFIR1, interpreta a ausência como falha do nó e assume o papel selecionado. O caminho de BFIR1 para todos ou alguns BFER segue funcional. O texto chama a troca de desnecessária e registra sua consequência: pacotes duplicados dentro da rede e nos receptores.

Um evento Down precisa conservar sua direção

RFC 5880 define BFD para um caminho de encaminhamento específico. RFC 8562 estende BFD a multiponto. O BIER BFD revision 12 trata de bootstrap e notificações active-tail. Velocidade de detecção não transforma uma sessão em conhecimento universal.

Sinal registrado Afirmação sustentável Expansão indevida
BFD Down entre backup e selecionado A sessão atingiu seu limiar Todos os caminhos até os BFER falharam
Ping inverso sem resposta A sonda inversa não completou O fluxo de ida parou
Tail excedeu Detection Time Esse tail perdeu o controle esperado Todo receptor perdeu o fluxo
BFER escolheu novo UMH Sua seleção mudou para o fluxo A aplicação se recuperou
Backup começou a transmitir Uma segunda fonte apareceu Duplicatas foram removidas em todo lugar

O recibo deve manter endpoints, direção, subdomínio, tratamento do pacote, entropia ou seleção de caminho, discriminator, intervalo, limiar e classe de tráfego. Down sozinho elimina o sujeito da frase.

O Ping pode errar ao falhar e ao funcionar

Um BFER pode enviar Ping para BFIR1 e considerá-lo UMH falho depois de respostas ausentes. O multicast protegido vai de BFIR1 ao BFER; a solicitação de teste viaja ao contrário.

Em topologias assimétricas, as rotas divergem. O rascunho reconhece os dois resultados falsos: o Ping falha enquanto caminho e fluxo estão bons; o Ping funciona enquanto o caminho multicast está defeituoso. A solicitação precisa ser coencaminhada com o caminho de ida monitorado para aumentar a consistência.

Esse alinhamento não prova entrega de aplicação. Ele só torna a observação de rede mais representativa. Continuidade, ordem e ausência de duplicatas ainda pertencem aos contadores do BFER e à evidência da aplicação.

Cold, warm e hot movem a autoridade

O rascunho geral de ingresso multicast redundante define três modos, mas a diferença não é apenas latência.

No cold standby, o receptor sinaliza a alternativa depois de decidir que o selecionado falhou. Não há duplicação rotineira, mas sinalização e convergência podem perder pacotes.

No warm standby, selecionado e backup conhecem a demanda, porém só o selecionado envia normalmente. O backup pode iniciar rápido e também pode tomar uma decisão errada sobre um caminho de receptor que não observa.

No hot standby, ambos enviam e o BFER descarta a cópia não escolhida. A perda da troca pode cair, enquanto banda duplicada e filtragem no receptor viram custo permanente.

Uma compra que pede somente “failover rápido” deixa sem resposta quem mantém estado, quem consome banda, quem suporta perda e quem possui a autoridade de declarar falha.

A seleção pode divergir entre receptores

BFER diferentes podem escolher S-BFIR distintos e usar timeouts diferentes. Um pode trocar para BFIR2, outro continuar em BFIR1 e um terceiro ainda esperar seu Detection Time. Um único estado primary_failed apaga essa pluralidade.

A chave mínima da decisão inclui fluxo, BFER ou conjunto, S-BFIR, caminho observado, detector, limiar e versão anterior. Depois, um recibo de controle registra quem alterou o UMH; um recibo de efeito registra início e fim reais de cada fonte, perdas, duplicatas, reordenação, origem aceita por cada BFER e continuidade da aplicação.

Receber um pacote de BFIR2 prova apenas que BFIR2 enviou algo que chegou. Não prova que BFIR1 parou nem que todos os receptores convergiram.

O documento não é um relatório de implantação

A revisão 11 é um Internet-Draft do grupo BIER, de 1 de outubro de 2026, com intenção Informational. Não é RFC. Não pede alocação IANA. As considerações de segurança remetem à arquitetura BIER, BFD multiponto, failover MVPN, BIER Ping e BIER BFD.

Ela prova que o problema de mismatch, falso resultado e promoção desnecessária faz parte da análise. Não prova implementação de fabricante, interoperabilidade, adoção ou recuperação de um serviço real.

As camadas de realidade de Lu Heng impedem que o estado simbólico do detector se aproprie do estado físico de outro caminho. O espelho da política exige nomear ator, regra, escopo e consequência onde o sinal vira mudança de topologia.

Recibo de failover

Registre identidade do fluxo; S-BFIR e B-BFIR; BFER envolvidos; modo de standby; overlay e seleção anterior; detector e sessão; caminho observado direcionado; prova de equivalência de tratamento com o fluxo; timers, limiar e pacotes ausentes; ator autorizador; UMH antigo e novo; início e parada efetivos das duas fontes; contadores de perda, duplicata e reordenação; aceitação no receptor; e resultado da aplicação.

Sem prova de coencaminhamento, escreva equivalencia_de_caminho_nao_verificada. Sem visibilidade do caminho de receptor, escreva caminho_do_receptor_desconhecido. Uma lacuna nomeada limita a automação; uma lacuna escondida recebe autoridade indevida.

Fontes