Resumo

  • A RFC 7911 combina o prefix com um Path Identifier local de quatro octetos, permitindo que vários anúncios coexistam na direção negociada de uma sessão.
  • O emissor escolhe o conjunto exposto; o receptor preserva import policy, best path, multipath e FIB. O identificador não é ranking, identidade global persistente, origem nem prova de diversidade.
  • A implantação precisa provar capacidade efetiva por AFI/SAFI, conjuntos enviados e recebidos, custo de estado, retirada individual e forwarding. Mais objetos visíveis não significam mais saídas utilizáveis.

Route reflection é uma forma de compressão. Em uma malha completa, cada speaker recebe candidatos diretamente. O reflector reduz o número de sessões e costuma anunciar apenas a rota que selecionou como melhor. O cliente recebe uma conclusão operacional, mas nem sempre as opções que levaram a ela.

O acordo funciona enquanto a escolha do reflector também serve ao cliente. Falha quando o caminho omitido seria aceito pela política local, permaneceria após uma pane ou seria melhor a partir da posição IGP do cliente. A sessão pode estar estabelecida e a rede ainda assim oferecer menos escolha lógica do que sua infraestrutura possui.

O BGP clássico acentua a perda. Um novo anúncio do mesmo NLRI vindo do mesmo peer substitui implicitamente o anterior. O prefix é a chave. Sem extensão, a sessão não mantém duas rotas simultâneas do mesmo prefix com ciclos de vida independentes.

A RFC 7911 coloca um Path Identifier de quatro octetos antes do NLRI. A chave passa a ser o par prefix-identificador. Um anúncio do mesmo par substitui apenas essa ocorrência; uma retirada apaga apenas ela. Uma retirada com identificador nunca visto deve ser ignorada, e não interpretada como exclusão de todas as rotas do prefix.

O número tem escopo local. É atribuído pelo speaker que anuncia para aquela sessão. Ao republicar uma rota, outro speaker cria seu próprio valor, sem preservar o identificador upstream como rótulo fim a fim. Depois de restart, os valores podem mudar. Sua magnitude não informa preferência, idade, qualidade, proveniência ou origem.

Isso torna o identificador útil para o protocolo e perigoso como identidade de negócio. Correlacionar “path 14” entre reflectors fabrica vínculo inexistente. Exigir o mesmo número após restart confunde continuidade de um token com continuidade da rota. A prova deve comparar attributes, função, next hop e relação de forwarding.

Capability code 69 também é direcional. Cada tuple declara AFI, SAFI e modo receive, send ou both. O encoding com múltiplos caminhos funciona num sentido apenas quando o sender anuncia send e o receiver anuncia receive para a mesma família. O sentido inverso pode continuar clássico.

Uma sessão pode, portanto, enviar vários caminhos IPv4 unicast apenas em uma direção e manter IPv6 single-path. Um reflector pode expor opções aos clientes sem receber todos os candidatos deles. A frase “ADD-PATH habilitado” não descreve esse contrato efetivo.

Capability autoriza transporte, não escolhe conteúdo. A RFC 7911 recomenda incluir a melhor rota, exceto quando aprendida do mesmo vizinho, mas não exige todos os caminhos. Uma implementação pode oferecer all, N-best, o best por AS vizinho, caminhos multipath-eligible ou um subconjunto de policy.

O algoritmo determina a utilidade. Dois caminhos com o mesmo next hop, site, line card, provider e conduit acrescentam estado sem formar duas saídas. Um best por AS melhora diversidade comercial, mas pode compartilhar a mesma fibra. Path Identifiers contam objetos de controle, não destinos de falha independentes.

A RFC 7964 mostra o trade-off no problema específico de oscilação persistente por MED. All available paths se aproxima da consistência informacional de full mesh, com mais estado. Group Best reduz ao melhor por AS vizinho sob condições topológicas. A redução serve a um mecanismo particular e não deve virar regra universal.

O receptor continua soberano. Pode rejeitar anúncios, selecionar um best, construir um conjunto multipath ou guardar alternativas fora da FIB. A RFC 7911 não substitui o Decision Process da RFC 4271. Receber quatro caminhos não habilita ECMP nem obriga hardware a instalar quatro.

Por isso, quatro entradas em Adj-RIB-In não provam quatro egressos. Uma pode ser filtrada, outra ter next hop irresolvido e duas convergirem na mesma adjacency da FIB. Até o Loc-RIB pode selecionar mais do que a plataforma programa. A afirmação só é confiável quando segue policy, decisão, recursão, FIB e packet test.

Path hiding em route server de IXP é um caso claro. A RFC 7947 descreve um server que escolhe uma rota rejeitada pela política de certo cliente, enquanto outro candidato presente seria aceito. Se só a primeira for anunciada, o cliente fica sem rota. A policy local funciona corretamente sobre um input artificialmente estreito.

ADD-PATH pode ampliar o input, porém a fronteira de confiança importa. A RFC 7947 alerta que uso bidirecional no route server pode propagar rotas inativas, inválidas ou subótimas dos clientes. Nesse cenário recomenda server send-only e clientes receive-only. É uma distribuição de autoridade de IXP, não uma receita para todo reflector interno.

Dentro de um AS, conjuntos diferentes por cliente podem ser deliberados. Edge routers robustos talvez precisem de mais diversidade; equipamentos menores, de limite baixo. Mas cada diferença precisa registrar role, family, algoritmo, máximo e resultado de convergência esperado. Sem isso, ninguém consegue reconstruir o direito de visibilidade durante a falha.

O estado custa. A RFC 7911 menciona exaustão de memória e instabilidade em rede. Cada caminho acrescenta RIB, attributes, avaliação de policy, updates e telemetry. Uma reserva silenciosa em estado normal pode virar um pico de decisões e withdrawals durante incidente.

A RFC 6774 chega ao mesmo limite por outra arquitetura de distribuição. Reduzir path starvation e conhecer backups antes da falha exige cópias e processamento. Visibilidade deve ter orçamento, admission limit e benefício verificável.

Os produtos separam as camadas. Cisco distingue capability, additional-path selection e advertisement. Junos separa configuração send/receive do estado negociado. FRRouting oferece all, per-AS-best, N-best e receive limits. São exemplos específicos, mas revelam tudo que o change record deve nomear.

A primeira evidência é uma matriz por vizinho e AFI/SAFI: modos anunciados localmente, recebidos remotamente e direção efetiva. Depois vêm algoritmo do sender, máximo, export filters, inclusão do best normal e diferenças por cliente.

O baseline guarda conjuntos exatos, não só contagens. Em Adj-RIB-Out: prefix, Path Identifier local, next hop, AS_PATH, origin, MED, communities e motivo de elegibilidade. No receiver: Adj-RIB-In, decisão de import, razão de best, multipath, Loc-RIB e FIB. Identificadores de speakers diferentes jamais viram chave global.

Replacement e withdrawal precisam usar a chave completa. Reanunciar o mesmo par com attributes novos muda só aquela rota. Retirar um identificador deixa os irmãos. Retirar um desconhecido não apaga nada. Esses testes encontram collectors e automações que ainda trabalham por prefix apenas.

Restart tem critério diferente. Os números podem mudar. Verifica-se se tokens antigos somem, alternativas com attributes esperados retornam no prazo e nenhum orphan sobrevive na FIB. O objeto estável é a relação entre rota, política e forwarding.

Diversidade é medida por failure domain: next hop, AS vizinho, site, line card, link, provider, conduit e policy. Onde não há dados, escreve-se “desconhecido”. Dois identificadores não transformam incerteza em redundância.

O teste final remove o egress preferido. Mede se uma alternativa já visível se torna best sem nova exploração remota, além de update volume, decision time, next-hop resolution, FIB programming e packet loss. Repete-se com alternativa filtrada, irresolvida e de destino compartilhado.

Capacidade é contrato de admissão. Defina limites por peer, family e prefix, memória, taxa de update, retenção de telemetry e comportamento em excesso. Descartar arbitrariamente rotas sem aviso recria path hiding atrás de uma capability aparentemente saudável.

Rollback vai além de tirar uma linha. Deve contrair o conjunto, remover identificadores antigos e limpar a FIB. Se capability renegotiation exige reset de sessão, o risco de reachability integra a aprovação inicial.

O princípio de especificação inicial mínima de Heng Lu explica a fronteira. O mecanismo compartilhado é pequeno: uma capability direcional e um discriminador local. O conjunto exposto, o orçamento recebido e a escolha na FIB permanecem locais. Interoperabilidade não exige centralizar decisões futuras.

Running-code primacy organiza a prova. Configuração é intenção. Capability negociada, tuple transmitido, rota aceita, motivo de seleção, next hop programado e pacote observado são fatos progressivamente mais fortes. Se a alternativa não atravessa a cadeia, ela não é opção operacional.

Data sovereignty aparece como controle de visibilidade. O sender controla o que revela; o receiver, o que usa; a rede física condiciona o resultado. Nenhuma contagem apaga essas autoridades.

ADD-PATH não manda enviar tudo nem garante resiliência. Ele impede que uma identidade baseada apenas no prefix destrua todas as alternativas da sessão. Só entrega valor quando o conjunto é deliberado, limitado, explicável e capaz de virar forwarding após a perda do caminho preferido.

Fontes