Resumo
- Na RFC 9856, Warm Standby suprime cópias nos PEs próximos às fontes; Hot Standby transporta as cópias e deixa cada PE de destino escolher uma.
- Single Flow Group é uma declaração configurada e anunciada, não um teste de payload, sequência, relógio, codificador ou disponibilidade da aplicação.
- Um recibo de redundância precisa registrar base de equivalência, autoridade de supressão, fonte aceita, BGP, observação do receptor, cronologia da troca e caminho de retorno.
Uma tela sem duplicação pode esconder duas perguntas diferentes. A rede escolheu apenas uma cópia? E a cópia escolhida entregou, sem interrupção, o mesmo serviço que a outra entregaria? A primeira pergunta está no escopo da RFC 9856. A segunda depende de evidência de aplicação e de recepção.
Publicada como Standards Track do IETF em setembro de 2025, a RFC amplia os procedimentos multicast de EVPN das RFCs 9251 e 9625. Ela cobre fontes redundantes que enviam fluxos IP multicast considerados idênticos ao mesmo domínio de tenant. O objetivo é evitar que os receptores recebam pacotes duplicados. A precisão dessa meta impede que se trate o protocolo como um certificado geral de continuidade.
O grupo não faz a comparação
O Single Flow Group, SFG, pode ser (*,G), reunindo qualquer origem que envie ao grupo G, ou (S,G), em que S pode ser um prefixo. O bit SFG na comunidade estendida Multicast Flags marca essa semântica em uma rota S-PMSI A-D.
O mecanismo comunica quais origens devem ser tratadas em conjunto. A RFC assume que elas enviam o mesmo fluxo e não são fontes em rajadas, mas não especifica comparação de sequência, timestamp, estado do codec, geração da aplicação ou versão de conteúdo. Uma origem atrasada ou incorreta pode pertencer legitimamente ao SFG e ganhar a seleção de acordo com todas as regras.
Por isso, a base de equivalência precisa existir antes da prova de rede: inventário, amostra, método de comparação, tolerâncias e proprietário do serviço que aceitou o resultado. O SFG transporta uma conclusão operacional; não a produz.
Warm Standby economiza rede e alonga a reação
No modo Warm, os PEs ligados às fontes elegem um Single Forwarder. Os demais descartam localmente os pacotes do SFG. O SF encaminha apenas uma interface de acesso; se o grupo chegar por mais de uma, a escolha é uma decisão local da implementação.
A eleição reutiliza a estrutura DF da RFC 8584. Uma preferência pode favorecer um PE e, numa incompatibilidade de algoritmo ou capacidade, vence o menor endereço IP de PE anunciado. Isso cria uma decisão determinística, mas não mede qualidade ou prontidão da fonte.
A primeira chegada de tráfego para um SFG configurado dispara o anúncio S-PMSI A-D. A interrupção do tráfego leva à retirada; recomenda-se um temporizador de inatividade, sem valor universal. Após a falha e a retirada do SF, outro PE pode assumir. A vantagem é impedir que cópias inúteis atravessem a rede. A desvantagem reconhecida é uma troca mais lenta que no modo Hot.
Não há limite universal de troca nem promessa de zero perda. Uma operação verificável precisa ligar o circuito de acesso escolhido ao temporizador, à detecção, à retirada, à nova eleição e ao primeiro pacote útil visto pelos receptores.
Hot Standby coloca a escolha perto do destino
No modo Hot, as cópias atravessam a rede do tenant. Cada fonte é associada a um Ethernet Segment, inclusive quando é single-homed, e os pacotes são marcados com um rótulo de S-ESI. O PE de destino aceita seu S-ESI primário e descarta os demais.
O arranjo consome mais banda e estado de controle. A rota S-PMSI A-D nasce da configuração do SFG, e não da recepção de tráfego; logo, a presença da rota não prova que a aplicação esteja enviando pacotes úteis. BFD multiponto pode observar os túneis P, mas não valida o codificador, o relógio ou a semântica do conteúdo.
Além disso, diferentes PEs de destino podem escolher S-ESIs primários diferentes por política local. Dois públicos podem receber uma cópia cada, um da fonte A e outro da B. Não existe necessariamente uma única origem física ativa para toda a rede.
A retirada das últimas rotas A-D relevantes muda o primário. Uma retirada em massa de um S-ES compartilhado pode alcançar vários tenants. O desaparecimento da última S-PMSI A-D de um SFG faz o PE remover a verificação RPF baseada no rótulo. Essas mudanças descrevem a autoridade do filtro; a experiência do receptor ainda precisa ser medida.
Um recibo de sete campos
O recibo proposto separa as evidências em sete partes:
- Base de equivalência: tenant, expressão SFG, fontes, método de comparação de payload/sequência/tempo, tolerâncias, amostra e proprietário da aplicação.
- Autoridade de supressão: modo, local da decisão, eleição ou política, versão da configuração e capacidades presentes.
- Estado ativo: PE SF e circuito no Warm, ou S-ESI primário de cada PE de destino no Hot.
- Sinalização BGP: S-PMSI A-D, A-D por ES/EVI, RT, bit SFG, preferência DF, rótulos ESI/DCB e geração das retiradas vistas por cada decisor.
- Observação do receptor: fonte aceita, contadores, lacunas, duplicações, reordenação, frescor da aplicação e amostra com mínima exposição de privacidade.
- Cronologia: falha, detecção, chegada da retirada, nova escolha, último pacote antigo, primeiro novo e intervalo medido de perda ou duplicação.
- Reversão: escolha anterior, configuração reversível, autoridade para restaurar, critério de abortar, validade e dívida ainda aberta.
Trata-se de uma proposta operacional de Daniel Kade, não de um campo da RFC nem de uma certificação do IETF. Cada parte mantém o alcance correto: BGP prova estado de controle; rótulo prova uma regra de filtro; amostragem prova uma experiência; comparação de aplicação prova equivalência.
Uma especificação mínima não elimina responsabilidade
A RFC 9856 não obriga um equipamento a implementar os dois modos. Ambientes heterogêneos precisam registrar a capacidade real de cada ponto. Os bits SFG e ESI-DCB alocados pela IANA oferecem vocabulário interoperável, mas não demonstram suporte, configuração, propagação ou programação corretos num dispositivo específico.
Expandir o protocolo até ele “provar” a aplicação destruiria a nitidez do contrato comum. Usar esse limite como desculpa para não provar nada seria igualmente ruim. A divisão saudável é simples: o padrão define classificação, sinalização, eleição e filtragem; a operação local define equivalência, observação, risco e retorno.
Assim, uma cópia limpa passa a ser o último elo, não a evidência inteira. As fontes foram comparadas; a autoridade foi identificada; BGP e filtros foram observados; receptores foram amostrados; a troca foi cronometrada; a reversão ficou possível. Só então supressão se torna redundância demonstrável.
Fontes
- RFC 9856 — Multicast Source Redundancy in EVPNs
- RFC 9625 — Optimized Inter-Subnet Multicast in EVPN
- RFC 9251 — EVPN Optimized Ingress Replication
- RFC 8584 — Extensibilidade da eleição DF em EVPN
- RFC 9572 — Atualizações de procedimentos BUM em EVPN
- RFC 9573 — Extensões de multihoming EVPN
- RFC 9746 — Filtragem split-horizon EVPN
- RFC 9780 — Procedimentos BFD para redundância de fonte multicast
- RFC 7432 — BGP MPLS-Based Ethernet VPN
- Registro IANA de comunidades estendidas BGP
- Status da RFC 9856
- Pesquisa de erratas da RFC 9856
- RFC 3935 — Missão do IETF
- Minimum Initial Specification — Lu Heng
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
