Resumo

  • A RFC 9502 descreve como prefixos IP participam de um cálculo ligado a Flexible Algorithm; ela não afirma que o tráfego atravessou o caminho calculado.
  • Uma sala de controle deve atribuir dono e evidência separados para definição, participação, cálculo, FIB e resultado de serviço.

Há um padrão recorrente em mudanças de infraestrutura: um painel mostra uma nova política, a política recebe um nome compreensível, e o nome passa a circular como se fosse a realização do resultado. No caso de IP Flexible Algorithms, a frase pode ser “o prefixo está no algoritmo 130”. Ela é útil como descrição de configuração. Torna-se enganosa quando passa a significar, sem evidência adicional, que todos os roteadores aceitaram a mesma definição, que IPv4 e IPv6 participam, que a rota foi selecionada, que a FIB foi instalada e que o serviço crítico foi entregue.

RFC 9502 é valiosa justamente porque não apaga essas passagens. A especificação estende a alcançabilidade de prefixos IPv4 e IPv6 para o contexto de IGP Flexible Algorithms. Ela define o terreno de controle no qual uma rota específica de algoritmo pode ser calculada. Não oferece um atalho da intenção administrativa para o comportamento observado. Entre uma ordem e um pacote há decisões locais, capacidades por plano, regras de cálculo e instalações de encaminhamento.

O primeiro proprietário é quem responde pela definição. A FAD, Flexible Algorithm Definition, tem parâmetros e restrições que precisam ser coerentes para os participantes. RFC 9350 determina que um nó que não pode suportar, validar ou aceitar a definição deixa de participar daquele algoritmo. Isso transforma uma discussão de arquitetura em uma pergunta de governança: onde se registra a versão da FAD, quem aprova sua mudança e como se sabe que os nós relevantes a aceitaram? Um print de configuração de um roteador não responde pelos outros roteadores.

O segundo proprietário é quem mantém a capacidade por plano. A extensão de RFC 9502 alcança IPv4 e IPv6, mas a participação é específica a cada IP data plane. Essa distinção deveria aparecer no relatório executivo, não somente na documentação de baixo nível. Um time pode ter validado IPv4 e anunciar “migração concluída” quando IPv6 não participa; ou pode ter dois conjuntos de nós com capacidades distintas sob o mesmo número. O algoritmo é o mesmo identificador, mas o alcance operacional não é o mesmo objeto.

O terceiro proprietário é quem responde pelo cálculo local. Anunciar um prefixo fornece insumo; não fornece automaticamente uma rota instalada. Métricas, topologia, restrições, afinidades e exclusões administrativas moldam o cálculo. Nós não participantes são removidos desse cálculo. Logo, uma ausência de caminho em uma visão de algoritmo não deve ser mascarada por uma afirmação de que o prefixo foi anunciado. O anúncio e a elegibilidade têm papéis diferentes.

Há ainda uma lição útil sobre falhas silenciosas. RFC 9502 trata informação conflitante sobre o mesmo prefixo associada a algoritmos diferentes como algo que deve ser ignorado, sem instalação da rota correspondente. “Não instalar” pode ser a resposta segura e correta. Quando a telemetria mostra uma lacuna, a reação madura não é completar a narrativa com a configuração desejada. É perguntar se a lacuna é uma decisão do protocolo, uma capacidade ausente, uma incongruência de definição ou uma observação incompleta.

O quarto proprietário está no plano de encaminhamento. Participantes podem instalar caminhos na FIB, mas RFC 9502 também limita um IP data plane a uma rota de algoritmo para o mesmo prefixo. Esse detalhe impede um erro frequente de governança: confundir a presença de dois algoritmos no desenho com dois caminhos simultaneamente ativos para o mesmo tráfego. A pergunta correta é concreta: em qual nó, para qual prefixo e em qual instante, qual entrada foi instalada? A resposta pertence a uma tabela, não a um slogan.

O quinto proprietário está mais perto do serviço. Uma FIB confirma uma escolha de encaminhamento local. Ela não mede a sessão do cliente, a latência ponta a ponta, o comportamento de uma aplicação ou o cumprimento de um contrato. Um tracer, uma sonda sintética ou uma amostra de fluxo pode acrescentar evidência de trânsito, mas também tem escopo e janela. Um SLO pode descrever a experiência, mas depende de outra instrumentação. A organização erra quando pede a um único time uma frase total que nenhum de seus instrumentos pode provar.

Essa separação de donos reduz o atrito em vez de criar burocracia. Arquitetura mantém a FAD e suas decisões de restrição. Engenharia de plataforma acompanha capacidade e adesão por plano. Operações de rede mantém cálculo e FIB. Operações de serviço mede resultado. Risco e compras definem o que cada afirmação externa exige. Na ausência desse mapa, a equipe mais próxima da configuração acaba assinando involuntariamente uma garantia de negócio.

Há uma afinidade clara com a observação de Heng Lu em sua nota sobre especificação inicial mínima: uma regra capaz de localizar uma decisão futura não toma essa decisão no lugar dos participantes. A FAD delimita condições para o cálculo. Não obriga um nó a ser capaz, não decide a participação IPv6 e não instala uma rota por decreto. Uma boa estrutura de governança preserva essa localidade, em vez de narrá-la como execução central automática.

A reflexão sobre running code reforça a cautela. Código em funcionamento importa, mas não autoriza uma instituição a declarar que todos os efeitos adjacentes ocorreram. Uma entrada de FIB vale como evidência concreta de decisão local; não é uma procuração para afirmar resultado de aplicação. Essa não é uma limitação embaraçosa da engenharia. É uma fronteira que protege cada responsável de prometer além do que observa.

O registro IGP Parameters da IANA disponibiliza o espaço de identificadores, incluindo a faixa 128–255 para Flexible Algorithms. O registro coordena nomes; não coordena a realidade da rede. Ele não sabe se uma FAD concorda, se um roteador participa ou se um pacote passou. Transformar um número registrado em indicador de entrega seria confundir uma instituição de nomenclatura com um sistema de observabilidade.

Também é útil manter a disciplina dos termos de RFC 8174. Quando uma RFC diz que um nó MUST NOT instalar uma rota em certas condições, ela define conduta protocolar. Não cria evidência para condições que não foram medidas. Em relatórios de alto impacto, o uso cuidadoso de “deve”, “pode” e “foi observado” impede que uma obrigação do software seja relatada como evento consumado.

Uma ficha de mudança adequada pode ser pequena, desde que seja separada. Para cada prefixo crítico, manter: FAD e revisão; matriz de participação por nó e por IPv4/IPv6; resultado do cálculo com motivo de exclusão; FIB em nós de controle; e medições de tráfego/serviço com horário. O pedido de aprovação deve declarar qual dessas cinco camadas constitui o critério de avanço e qual falha dispara recuo. Assim o comité não precisa decidir se “verde” é suficiente sem saber o que verde mediu.

O ponto não é tornar um Flexible Algorithm menos útil. É impedir que sua utilidade operacional seja transformada em linguagem de garantia sem uma cadeia de prova. Uma rota ainda precisa ser calculada; uma decisão ainda precisa ser instalada; um resultado ainda precisa ser observado.