Resumo

  • Em 31 de agosto de 2026, o IESG aprovou a revisão 05 de Dynamic Flooding on Dense Graphs para publicação como RFC Experimental. O registro examinado ainda não atribuía um número RFC final.
  • Um Area Leader calcula uma topologia esparsa para distribuir estado de enlace, sem substituir a topologia de base usada no encaminhamento de dados.
  • O texto lista sete critérios antes de uma possível evolução, inclusive três implementações independentes interoperáveis e experiência operacional documentada. O processo de aprovação registra somente uma implementação IS-IS.
  • Convergência, redução, qualidade operacional e robustez precisam ser “aceitáveis”, mas não há um valor universal. O espaço local é legítimo desde que o limiar seja declarado antes do teste.
  • Um registro versionado deve ligar versão, código, grafos, escolhas do algoritmo, denominador, falhas injetadas, flooding temporário, retorno e responsável pela decisão.

O IESG abriu uma experiência

O status escolhido descreve o alcance da notícia. Houve consenso forte no grupo Link State Routing, e o problema é real: em um grafo denso, o flooding convencional pode fazer o mesmo anúncio de estado percorrer enlaces demais. Ainda assim, a solução foi aprovada como Experimental, não como padrão de produção.

A proposta separa a topologia que encaminha dados daquela que distribui atualizações. O grafo de base continua contendo os enlaces disponíveis para o tráfego. O Area Leader calcula um subgrafo para o plano de controle e o anuncia por meio do arcabouço da RFC 9667. Esse subgrafo precisa alcançar todos os nós alcançáveis, deve ser biconexo quando possível, não pode criar diâmetro excessivo e deve evitar concentrar o grau em poucos equipamentos.

O exemplo didático parte de dez nós plenamente conectados, com 45 arestas, e chega a 12 arestas no grafo de flooding. O diâmetro passa de um para quatro. O desenho torna o compromisso visível, mas não é um benchmark. Não informa a convergência de uma rede real nem o comportamento durante uma sequência de falhas.

O ponto de partida do software recomenda cautela. O shepherd identificou uma única implementação IS-IS. Trata-se de uma mudança operacional relevante baseada no arcabouço ainda experimental da RFC 9667. Os autores não afirmam que o algoritmo seja ótimo nem o propõem como a resposta normalizada. A aprovação cria um objeto comum para acumular evidência.

Sete critérios, sem régua universal

A revisão 05 diz o que precisaria existir antes de avançar: pelo menos três implementações independentes interoperáveis; experiência de implantação e operação documentada; ausência de objeções fundamentais; considerações de segurança validadas ou atualizadas; qualidade operacional aceitável; convergência e redução de flooding aceitáveis; e robustez durante mudanças de topologia.

É uma barreira substantiva. Uma demonstração do único código conhecido não comprova independência. Três produtos derivados do mesmo repositório não se tornam três implementações apenas pela embalagem. A interoperabilidade inclui a codificação correta da topologia pelo Area Leader e a interpretação coerente do próprio papel por cada nó participante.

O adjetivo “aceitável” não vem com segundos, percentuais ou percentis. Isso pode ser adequado: uma rede de operadora, uma malha de data center e um laboratório têm orçamentos de convergência distintos. Uma cifra obrigatória poderia fingir comparabilidade onde ela não existe.

Mas a ausência de cifra comum não autoriza uma cifra retrospectiva. Se o critério aparece depois do resultado, muda-se a janela de observação, exclui-se a pior cauda, ignora-se a população legada ou chama-se de ganho uma redução menor que a meta original. A autonomia do operador só é auditável quando definição, denominador, limiar e autoridade antecedem a medição.

A implementação faz escolhas que mudam o resultado

O algoritmo central deixa detalhes em aberto: profundidade da busca, ordem dos vizinhos, desempate e seleção de endpoints extras. Duas implementações podem receber o mesmo grafo e produzir subgrafos diferentes. Um relatório que diz apenas “dynamic flooding habilitado” não permite comparação.

O papel do Area Leader também precisa ser observado. Somente ele calcula e anuncia a topologia. Qual roteador ocupava a função? Em que estado estava a eleição? Qual visão da base de estado alimentou o cálculo? Em que momento o novo grafo passou a valer? O documento recomenda uma forma de gestão que mostre líder e adjacências ativas, mas deixa a interface a cargo do implementador.

Implantação parcial altera o denominador. Nós legados continuam inundando todas as interfaces. Isso preserva compatibilidade, porém limita a economia. Medir somente o conjunto atualizado produz uma área estatística que não corresponde à área operacional.

A topologia estável é o teste mais fácil. Queda de enlace, falha de nó, perda do líder, partição e recomposição exigem recálculo e flooding temporário. Se a transição falhar, alguns roteadores podem não receber estado recente e calcular rotas inconsistentes. A média de mensagens em período calmo não mede esse risco.

Registre a experiência antes de conhecer o vencedor

O primeiro bloco identifica o objeto: revisão do draft, cobertura da RFC 9667, implementação e build, maturidade, modelo de licença, responsável e período. Há uma divulgação de IPR associada ao trabalho; registrar sua revisão é uma dependência de decisão, sem que esta matéria ofereça conclusão jurídica.

O bloco topológico fixa a impressão do grafo de base, números de nós e arestas, participantes e legados, líder e eleição, impressão do grafo calculado e parâmetros de ordenação, desempate e endpoints. Identificadores estáveis e pseudônimos preservam a capacidade de reproduzir sem expor endereços sensíveis.

O bloco de medida declara quando começa e termina a convergência, em quais interfaces se contam mensagens, durante qual intervalo, qual carga por nó, diâmetro, distribuição de grau e perda são tolerados. Média, distribuição, cauda adversa e tentativas descartadas pertencem ao mesmo relatório.

O bloco de resiliência enumera previamente perda de enlace, nó e líder; partição e retorno; mudanças rápidas; convivência com nós antigos; e retorno ao flooding clássico. Para cada evento, liga detecção, acionamento temporário, substituição do grafo, consistência, tempo de recuperação e intervenção manual.

O bloco decisório guarda avançar, limitar, pausar ou reverter; nomeia quem podia decidir; aponta o limiar acionado e agenda a revisão. Corrigir significa acrescentar uma nova linha, não apagar o primeiro grafo que falhou.

A RFC 7942 oferece um precedente: identidade da implementação, maturidade, cobertura, compatibilidade, licença, experiência e relatórios de interoperabilidade são fatos úteis, porém temporais. Por isso o experimento precisa de um registro vivo fora do RFC imutável, capaz de sustentar o futuro relatório de resultados.

Os limites do que foi aprovado

As fontes não demonstram três implementações independentes, implantação de produção identificada, ganho de campo ou incidente. O exemplo dos dez nós não pode virar promessa de desempenho. A divulgação de IPR tampouco recebe interpretação legal neste texto.

O histórico da revisão operacional merece precisão. A análise OPSDIR da revisão 04 apontou problemas importantes na discussão de implantação incremental, múltiplos algoritmos, práticas de operação e falhas de nós. A revisão 05 acrescentou Operational Considerations. Isso mostra que a revisão afetou o documento; não certifica toda implementação futura.

A disciplina de especificação mínima de Heng Lu entra aqui apenas como teste editorial: regras comuns devem ser pequenas, determinísticas e verificáveis localmente, enquanto escolhas futuras preservam dono e prova. Ela não acrescenta fatos à decisão do IETF nem descreve uma rede específica.

Assim, a força da aprovação está em manter a pergunta aberta de forma comum. O experimento só poderá fechar essa pergunta quando implementações independentes, medidas prévias e falhas preservadas permitirem uma comparação honesta.

Fontes

  1. IESG — anúncio da aprovação
  2. IETF Datatracker — Dynamic Flooding on Dense Graphs, revisão 05
  3. IETF — parecer do shepherd
  4. OPS Directorate — revisão de Last Call
  5. RFC 9667 — arcabouço de flooding dinâmico
  6. RFC 7942 — estado de implementações
  7. IETF — divulgação IPR 4044
  8. Heng Lu — Minimum Initial Specification