Resumo

  • BGP PIC faz muitos prefixos compartilharem objetos hierárquicos de next hop; diante de uma falha coberta, a mudança de poucos objetos substitui a reprogramação prefixo a prefixo.
  • A troca rápida depende de um caminho alternativo aprendido, escolhido e instalado antes do incidente. Uma segunda rota ou outro BGP next hop não provam sozinhos diversidade física, capacidade ou presença real na FIB.
  • A governança precisa cobrir toda a pré-autorização: visibilidade do candidato, elegibilidade, destino comum, detector, hierarquia de hardware, pacotes observados e retorno ao estado estável.

Às 2h14, um PE de ingresso perde sua saída preferencial. O BGP ainda processa rotas VPN, e os route reflectors ainda não distribuíram todo o novo estado. Mesmo assim, o tráfego de centenas de milhares de prefixos já sai por outro PE.

A pergunta mais comum é como a rede convergiu tão depressa. A pergunta importante é quem escolheu aquele caminho. Talvez a escolha não tenha ocorrido durante a falha: o roteador a havia feito horas antes.

O alternate já tinha chegado, sido aceito pela policy, resolvido até o next hop e associado a objetos compartilhados de encaminhamento. Quando o detector declarou a dependência primária inutilizável, o forwarding plane mudou poucos ponteiros. Não reescreveu cada destino.

Esse é o alcance exato de BGP Prefix Independent Convergence. O nome não diz que toda convergência deixou de depender da escala. Diz que uma etapa local — ativar um backup preparado após uma falha coberta — pode deixar de crescer com o número de prefixos BGP afetados.

Na data deste texto, a descrição central da IETF é draft-ietf-rtgwg-bgp-pic-23, um Internet-Draft ativo com status pretendido Informational. É trabalho em andamento, não RFC e não uma nova mensagem entre roteadores. Ele descreve uma arquitetura interna de FIB hierárquica, resolução recursiva e backups pré-calculados.

Numa FIB plana, cada prefix leaf pode guardar uma cópia dos detalhes de encaminhamento. Se 500 mil rotas resolvem pelo mesmo egress, sua mudança pode exigir 500 mil atualizações. Numa estrutura hierárquica, as folhas apontam para uma BGP pathlist comum, que aponta para um objeto IGP resolvido e, por fim, para adjacency, interface ou pilha de labels.

Alterar o ramo compartilhado muda todas as folhas dependentes. É a diferença entre reendereçar meio milhão de volumes e mover uma única chave na esteira pela qual todos passam. A segunda operação ainda custa tempo, mas não se repete para cada volume.

“Prefix independent” é uma afirmação de escala com fronteiras. A detecção demora. Um reflector pode ocultar a alternativa. O control plane continua retirando, escolhendo e anunciando. Roteadores remotos convergem separadamente. O caminho de volta pode falhar e o backup pode não ter capacidade. PIC retira o número de prefixos de uma fase local, não da crise inteira.

A velocidade é comprada com pré-cálculo. Enquanto o primário está saudável, o roteador protetor precisa de uma alternativa válida segundo a policy, alcançável, diferente no domínio de falha relevante e instalada na cadeia de hardware. A decisão emergencial é, em parte, uma decisão histórica.

Isso muda a auditoria. Uma escolha pós-falha permite observar UPDATE, atributos vencedores e entrada programada. PIC exige auditar uma intenção dormente. O backup pode ficar semanas sem tráfego e, ao ser acionado, depender de uma avaliação antiga de topologia, política e recursos.

Primeiro vem o fornecimento de candidatos. O draft cita ADD-PATH, best-external, distribuição de caminhos diversos e Route Distinguishers distintos em VPNs. São formas possíveis de entregar alternativas, não garantias equivalentes.

Route reflection pode eliminar a alternativa antes do PE. Uma capability ADD-PATH também não basta: direção send/receive, AFI/SAFI, policy de envio, quantidade de paths, import policy e Adj-RIB-In efetiva determinam o que existe no ponto de failover.

Depois vem a elegibilidade. A documentação atual do Nokia SR Linux descreve para Edge PIC um candidato válido, alcançável e com BGP next hop diferente do primário; o melhor é escolhido pelo processo normal do BGP. É uma regra coerente de implementação, não certificado de independência.

Dois next hops podem resolver pela mesma fibra, line card, tunnel, sala de energia ou provedor. Dois PEs podem depender do mesmo service node. Diferença lógica não impede shared fate físico.

A diversidade deve ser declarada por failure class. Outra interface pode proteger contra porta, mas não contra a perda da placa. Outro path no mesmo PE não protege contra a perda do PE. Duas sessões com o mesmo provedor podem compartilhar geografia e contrato.

Core PIC e Edge PIC localizam a camada de reparo. Core PIC muda o caminho interno até um BGP next hop que continua alcançável; o IGP ou transporte se move por baixo. Edge PIC usa outro BGP next hop pré-calculado quando o egress desaparece, podendo mudar label VPN, tunnel e service path.

Produtos não oferecem escopo uniforme. Família, serviço, software, ASIC e line card importam. O próprio draft observa que o benefício depende do desenho do forwarding plane, não de uma mudança no protocolo BGP.

O detector tem a chave de ativação. Estado físico, interface, adjacência IGP, sessão BGP e BFD observam falhas diferentes. A RFC 5880 define Detection Time do BFD separadamente em cada direção, conforme intervalos negociados e um multiplicador. Os dois sentidos podem ter valores diferentes.

Um painel “BFD 50 ms” pode esconder essa assimetria. Timers agressivos também trazem risco. Congestionamento, starvation do control plane, filtro ou ataque podem remover pacotes BFD legítimos. Falsos down e up podem gerar denial of service. Quanto menos observações ausentes autorizam a troca, maior o poder concedido ao detector.

O sinal deve cobrir a dependência correta. Carrier local vê rapidamente o corte direto, não um black hole remoto. Single-hop BFD mede uma adjacency, não o serviço inteiro. Multi-hop BFD alcança um endpoint, mas seu caminho precisa ser comparado ao tráfego protegido.

O IGP também pode ocultar falhas. Summarisation reduz detalhe entre áreas. A RFC 9929 define Unreachable Prefix Announcement porque um prefixo coberto por um summary pode ficar inacessível sem retirada do resumo, e cita usos como BGP PIC. A lição não é tornar UPA universal; é reconhecer que o ponto de decisão não repara o que não vê.

A hierarquia de hardware é outro limite. O draft pressupõe vários níveis de indirection. Plataformas limitadas podem flatten a cadeia ao programá-la, duplicando estado e reduzindo compartilhamento. Isso consome FIB e pode devolver trabalho por prefixo a certas falhas.

Assim, dois roteadores com a mesma RIB podem reagir de maneiras distintas. Um muda uma pathlist; outro reescreve muitas entries. A promessa deve ser medida por plataforma, placa, release, route family e encapsulation.

Em L3VPN, o alternate pode exigir outro VPN label e outra pilha LDP ou Segment Routing. Trocar o next hop mantendo um label obsoleto produz falha rápida. A prova precisa chegar à adjacency e à encapsulação emitida.

O estado pré-calculado envelhece. Mudanças de import, withdrawal, resolução, label, reachability parcial ou pressão de recursos podem torná-lo impróprio. O caso perigoso não é o backup ausente, mas o backup antigo ainda marcado como pronto.

Registre quando o candidato chegou, quando sua elegibilidade foi recalculada, quando a FIB foi programada e qual epoch de policy/topology justificou o estado. Mudanças relevantes devem revalidar a cadeia. Presença na RIB não prova atualidade.

Capacidade faz parte da autorização. Um caminho pode ser loop-free e alcançável, mas pequeno demais. Muitos primários compartilhando um standby podem concentrar carga enorme numa falha. Backups aceitáveis separadamente podem colidir em falhas simultâneas. Contratos de transit e peering também podem proibir um caminho tecnicamente elegível.

A RFC 5714 separa reparo local de convergência distribuída. Fast reroute mantém pacotes enquanto os protocolos propagam a falha e formam o estado final. O reparo é uma ponte, não necessariamente o destino.

Meça seis relógios: detecção, entrega do evento, ativação FIB, primeiro pacote bem-sucedido, convergência do control plane e FIB estável final. Um único número de “convergência” apaga responsabilidades e não demonstra entrega.

Sondas data plane devem registrar interface, next hop e labels antes, durante e depois. O retorno exige prova própria: firewall stateful, NAT e service chain podem perder sessões mesmo quando a ida muda corretamente.

A matriz de teste deve cortar link local, transporte remoto e egress PE; perder BGP; atrasar ou falsificar BFD; retirar o backup primeiro; mudar policy; pressionar FIB; reiniciar line card; e restaurar o primário. Cada caso deve nomear detector, objeto compartilhado, backup esperado, perda aceitável e estado final.

O false positive move rapidamente uma população enorme para um caminho inútil. O false negative deixa uma proteção fictícia porque o backup não entrou no hardware ou o trigger aponta para o objeto errado. O estado compartilhado é fonte de eficiência e multiplicador do erro.

Por isso, seleção e certificação devem ser separadas. Routing define elegibilidade; transporte prova diversidade física; plataforma mostra a FIB real; serviço valida capacidade e bidirecionalidade; um reviewer independente autoriza expansão.

O primeiro artefato é uma protection matrix por failure class, route family, plataforma e serviço, com primary dependency, candidate source, backup, diversity evidence, detector, timer, hardware object, capacidade e owner.

O segundo é um dormant-state ledger que distingue backup na RIB de backup no hardware. O terceiro é uma timed trace que liga o detector à mudança da pathlist e aos pacotes observados, incluindo a transição do reparo ao estado convergido.

Restaurar o primário também precisa de controle. Voltar imediatamente pode causar reordering, oscillation e nova perda. Hold-down, validação ou revert aprovado podem ser mais seguros. Rollback não é desligar PIC; é recuperar um estado estável demonstrado.

O princípio de minimum initial specification de Heng Lu se ajusta bem: manter estreito o mecanismo comum e deixar cada operador escolher famílias, plataformas, falhas e timers. Running-code primacy ordena a prova: configuração, RIB e FIB são afirmações; o pacote é o resultado.

Soberania prática significa consultar, testar, expirar e revogar a decisão pré-calculada dentro do hardware. Ter o repositório de configuração sem enxergar o backup dormente é controle simbólico.

BGP PIC retira trabalho da emergência. Para ser governável, precisa retirar para antes também a evidência. Origem, diversidade, trigger, realização física, capacidade e validade do backup devem ser conhecidos antes do alarme.

Fontes