Resumo

  • O Internet-Draft individual de 2 de novembro propõe limitar Node e Link NLRI internos à área de origem, mas permitir que a alcançabilidade de Prefix atravesse áreas.
  • A borda associa o prefixo distante a uma saída alcançável localmente. O caminho de áreas impede que um anúncio retorne a uma área anterior; a ausência de loops nos pacotes com múltiplas saídas ainda depende de regras não especificadas.
  • A próxima versão precisa dizer como representar o prefixo remoto, combinar métricas e comparar bordas. Um teste com duas saídas e uma falha deve confrontar anúncios, FIB e pacotes.

No exemplo do documento, P fica na área C e A1, na área A, quer enviar um pacote. A1 não recebe os links internos de C. Recebe a informação de que P é alcançável pela borda voltada para B e usa sua topologia local para calcular o trajeto até ali. B e C resolvem os trechos seguintes. A proposta economiza a distribuição de detalhes distantes, mas põe a qualidade do resumo nas mãos de quem controla a fronteira.

O ponto de partida é a RFC 9815, com estado de links e cálculo SPF distribuído. Na proposta nova, cada roteador recebe um Area ID; quem tem um vizinho em outra área atua como roteador de borda, sem designação prévia. Node NLRI e Link NLRI internos ficam locais. Um link entre áreas pode ser conhecido pelas duas vizinhas. Prefix NLRI pode seguir além. O texto cita grandes redes de satélites de órbita baixa como aplicação possível; não apresenta implantação, medição de desempenho ou redução de tempo de convergência.

Uma falha dentro da área B mostra o critério de exportação. Se B1–B2 cair e as conexões com A e C continuarem úteis, B divulga a mudança de Link NLRI internamente e recalcula suas rotas. Desde que o alcance ou os atributos anunciados para P não mudem, A e C não precisam conhecer o detalhe. Se a conexão B–C cair sem alternativa, B deve atualizar ou retirar a informação de alcance de P. O que atravessa a fronteira é a mudança na promessa externa, não toda ocorrência interna.

É no segundo caminho para P que a especificação ainda deve trabalho. A revisão 00 deixa em aberto a representação exata do prefixo na borda, a composição de métricas e o tratamento de bordas candidatas múltiplas. Também posterga a sinalização do Area ID, a codificação do caminho de áreas, a operação mista e a relação com originação, números de sequência e route reflectors da RFC 9815. Esses detalhes definem quais rotas entram na tabela de encaminhamento. Sem eles, “alcançável” pode significar uma saída diferente para cada área.

O teste de loop do plano de controle é específico. Um anúncio que saiu de C, passou por B e chegou a A não pode ser enviado de volta a B: B já está no caminho de áreas. O pacote não lê a história do anúncio; segue o próximo salto instalado. O próprio draft distingue as coisas: com várias bordas, caminhos alternativos e métricas calculadas de modo independente, o encaminhamento sem loop exige procedimentos adicionais de seleção e representação. Barrar a volta da mensagem não escolhe o destino físico do pacote.

A borda ganha também a chance de falsear o resumo. A seção de segurança observa que uma borda comprometida pode suprimir anúncios locais, criar alcance remoto fictício ou manipular o caminho de áreas. As demais áreas não terão o mapa detalhado que poderia contradizê-la. A próxima revisão deve tornar explícitas escolha, substituição e retirada; o ensaio deve ligar a sequência de anúncios às rotas instaladas e ao percurso real durante uma falha. Esconder o mapa é a parte fácil. Entregar ao endereço anunciado é o serviço comprado.

Draft Area-Scoped BGP-LS-SPF, revisão 00 · RFC 9815