Resumo

  • O RFC 9655 cria o Egress TLV opcional 32771, colocado antes do Target FEC Stack, para informar o endereço IPv4 ou IPv6 do egresso último em probes com Nil FEC.
  • Na profundidade zero, o código 36 comprova correspondência exata com endereço local e o 10 nega; um egresso legado pode devolver código 3 sem executar a nova validação.
  • Política, derivação do endpoint, bytes do pedido, capacidade dos nós, encaminhamento observado, reconstrução offline e resultado do tráfego de produção precisam de identidades e relógios próprios.

A escolha escondida dentro do endereço

O Nil FEC de RFC 8029 deixa de carregar informações sobre o FEC associado ao label. Quando aparece por fora, a validação do Target FEC é pulada. Assim, um headend que recebeu uma pilha do controlador consegue testar um caminho mesmo sem conhecer todas as semânticas de outros domínios.

Quando um único Nil FEC representa a pilha inteira, o receptor também perde a forma de saber se é o destino pretendido. Um erro de encaminhamento pode terminar em outro roteador com uma resposta positiva.

RFC 9655 acrescenta o Egress TLV, com quatro octetos para IPv4 ou dezesseis para IPv6. Em profundidade maior que zero, o código 8 relata comutação em trânsito. Quando a pilha chega a zero, o roteador procura igualdade exata entre o valor do TLV e seus endereços de interface ou loopback. Igualdade produz 36; falha produz 10.

O recibo é concreto: este roteador tinha este endereço local quando respondeu. O recibo não enumera todos os segmentos executados.

Endpoint, Adj-SID e Binding SID têm donos diferentes

O caso comum copia o Endpoint da SR Policy de RFC 9256. Se não houver endpoint ou ele for zero, o headend usa o destino do último segmento. Se o último segmento for Adj-SID, escolhe o nó remoto da adjacência. Se for Binding SID, resolve o nó final do caminho representado pelo binding.

Cada ramo depende de estado. Topologia, binding e candidate path podem mudar entre a computação e o envio. Por isso o registro deve incluir policy ID, candidate path, segment list, regra de derivação, resolução do binding, epoch do controlador, build do headend e bytes finais do pedido.

RFC 8402 descreve segmentos como instruções. O endereço no TLV é uma projeção terminal dessas instruções, não uma prova de que cada uma foi aplicada.

Continuidade operacional pode esconder perda de controle

Um trânsito sem suporte pode ignorar o Egress TLV, avançar sobre ele ou devolver erro; o headend pode continuar com TTL maior. Um egresso sem suporte não faz a comparação e pode responder com o código antigo 3.

O teste continua disponível, mas não com o mesmo significado. Operação madura distingue “36 após lookup” de “3 sem prova do lookup”. Preserva se o TLV foi enviado, a capacidade observada, o endereço consultado, profundidade, código, subcódigo, versão e resposta bruta.

O registro IANA registra tipo 32771 e código 36; RFC 9041 esclarece faixas de TLV. Registro coordena números, mas não instala software nem habilita recursos.

Um verificador offline também precisa ser auditado

No traceroute, cada nó é receptor. Respostas sucessivas e as extensões de RFC 8287 podem alimentar uma aplicação que compara o trajeto observado à política esperada. Essa aplicação deve declarar seus inputs, policy epoch, regras para silêncio e tratamento de ECMP.

Preencher um salto ausente com o desenho do controlador transforma intenção em observação falsa. O verdict também não substitui o serviço: probe e tráfego podem usar hashes, tempos e steering diferentes. O último elo precisa de contadores de produção, recepção no destino e resultado da aplicação.

As camadas de realidade de Heng Lu separam intenção, símbolo, execução e resultado. A especificação inicial mínima coordena a identidade comum sem apagar decisão local. A primazia do código em execução exige evidência do binário e da tabela que realmente responderam.

Fontes