Resumo

  • A RFC 9855 ativa no PLR uma lista TI-LFA pré-instalada e sem loops após detectar falha diretamente ligada.
  • Esse reparo de forwarding local não prova convergência geral, aplicação disponível, sessão preservada ou resultado observado.

“O tráfego foi restaurado” pode significar apenas que um PLR detectou o recurso falho e aplicou uma lista de segmentos preparada antes do evento. É uma evidência técnica séria, mas seu escopo é o roteador local, o recurso protegido e o modelo de falha. Não é ainda uma declaração sobre todos os roteadores, todas as dependências ou o cliente.

RFC 9855 usa entradas de backup pré-computadas e pré-instaladas para agir antes da convergência completa do IGP. A lista codifica um caminho pós-convergência esperado que evita o recurso protegido e, nas condições de FIB do RFC, não forma loop. Ela começa na detecção pelo PLR e termina quando aquele PLR conclui a convergência.

O mecanismo não controla a ordem de convergência em outros roteadores, nem elimina microloops transitórios fora do PLR ou aqueles que podem surgir quando o enlace retorna. P-space, Q-space e segmentos de nó/adjacência constroem um caminho de reparo; limites de lista e programação de hardware continuam relevantes. Uma lista correta para um enlace, nó ou SRLG especificado não demonstra caminho remoto, capacidade, DNS, TLS, banco de dados ou operação de cliente.

Contadores do PLR demonstram ativação de forwarding. Não demonstram que a sessão persistiu ou que uma transação foi concluída. RFC 5286, RFC 7490 e RFC 5715 ajudam a delimitar alternates e microloops, mas não substituem telemetria de ponta a ponta e observação de serviço.

Sources