Resumo

  • O RFC 9815, classificado como Standards Track em sua página de informações, define o Node SPF Status 2 como uma restrição de trânsito. Se esse status antes anunciado deixa de acompanhar a Node NLRI, a informação anterior é implicitamente retirada e o nó volta a ser considerado ativo e elegível para trânsito.
  • Essa elegibilidade não equivale a uso efetivo como próximo salto intermediário. Topologia, métricas, cálculo SPF, estado de encaminhamento instalado e os fluxos realmente testados continuam determinando o que acontece. Por isso, “o serviço voltou” e “a restrição de não trânsito sobreviveu” precisam ser aceitos separadamente.

A cena é deliberadamente hipotética. Uma revisão de mudança após um reinício a frio chega à seguinte tabela:

Afirmação de aceitação Estado Responsável pela prova Evidência disponível
O serviço voltou a ser alcançável Verde Responsável pelo serviço Prefixos necessários respondem aos testes definidos
O nó continua impedido de carregar trânsito Não comprovado Responsável pelo roteamento O status 2 que existia antes da mudança não está presente

A primeira linha não corrige a segunda. O serviço pode responder exatamente como esperado enquanto a restrição que impedia a expansão do nó como caminho de trânsito deixou de existir.

Essa divisão de responsabilidades não vem prescrita pelo IETF. É uma recomendação operacional: alguém deve responder pela aceitação positiva de alcançabilidade, e alguém deve responder pela preservação da propriedade negativa de não trânsito. A mesma equipe pode exercer as duas funções; o ponto é que as duas afirmações não devem ser fundidas em um único “verde”.

A ausência do TLV tem semântica própria

O ponto de partida está no próprio desenho do protocolo. O RFC 9815 determina que todos os roteadores de um domínio BGP-SPF anunciem sua Node NLRI incondicionalmente. A condição do nó perante o cálculo SPF pode ser carregada separadamente no Node SPF Status TLV, de tipo 1184.

Na Seção 5.2.1.1, a ausência desse TLV tem significado definido: o nó é considerado ativo e disponível para tráfego de trânsito. Se uma Node NLRI anteriormente chegou com um SPF Status e uma atualização posterior chega sem o TLV, o estado anterior é considerado implicitamente retirado.

Esse comportamento é particularmente importante em mudanças porque “campo opcional” não significa “campo sem consequência quando ausente”. A codificação pode ser opcional, mas sua ausência representa um estado concreto do protocolo.

No cenário da tabela, portanto, não é correto interpretar o desaparecimento do valor 2 como simples falta de telemetria. Pela semântica normativa, a restrição anterior deixa de participar do cálculo. O nó recupera a condição padrão de elegibilidade para trânsito.

A inferência operacional termina aí. Elegibilidade não quer dizer seleção.

Mesmo com o status 2 ausente, um nó só aparecerá em determinado caminho se a topologia e as métricas produzirem essa escolha no cálculo SPF. O resultado ainda precisa repercutir no estado de encaminhamento instalado, e um fluxo específico precisa realmente atravessar aquele caminho para que se possa afirmar uso no plano de dados. A ausência do status 2 abre uma possibilidade que estava bloqueada; não determina sozinha que a possibilidade será exercida.

Status 1 e status 2 mudam partes diferentes do cálculo

A diferença fica mais nítida no algoritmo descrito na Seção 6.3 do RFC 9815.

No passo 3, um nó cujo SPF Status indique inacessibilidade é ignorado. Esse é o efeito do valor 1: para fins de BGP-SPF, o nó não prossegue como nó alcançável no cálculo.

No passo 4, os prefixos associados ao nó corrente alcançável são considerados para instalação. O status 2 não faz o nó desaparecer dessa etapa. A própria finalidade da modalidade de não trânsito é permitir que o nó e seus prefixos continuem acessíveis.

A diferença decisiva surge no passo 5. Quando o nó corrente carrega o status 2, seus Link NLRIs de saída não são expandidos para continuar a árvore através dele. Em termos operacionais, o SPF pode chegar ao nó e aos prefixos que ele origina, mas não deve usá-lo para avançar em direção a outros nós.

Isso esclarece a razão pela qual uma verificação de serviço é insuficiente como prova de não trânsito. O funcionamento do serviço confirma justamente uma característica compatível com o status 2: chegar ao nó continua permitido. Uma resposta positiva não informa, por si só, se a expansão dos enlaces de saída permanece suprimida.

Há então duas perguntas diferentes para a revisão de mudança:

  1. O nó e os prefixos necessários continuam alcançáveis?
  2. O cálculo continua impedido de expandir os enlaces de saída desse nó como trânsito?

A primeira pode estar verde e a segunda continuar sem evidência.

O valor 2 ocupa um espaço normativo estreito

Os valores do Node SPF Status não formam uma escala genérica de saúde.

O registro definido na Seção 8.3 do RFC 9815 e o registro BGP SPF da IANA estabelecem 0 como reservado, 1 como nó inalcançável perante o BGP-SPF, 2 como nó que não suporta tráfego de trânsito, 3 a 254 como não atribuídos e 255 como reservado.

Isso impede duas ampliações sem base no texto.

Primeiro, status 2 não deve ser reinterpretado automaticamente como “manutenção”, “sobrecarga”, “degradação” ou qualquer outro estado operacional geral. Essas podem ser razões locais para alguém desejar uma restrição, mas não são significados atribuídos ao valor 2 pelo RFC.

Segundo, os valores ainda não atribuídos não são licenças para criar semânticas locais que o SPF deva compreender universalmente. Para um valor desconhecido, o RFC manda preservar sua propagação e ignorá-lo no cálculo SPF; a implementação pode registrá-lo para análise. Assim, 3–254 continuam sem significado SPF atribuído no registro atual.

Os valores reservados têm tratamento diferente. Se o Node SPF Status TLV contém 0 ou 255, o TLV é considerado malformado. A Seção 7.1 determina que a Node NLRI correspondente seja tratada como retirada, pelo procedimento de treat-as-withdraw. Isso é qualitativamente distinto tanto da ausência do TLV quanto de um valor desconhecido não reservado.

O código 1184 também tem atribuição precisa

A procedência dos números importa quando a evidência operacional é revisada.

A Seção 8.2 do RFC 9815 associa o código 1184 a SPF Status. A mesma atribuição aparece no registro BGP-LS Parameters da IANA.

Já os valores específicos do Node SPF Status pertencem ao registro BGP SPF, refletindo a Seção 8.3. É nesse registro que aparecem 1 para inalcançável, 2 para não trânsito, 3–254 não atribuídos e os valores reservados nas extremidades.

Essas duas tabelas não devem ser atribuídas à página geral de parâmetros BGP. O código do TLV e os valores internos do status têm registros próprios, e essa precisão evita transformar uma verificação documental simples em uma cadeia de atribuições imprecisas.

O RFC 9816 limita os exemplos de não trânsito

O RFC 9816, cuja página de informações o apresenta como documento de uso e aplicabilidade associado ao RFC 9815, ajuda a delimitar o que o status 2 pretende resolver.

Sua Seção 7 fornece dois casos de aplicação para a capacidade de nó não transitável.

O primeiro é um servidor que precisa disponibilizar serviços de aplicação a clientes em diferentes sub-redes do domínio BGP-SPF sem funcionar como roteador de trânsito. O segundo é um controlador residente em um servidor que precisa ser diretamente alcançável em todo o domínio sem carregar tráfego de trânsito.

O alcance desses exemplos deve ser preservado. Eles mostram por que um nó pode precisar participar da topologia e continuar alcançável sem servir como caminho intermediário. Não demonstram que operadores já empregam o mecanismo em uma determinada escala, não documentam um caso real específico e não redefinem o status 2 como instrumento de manutenção ou controle de sobrecarga.

Essa contenção é relevante para governança técnica. Uma equipe pode adotar razões locais para ativar o estado de não trânsito, mas o registro de mudança deve distinguir a razão local da semântica padronizada que o protocolo realmente executa.

Visibilidade topológica não substitui a verificação do caminho

A separação entre visão de controle e prova de encaminhamento aparece no documento de aplicabilidade, não no mecanismo básico do status 2.

A Seção 5.5.2 do RFC 9816 explica que os anúncios BGP-LS-SPF podem ser usados para construir uma visão da topologia para diagnóstico e verificação de consistência. O texto acrescenta que uma ferramenta central também pode ser empregada para verificação do caminho de dados, deixando algoritmos e heurísticas fora do escopo.

Essa formulação é importante porque evita uma equivalência fácil demais entre “a topologia mostra a restrição” e “nenhum fluxo transitou pelo nó”.

Uma verificação do estado anunciado pode demonstrar que o status 2 está presente na informação usada pelo cálculo. Uma inspeção do resultado calculado pode mostrar quais caminhos deveriam ser escolhidos naquele momento. Uma verificação do caminho de dados pode observar fluxos concretos. São camadas de evidência distintas.

Daí segue uma inferência operacional limitada: um teste negativo de trânsito só sustenta a afirmação correspondente aos fluxos definidos, nos instantes definidos e sob as condições observadas. Se dois pontos de teste não veem o nó no caminho, isso não prova uma ausência universal de trânsito para todos os fluxos possíveis.

O erro simétrico também deve ser evitado. A ausência do status 2 restaura elegibilidade, mas não é prova de que houve trânsito. Sem evidência do cálculo resultante e do caminho percorrido, a afirmação correta é apenas que a proteção normativa deixou de bloquear essa utilização.

Depois do reinício, quem fecha cada linha?

Retorne à tabela inicial. O serviço passou no teste. A Node NLRI reapareceu, como se espera de um participante BGP-SPF, e os prefixos relevantes são alcançáveis. O responsável pelo serviço possui base para aprovar sua linha.

O responsável pelo roteamento, porém, enfrenta outro critério. Antes da mudança havia um status 2; depois dela, ele não aparece. Segundo a semântica do RFC, isso não mantém silenciosamente o estado anterior. A omissão retira implicitamente a informação de status e devolve a disponibilidade para trânsito.

Nesse ponto, um simples “tudo está verde” mistura afirmações incompatíveis em uma mesma aceitação.

Se a intenção operacional continua sendo não trânsito, a evidência necessária deve mostrar que o status 2 voltou a ser anunciado e que o comportamento relevante foi verificado no escopo adequado. Se a intenção mudou e o nó deve voltar a ser elegível, essa decisão também precisa ser explícita. O que não é seguro concluir é que a alcançabilidade bem-sucedida carregou consigo a antiga restrição.

Esse é o limite central do problema: alcance positivo e restrição negativa têm donos de prova diferentes, mesmo quando a mudança técnica é a mesma.