Resumo

  • O RFC 1863 ordenava servidores pela quantidade de clientes informados e favorecia o menos carregado com o menor DelayTimer; isso produzia um vencedor provável, não um emissor único garantido.
  • A LIST registrava a responsabilidade declarada pelo servidor, não o recebimento, a seleção, a instalação da rota ou a conectividade útil do cliente.
  • O cliente precisava absorver duplicatas e a retomada precisava caber no Hold Time. O RFC 4223 registrou depois que não existiam implementações desse desenho específico.

Uma vantagem de tempo, não um mandato

O RFC 1863, de 1995, propôs route servers BGP/IDRP para reduzir as sessões exigidas por uma malha completa. O cliente se conectava a todos os servidores do cluster para ter redundância, embora normalmente apenas um devesse transmitir as atualizações.

Cada servidor mantinha sua própria lista de clientes informados e cópias das listas dos pares. Elas eram ordenadas pela quantidade de clientes e, em empate, pelo endereço. Se um novo cliente não aparecesse em nenhuma, o servidor na posição N aguardava (N-1) × DelayGranularity.

Ao vencer o prazo, ele examinava as listas novamente. Uma LIST nova que mostrasse outro responsável o fazia permanecer em silêncio; na ausência dela, registrava o cliente, agendava a publicação da lista e começava a enviar. O segundo exame diminuía a janela de estado antigo, mas não tornava atômicas as cópias distribuídas. O RFC reconhecia que a conciliação não eliminava todas as corridas.

A economia era de conexões

O servidor repassava rotas externas com seus atributos e não escolhia a melhor rota para distribuição. O cliente preservava seus critérios e sua política local. O documento chamou a relação de peering virtual e limitou o ganho: cada roteador manteria menos conexões, mas continuaria guardando o volume de informação de roteamento.

Assim, receber no servidor, retransmitir, receber no cliente, selecionar, instalar e encaminhar são recibos diferentes. Centralizar sessões não transformava um candidato em resultado.

O ADVERTISER conservava o endereço do roteador de borda que apresentara a rota. Isso devolvia contexto à política do cliente, sem autenticar a origem. O RFC declarou que não discutia segurança. No caminho entre clusters, RCID_PATH ajudava a detectar loops e era retirado antes de chegar a clientes comuns; não era uma cadeia universal de proveniência.

Informado não queria dizer confirmado

Uma entrada LIST era escrita pelo servidor que julgava estar enviando. Não vinha do cliente e não confirmava UPDATE alguma. Na fase Initiation, um servidor podia aceitar sessões e processar entradas, mas não anunciava até vencer o prazo inicial sugerido de cinco minutos ou receber todas as conexões e listas configuradas. Estar conectado não bastava para assumir a função.

Se dois servidores começassem a enviar, o cliente deveria substituir uma rota anterior quando a nova, vinda de outro servidor do mesmo cluster, tivesse atributos completamente idênticos. A substituição não provocaria outro anúncio. Essa regra continha armazenamento duplicado e flap, sem declarar iguais rotas apenas destinadas ao mesmo prefixo e sem julgar sua verdade.

A falha iniciava outra candidatura

Ao perder a sessão com um servidor do cluster, um sobrevivente verificava os clientes da lista remota. Só considerava um deles se ainda mantivesse sessão direta e se nenhuma lista ativa já o reivindicasse. Depois repetia o atraso e a segunda leitura do procedimento normal.

Não havia um token de propriedade transferido pelo nó morto. A responsabilidade era reconstruída a partir do estado sobrevivente, e a lista antiga só era descartada após a conciliação.

O máximo DelayTimer somado ao Hold Time entre servidores deveria ficar abaixo de dois terços do menor Hold Time voltado aos clientes. No exemplo de três servidores, 90 segundos no cliente comportavam 30 segundos entre servidores e granularidade de 15. A conta reservava tempo para retomar antes da expiração; não provava atualização da tabela nem continuidade do tráfego.

O encerramento veio sem implantação

A página do RFC Editor hoje marca o RFC 1863 como Historic. O RFC 4223 afirmou em 2005 que não existiam implementações do route server ali definido e que ele não era usado como alternativa à malha completa.

Isso não significava ausência de todo route server. O RFC 4223 excluiu outros usos do termo e citou reflexão de rotas, confederações e números AS privados como alternativas. O RFC 2796 e o RFC 4456 descrevem reflectors que selecionam melhor caminho e usam outros atributos contra loops; o RFC 3065 trata de confederações.

Não implementação tampouco equivale a refutação técnica. Ela estabelece que os temporizadores e a recuperação dessa proposta não receberam validação operacional. O mecanismo mostrou como a corrida deveria ser contida; não produziu running code capaz de provar que seria.

O resultado permanecia do lado de fora

Sessão, LIST, atraso curto, segunda leitura, substituição idêntica e margem de Hold Time tinham significados próprios. A conectividade útil ainda dependia de rota atual, política, seleção, instalação, próximo salto e tráfego observado.

A lição histórica é que redundância não é o segundo processo no rack. É a capacidade demonstrável de atravessar um período em que mais de um ator pode considerar sua decisão correta, sem converter ambiguidade em interrupção invisível.

Fontes