Resumo

  • A alcançabilidade do NEXT_HOP continua necessária, mas túneis e segment routing podem fazer o encaminhamento depender de outro endpoint, contexto e repositório de rotas.
  • A tupla proposta obriga alcançabilidade, preferência, métrica e rastreamento a vir da mesma resolução; instalação e entrega do pacote exigem comprovantes próprios.

O endereço de controle não é o caminho inteiro

O modelo da RFC 4271 pressupõe que o speaker BGP consegue verificar NEXT_HOP e obter o custo interno até o endereço. GRE, MPLS, SR Policy e SRv6 desfazem a correspondência simples. O endereço do plano de controle pode responder enquanto o endpoint do túnel, a política ou o SID de serviço que carregaria o pacote deixou de existir.

A revisão 00 de BGP Best Path Selection Based on Next Hop Resolution foi publicada em 24 de setembro de 2026 como Internet-Draft Standards Track do grupo IDR. Se aprovada, atualizará a RFC 4271. Ainda não é RFC, consenso final, ordem de implementação ou medição de adoção.

O texto cria uma unidade precisa: a tupla de resolução de caminho, composta por chave e contexto opcional. A chave pode ser o NEXT_HOP comum, o Tunnel Egress Endpoint da RFC 9012 ou um SID de serviço SRv6 da RFC 9252. O contexto identifica ou parametriza procedimento e base usados na resolução: Tunnel Encapsulation, comunidade estendida Color ou informações de sub-TLV SRv6 além do SID.

Assim, {N1, C1} e {N1} não são evidências intercambiáveis. Mesmo com a mesma chave, resolver pela SR Policy e consultar o próximo salto convencional são pedidos diferentes.

Uma resolução não pode ser remontada com peças alheias

A regra central exige que resolubilidade, preferência, métrica e estado de rastreamento pertençam à mesma resolução. Usar o “alcançável” do contexto A e o custo mais atraente do contexto B fabrica um caminho que nenhum sistema realmente resolveu.

Restrições limitam quais rotas ou bases podem satisfazer a tupla. Elas podem exigir um tipo de túnel, impedir resolução por agregado ou ordenar classes de transporte. Não são um terceiro componente da tupla; são regras locais de elegibilidade.

A verificação normal de NEXT_HOP permanece. O rascunho acrescenta, por configuração, a resolução da tupla sob essas restrições. Um objeto específico de túnel disponível não autoriza ignorar um próximo salto convencional quebrado.

Números também não garantem comparabilidade. Uma métrica pode significar custo IGP; outra, latência; uma terceira resolução pode não produzir custo. Uma preferência de chave de resolução local, numérica e com menor valor preferido ordena primeiro mecanismos diferentes. Só depois o custo interno, vindo exclusivamente da tupla, participa da escolha. Sem métrica, usa-se o custo máximo permitido.

Oito comprovantes, sem atalhos

O comprovante de anúncio preserva rota, NEXT_HOP e atributos. O de tupla registra chave, contexto e derivação. O de restrição identifica política e base elegível. O de resolução une alcançabilidade, preferência, métrica, dados de encaminhamento e horário em um resultado atômico.

O comprovante de seleção mostra candidatos, filtros e vencedor. O de rastreamento identifica assinaturas para o próximo salto e cada contexto, inclusive caminhos não vencedores. O de instalação observa RIB, FIB e encapsulamento. O de entrega mede trajetória e resultado do serviço.

Seleção não prova instalação; instalação não prova entrega. Congestionamento, descarte e encaminhamento incorreto aparecem no rascunho como riscos, não como estatística de campo nem prova de que o mecanismo os resolverá.

Caminhos não vencedores também mudam

O speaker deve rastrear o NEXT_HOP comum e a tupla. Se qualquer um deixar de resolver, ou se a métrica da tupla mudar, todos os prefixos afetados precisam ser reavaliados. Chaves iguais com contextos diferentes exigem assinaturas distintas. Caminhos não vencedores também precisam ser acompanhados, pois podem voltar a ser elegíveis sem novo anúncio.

Deduplicar {N1, C1} e {N1} em um único watcher elimina justamente o limite de evidência que o mecanismo pretende preservar.

Regra comum pequena, decisão local explícita

A proposta acompanha a defesa de Heng Lu por uma especificação inicial mínima e decisões futuras localizadas. A norma pode definir identidade da tupla e proibir mistura sem impor preferência mundial de transporte. Restrições, valores e implantação continuam sob autoridade local.

A distinção entre autoridade e crença também se aplica. O anúncio prova o que foi anunciado; a resolução prova o que um sistema encontrou. Nenhum prova o percurso real. A primazia do código em execução pede versões, registros atômicos, estado programado e observação de pacotes.

Color pode participar do contexto, mas o tema não deve ser absorvido pelas classes de transporte da RFC 9830. Aqui, a pergunta não é se importação de Color ou SLA estão corretos; é se todos os fatos de uma decisão BGP descrevem a mesma resolução.

Estado e limites

A revisão recomenda configuração consistente dentro de um domínio administrativo. Isso reduz divergência, mas não prova o plano de dados. Restrições erradas, bases desatualizadas e preferências inconsistentes continuam perigosas, ainda que o texto não acrescente considerações de segurança ao uso existente de NEXT_HOP.

O rascunho e as implementações podem mudar. Seu valor imediato é tornar explícito o atalho proibido: não montar a aparência de um caminho com fatos obtidos sobre caminhos diferentes.

Fontes