Resumo

  • O RFC 9917 é um IETF Proposed Standard publicado em janeiro de 2026 e atualiza os RFCs 9350 e 9843. Ele permite que a computação do caminho do Flex-Algorithm considere Administrative Groups no sentido reverso do enlace.
  • O caso de uso é o receptor remoto detectar erros de entrada, como CRC errors, e, a partir de um limiar definido pelo operador, configurar um Extended Administrative Group na aresta reversa. Uma restrição correspondente pode então excluir a aresta de ida.
  • O mecanismo não detecta falhas automaticamente, não torna o enlace físico simétrico e não prova suporte universal. A decisão exige evidência sobre telemetria, limiares de set/clear, codificação, winning FAD, suporte, convergência, observabilidade e rollback.

O mecanismo: a recepção remota entra na decisão de ida

A proposta trabalha com arestas direcionadas. O lado que envia pode continuar reportando um enlace aparentemente saudável, enquanto o lado que recebe observa degradação. No exemplo do RFC 9917, o receptor identifica erros de entrada — CRC errors são apenas o exemplo citado pelo RFC — e uma política operacional associa essa condição a um Extended Administrative Group na aresta reversa. O valor do limiar é uma decisão do operador; o RFC não fornece um número universal.

Também não se deve presumir que uma implementação fará automaticamente a ponte entre telemetria de interface e afinidade reversa. Essa cadeia precisa ter dono, registro e validação. Quando o winning FAD aplica a restrição relevante, o atributo da aresta reversa pode fazer a aresta de ida deixar de ser elegível no cálculo do Flex-Algorithm. Isso é uma decisão de topologia lógica, não uma prova de que a mídia física ficou bidirecional ou simétrica.

Três formas de restringir o Admin Group reverso

O RFC 9917 define exclude, include-any e include-all para IS-IS e OSPF. Com exclude, a aresta reversa não pode conter o grupo indicado. Com include-any, basta que um grupo da coleção indicada esteja presente. Com include-all, todos os grupos indicados precisam estar presentes. O efeito depende do winning FAD, das regras de poda que precedem essas regras e da capacidade efetivamente disponível em cada nó. O texto não manda que todo roteador suporte toda restrição de Flex-Algorithm.

Essa distinção importa em redes mistas. Um operador pode ver o marcador no estado de enlace e ainda assim não obter a mesma topologia calculada em todos os roteadores. A aceitação deve comparar atributos de ida e volta, FAD vencedor, resultado da poda e caminho escolhido, em vez de inferir funcionamento a partir de um único vizinho.

Regras 8, 9 e 10: ordem é parte do contrato

As novas regras de restrição reversa são as regras 8, 9 e 10 de computação de caminho. Elas estendem o registro ordenado de poda que já vem das bases dos RFCs 9350 e 9843. A ordem relativa das regras existentes não pode mudar. As regras não podem ser removidas, fundidas ou repetidas. Portanto, uma tentativa de “normalizar” a sequência localmente pode produzir uma política diferente, mesmo que os nomes pareçam equivalentes.

A codificação também merece uma prova específica. Comprimentos malformados dos sub-TLVs de afinidade reversa são ignorados. Ocorrências duplicadas acionam os comportamentos de recepção especificados para IS-IS e OSPF. Não há autorização para inventar um tratamento adicional quando o texto não o define. O teste deve capturar o conteúdo recebido, o resultado do parser, o comportamento diante da duplicação e a topologia final observada em cada protocolo.

Churn: quando a evidência vira pressão de controle

Uma contagem de erro oscilando perto do limiar pode alternar o atributo entre set e clear. Isso pode provocar flooding de IGP e recalculações repetidas do caminho. O RFC 9917 aponta limiares distintos para definir e retirar a afinidade e throttling normal de flooding do IGP como controles possíveis. São mecanismos de contenção, não valores seguros para qualquer rede. É preciso medir frequência de atualização, volume de LSDB, número de recálculos, deslocamento de tráfego e tempo de convergência.

Como o operador deve decidir

A pergunta não é apenas “o receptor viu erro?”. É: quem é dono da telemetria e da ação; quais são os limiares de set e clear; a codificação Extended Administrative Group, conforme o RFC 7308, foi validada ponta a ponta; todos os nós relevantes escolhem o mesmo winning FAD; a matriz de suporte para IS-IS, OSPF e regras 8–10 é conhecida; o pior caso de flooding e convergência foi medido; e existe rollback observável e praticável?

Esta análise não é sobre replay de PCEPS do RFC 9916, ciclo de vida de lease DHCPv6 do RFC 9915, projeção de rotas RPL do RFC 9914 ou recuperação RAW do RFC 9912. O tema aqui é mais estreito: evidência de sentido reverso entrando, em ordem definida, na poda de uma topologia IGP Flex-Algorithm.

Livro-caixa de alegações e evidências RFC

Alegação Evidência
Admin Group reverso pode excluir a aresta de ida RFC 9917, resumo e seções 1 e 3
Erro de entrada remoto e exemplo de CRC errors RFC 9917: caso de uso, seção 3
exclude, include-any e include-all em IS-IS e OSPF RFC 9917, seções 5–10
Comprimento malformado e ocorrência duplicada RFC 9917, seções 5–10
Regras 8, 9 e 10 e registro ordenado RFC 9917, seções 11, 12.3 e 12.3.1
Modelo Flex-Algorithm, winning FAD e poda anterior RFC 9350
Extensões anteriores de banda, atraso, métricas e restrições RFC 9843
Codificação Extended Administrative Group RFC 7308
Status Proposed Standard, publicação em janeiro de 2026 e atualizações RFC 9917: front matter

Caminho de decisão para aceitação operacional

Primeiro, documente a origem da telemetria, os proprietários, os identificadores das arestas e o winning FAD. Depois, em laboratório ou em um domínio isolado, provoque separadamente o set e o clear e confira a codificação do RFC 7308, a interpretação por IS-IS/OSPF, a ordem das regras 8–10 e a remoção da aresta de ida. Injete comprimentos malformados e ocorrências duplicadas para registrar exatamente o comportamento definido pelo protocolo. Em seguida, compare nós com e sem suporte, usando limiares distintos e throttling, e meça flooding, recálculo, convergência e impacto de tráfego.

Se suporte, observabilidade ou rollback não puderem ser demonstrados, a decisão é não habilitar em produção; no máximo, manter um piloto isolado com saída reversível.

Fontes