Resumo

  • A RFC 9494 mantém algumas rotas depois da janela normal de Graceful Restart, por AFI/SAFI e durante uma Long-Lived Stale Time finita. LLGR_STALE expõe a condição e coloca a rota abaixo de qualquer alternativa não degradada.
  • Enke Chen é coautor das RFCs 4724 e 9494. A extensão não comprova a saúde do caminho antigo: limite local, NO_LLGR, sincronização por End-of-RIB, expiração e riscos documentados de loop tornam a retenção condicional.

O silêncio do controle não apaga o silício

Quando uma sessão BGP cai, a fonte de atualizações desaparece. O estado já programado no plano de encaminhamento, porém, pode continuar no hardware. Nexthops, labels e túneis não evaporam necessariamente junto com o processo de controle. Remover tudo naquele segundo pode transformar um reinício recuperável em indisponibilidade. Manter tudo sem prazo pode fazer um blackhole parecer uma operação tranquila.

Essa separação ficou mais relevante porque BGP carrega objetos de naturezas diferentes. Reachability unicast convencional costuma estar perto da decisão de próximo salto. Estado de VPN, descoberta ou sinalização pode se comportar como informação operacional que sobrevive ao processo que a distribuiu. Redes tunelizadas também separam parte do caminho físico da sessão que o descreve.

Não existe, portanto, uma duração correta para todos os casos. O que precisa ser comum é outra coisa: como declarar que o dado envelheceu, como reduzir seu poder, quem pode rejeitá-lo e quando ele obrigatoriamente some.

A primeira janela cabe em 12 bits

A RFC 4724, de 2007, tem como autores Srihari Sangli, Enke Chen, Ramachandra Fernando, John Scudder e Yakov Rekhter. Ela define a capacidade Graceful Restart e o marcador End-of-RIB. O speaker em reinício pode preservar encaminhamento enquanto reconstrói BGP; o receptor pode reter as rotas do peer, marcá-las stale e aguardar a nova sincronização.

Restart Time tem 12 bits, portanto o maior valor codificável é 4.095 segundos. A RFC sugere um default não superior ao HOLDTIME recebido em OPEN. Se a sessão não voltar dentro do prazo, as rotas retidas são excluídas. Evidência de que o encaminhamento do peer deixou de ser viável também permite a remoção antecipada.

Durante o GR comum, a preferência da rota não muda. O mecanismo troca churn por uma breve presunção de continuidade. A RFC 8538 depois ampliou as formas de término de sessão que podem seguir os procedimentos graciosos e criou Hard Reset para pedir uma reinicialização completa. A presunção continuou sendo limitada no tempo.

Long-lived não significa apenas um número maior

A RFC 9494, publicada em novembro de 2023, foi escrita por James Uttaro, Enke Chen, Bruno Decraene e John G. Scudder. A presença de Chen na especificação original e na extensão longa mostra uma contribuição verificável em resultados coletivos da IETF. Não sustenta autoria exclusiva nem comprova implementação em qualquer rede.

A capacidade LLGR usa o código 71 e traz tuplas <AFI, SAFI, Flags, LLST>. Cada família pode anunciar uma Long-Lived Stale Time própria. Não há valor sugerido como default, porque o risco depende do uso, da escala e do tipo de falha. O receptor pode impor piso, teto ou ambos e reduzir a duração oferecida pelo vizinho.

LLGR também depende da capacidade GR comum. Se ela não vier junto, a capacidade longa deve ser ignorada. Quando os dois períodos são positivos, eles ocorrem em sequência. No primeiro, a rota stale mantém preferência. No segundo, ela passa a ser least preferred. Com Restart Time zero, o operador pode entrar diretamente na condição degradada.

Essa mudança de classe evita um erro conceitual. Na janela curta, espera-se que a mesma fonte volte rapidamente e confirme o estado. Na janela longa, a ausência já enfraqueceu a prova. Dar mais tempo sem diminuir a autoridade seria transformar conveniência em fato.

LLGR_STALE acompanha a dúvida

Ao iniciar LLGR, o helper liga um timer por AFI/SAFI e acrescenta a comunidade well-known LLGR_STALE, valor 0xFFFF0006. A rota deve ser menos preferida que qualquer opção que não esteja no último nível. Se todas as candidatas forem least preferred, os critérios normais voltam a desempatar.

Uma rota fresca, portanto, substitui a antiga. Sem alternativa fresca, a stale ainda pode ser best path e continuar carregando pacotes. A RFC preserva uma chance de serviço, mas nunca declara que o caminho retido está saudável.

A marca não pode sumir na exportação. O speaker não deveria anunciar a rota a um vizinho que não tenha oferecido LLGR, salvo a opção estrita para peers internos ou de confederação. Ao propagar, não pode remover LLGR_STALE. Se a incerteza fosse apagada no salto seguinte, o downstream trataria memória como reachability atual.

NO_LLGR, valor 0xFFFF0007, oferece a recusa explícita. Uma rota com essa comunidade não deve ser retida pelo processo longo e segue a remoção normal de BGP. O emissor pode proteger informações cuja sobrevida seria imprópria; a política do receptor pode impor a mesma condição. Suportar a capacidade não obriga a aceitar cada objeto.

A volta da sessão não reinicia a idade

Reabrir TCP e BGP só prova que os processos voltaram a conversar. A sincronização de um AFI/SAFI termina com End-of-RIB ou com o limite do adiamento de seleção. O LLST continua correndo, e toda rota ainda stale quando ele expira deve ser removida.

Reinícios consecutivos tampouco dão automaticamente uma vida completa ao mesmo estado. Essa regra impede que uma informação nunca refrescada seja rejuvenescida por novas quedas. Se o peer voltar sem as capacidades necessárias, sem a família ou sem a indicação exigida de preservação, o helper também limpa as rotas correspondentes.

Um exemplo da RFC usa Restart Time de um segundo e LLST de 3.600 segundos. Depois do primeiro segundo, as rotas ganham LLGR_STALE e perdem preferência. Sem backup, o roteador de borda ainda as usa e as reanuncia, com a marca, a um peer externo capaz. No vencimento, apaga e envia withdrawals. Se a sincronização terminar em 180 segundos, as rotas refrescadas perdem a marca. Se o peer externo nunca anunciou LLGR, recebe a retirada logo no início da fase longa.

A maior especificidade pode vencer a prudência

O primeiro risco aparece entre duas etapas diferentes. BGP reduz a preferência de um path para o mesmo prefixo. O encaminhamento IP, antes disso, escolhe o prefixo de correspondência mais longa. Um more-specific stale ainda pode capturar pacotes no lugar de uma rota fresca menos específica. A tabela mostra a degradação, mas o tráfego segue para o blackhole estreito.

O segundo risco é a divergência dentro do AS. A RFC descreve um caso em que um roteador abandona a saída antiga após o depreference, enquanto outro continua escolhendo aquela saída. Os dois passam a devolver os pacotes um ao outro. GR comum já pode produzir inconsistência transitória; LLGR pode torná-la persistente.

Daí a regra cardinal: não se recomenda LLGR para rotas usadas em encaminhamento hop-by-hop dentro de um AS. Túneis, como MPLS, removem alguns desses loops; objetos BGP mais distantes do forwarding convencional também reduzem a exposição. Ainda assim, F bit e Forwarding State precisam corresponder ao que foi realmente preservado.

VPNs acrescentam o ciclo de vida dos labels. Um label antigo pode ser realocado para outro contexto depois da retirada. Se uma rota stale continuar ativa, o mesmo valor passa a apontar para um destino diferente. Antes de habilitar LLGR para uma família VPN, o tempo mínimo de reutilização de labels deve ser maior que o teto máximo de LLST. O limite temporal protege isolamento, não só convergência.

Semântica comum, risco local

O ensaio de Lu Heng sobre especificação inicial mínima, decisão futura localizada e adoção voluntária oferece uma lente posterior. O núcleo compartilhado pode definir capacidade, escopo por família, marca de degradação, sinal de recusa, menor preferência e expiração. O operador que suporta a perda decide peers, teto, arquitetura de encaminhamento e causas de remoção antecipada.

Isso evita duas apropriações. A especificação comum não se torna uma ordem central para guardar rotas antigas. A decisão local não permite apagar LLGR_STALE e vender memória como informação fresca. A interoperabilidade dá nome ao estado; a aceitação permanece com quem corre o risco.

A primazia do código em execução exige prova além de uma sessão Established: tuplas AFI/SAFI negociadas, LLST recebida e efetiva, quantidade de rotas em LLGR, mudanças de best path, withdrawals para peers incapazes, progresso de End-of-RIB, perda, indícios de loop e limpeza final. Esta é a aplicação analítica posterior de Sofia Ren a partir de Lu Heng, não uma intenção atribuída a Chen ou aos autores das RFCs.

O rigor da RFC 9494 está em não rebatizar a rota. Enquanto for antiga, ela continua stale. Pode manter um serviço como último recurso, mas só dentro de uma duração aceita e sem apagar o aviso. Continuidade confiável começa por admitir o quanto a evidência se degradou.

Fontes