Resumo

  • No mecanismo proxy do RFC 1482, ouvir qualquer um de vários prefixos componentes podia fazer o backbone criar e propagar um agregado maior. A presença da cobertura não demonstrava que todos os componentes estavam ativos.
  • O registro proposto distinguia Home AS, Announcing AS e os Neighbor AS de cada etapa. A intenção cadastrada, a configuração instalada, a rota observada e o resultado do pacote precisavam de testemunhos próprios.

O buraco continuava existindo sob a cobertura

Em 1993, reduzir a tabela de rotas exigia que uma afirmação ampla substituísse muitas afirmações estreitas. O RFC 1482 levou essa ideia à base de roteamento por políticas da NSFNET e descreveu duas formas de receber um agregado.

Uma rede regional compatível com CIDR poderia anunciar diretamente um prefixo agregado. A base indicaria de quais ASs essa informação era esperada. Uma rede ainda incapaz de fazê-lo dependeria de agregação por procuração no backbone.

O exemplo de GateD colocava três componentes em uma lista OR. Bastava ouvir qualquer um deles para armazenar e anunciar o bloco superior como se o agregado tivesse sido recebido. A sintaxe ainda era ilustrativa, mas a condição era clara: um fato parcial acionava uma representação mais abrangente.

Isso economizava entradas. Também permitia que a cobertura sobrevivesse enquanto um componente desaparecia. Um roteador remoto poderia enviar tráfego corretamente segundo a rota agregada, apenas para que o pacote encontrasse, mais adiante, uma parte sem rota específica.

O RFC mencionou esse percurso: o tráfego para um buraco poderia cruzar um AS e ser descartado depois. O anúncio não era falso por existir; era mais limitado do que uma garantia de alcance para cada endereço contido no prefixo.

A lista de fontes esperadas não era um coletor de rotas

Antes da agregação, a base NSFNET já associava números de rede aos ASs dos quais seus anúncios eram esperados. O exemplo da rede 35 incluía fontes primárias, secundárias e adicionais.

Essa relação configurava uma regra de aceitação. Não registrava a chegada de uma atualização. Um AS autorizado podia permanecer silencioso. Uma atualização recebida podia não ser escolhida. Uma rota escolhida podia não chegar ao plano de encaminhamento.

Na saída, sentenças announcetoAS definiam o que seria mostrado a cada vizinho. Havia modos irrestrito e restrito, inclusões, exclusões e a possibilidade de não anunciar nada a um AS. Dois vizinhos podiam receber imagens diferentes do mesmo backbone por desenho, não por defeito.

As redes intermediárias enviavam essas políticas à Merit, que as incorporava aos arquivos de configuração dos roteadores ANSnet. A solicitação, a linha de banco, o relatório, o arquivo gerado, a leitura pelo software e o estado em execução eram versões sucessivas. O RFC previa mudanças nas ferramentas, nos relatórios, nos parsers e no processo de geração, além da transição conceitual de rcp_routed para GateD.

A casa do agregado não era todo lugar de onde ele partia

O Aggregate Registry proposto registraria prefixo, Home AS, Announcing AS, Neighbor AS e contatos. O Home AS era o provedor que inicialmente reunia o alcance dos componentes. Outros ASs poderiam anunciar o mesmo agregado aos próprios vizinhos.

No exemplo, AS 100 era a casa. O prefixo reaparecia em linhas para AS 690, AS 200 e AS 201, cada uma com destinatários distintos. A repetição mostrava uma cadeia de propagação pretendida.

Um observador atrás de AS 201 poderia receber a atualização desse trânsito. Isso não tornava AS 201 a casa do agregado. Também não autorizava dizer que o observador recebera diretamente de AS 100. Home, anunciante intermediário e vizinho receptor eram papéis diferentes.

As atualizações do registro chegariam por e-mail ou ferramenta on-line. O texto não especificou publicação autenticada, carimbo temporal de observação, recibo de retirada ou conciliação automática com tabelas de protocolo e encaminhamento. A seção de segurança declarou que o tema não fora discutido. Portanto, o registro coordenava intenção; não substituía telemetria.

O detalhe removido não voltaria para cada vizinho

Na implantação inicial, a NSFNET não desagregaria os blocos ao anunciá-los. Quem precisasse de roteamento completo deveria usar um protocolo compatível com CIDR. Um peer baseado em rota default continuaria enviando tráfego para a cobertura, sem receber o inventário de componentes.

A granularidade vista por um observador era parte de seu acordo de troca. Ver apenas o agregado não provava que o exportador ignorava os específicos. Conhecer específicos internamente tampouco significava que todos os vizinhos os receberiam.

O RFC 1338 e o RFC 1519 apresentam a arquitetura de alocação e agregação que respondia ao crescimento. O RFC 1771 detalha depois os atributos e o caminho de AS do BGP-4. O RFC 1786 oferece uma linguagem de registro de políticas mais rica. Esses documentos explicam a evolução; não provam que toda linha ou regra prevista em 1993 entrou em produção.

Trinta e três por cento era uma conta de planejamento

O RFC calculou uma redução potencial de 4.135 anúncios sobre 12.348, ou 33%. Chamou o resultado de estimativa otimista obtida por um algoritmo pessimista e disse que a economia real poderia ser diferente.

Não foi uma medição anterior e posterior em roteadores implantados. Era um cenário sobre o que poderia ser agregado. Também não resolvia automaticamente o crescimento futuro da tabela ou o esgotamento de endereços.

O registro do RFC Editor classifica o texto como histórico. O próprio documento dizia que a implementação estava em andamento, mas deixava planejamento, debate, depuração, estabilidade, algoritmos de decisão e tratamento de buracos para trabalho adicional. Uma iniciativa em curso não prova a configuração de um equipamento específico.

O resumo da rota exigia uma auditoria sem resumo

O ganho da agregação era fazer muitos destinos caberem em uma declaração. Seu risco documental era perder a explicação de como aquela declaração se tornou visível.

Uma auditoria precisa separar os componentes, o limite agregado, o Home AS, cada trânsito, o público de cada vizinho, a versão do registro, os arquivos gerado e instalado, a atualização recebida, a escolha, a exportação, o próximo salto e a resposta do destino.

Se apenas o agregado final for preservado, a história saberá que havia uma direção. Não saberá qual componente ativou a regra proxy, quem pretendia falar para quem, nem qual endereço atravessou o AS até encontrar o vazio. O RFC 1482 mostrou que economizar linhas na tabela aumentava o valor das linhas de proveniência.

Fontes