Resumo

  • A RFC 9830 define como o BGP transporta candidatos de SR Policy, mas quem valida seu significado, escolhe o candidato ativo e instala estado é o SRPM do headend.
  • O Distinguisher evita que anúncios diferentes se confundam no BGP, porém não expressa prioridade, versão, confiança nem autorização.
  • Uma cadeia de evidências defensável separa recepção, melhor rota BGP, importação por Route Target, elegibilidade no SRPM, seleção ativa, Binding SID, instalação na FIB e comportamento dos pacotes.

Duas eleições acontecem no mesmo equipamento

O caso inicial é deliberadamente genérico. Não descreve um fornecedor ou uma rede real; serve para localizar uma fronteira que interfaces de operação costumam esconder. Um UPDATE bem formado pode ser aceito, armazenado e eleito como melhor rota para um NLRI. Cada evento é verificável. Nenhum deles responde, sozinho, qual lista de segmentos está conduzindo pacotes.

A RFC 9830 separa os papéis. O BGP origina e propaga informações de candidate path. No headend, essas informações são entregues ao Segment Routing Policy Module, o SRPM. Esse módulo também pode conhecer candidatos por CLI, NETCONF, PCEP ou configuração local. Ele aplica as regras da arquitetura de SR Policy, verifica os componentes, compara as alternativas, escolhe um candidato ativo, trata o Binding SID e solicita a instalação no plano de dados.

Há, portanto, duas eleições. O processo BGP escolhe a melhor rota de um NLRI segundo atributos e políticas BGP. O SRPM escolhe o candidato ativo de uma política identificada por Color e Endpoint. Um candidato pode vencer a primeira eleição e perder a segunda para uma configuração local mais preferida. Também pode chegar ao SRPM e ser considerado semanticamente inválido. A interface que apresenta ambas como um único selo “ativo” elimina justamente a explicação de que o operador precisará durante uma falha.

A própria norma observa que o BGP não instala o candidate path de SR Policy no plano de dados. Essa frase deve ser tratada como requisito de observabilidade: presença na tabela BGP é recibo de transporte, não recibo de encaminhamento.

O Distinguisher dá separação, não significado

O NLRI de SR Policy reúne Distinguisher, Color e Endpoint. Color e Endpoint formam a identidade da política. O Distinguisher permite que o originador mantenha anúncios distintos para vários candidatos da mesma política ou para diferentes headends sem submetê-los, por acidente, à mesma competição de rota.

O documento é explícito: o Distinguisher não tem valor semântico. Um número maior não significa candidato mais novo ou mais importante. Estabilidade do número não prova continuidade da intenção. Ele não identifica o serviço, o aprovador ou a justificativa da mudança. Sua autoridade termina na distinção entre NLRIs.

Essa limitação impede um erro comum em inventários. Sistemas de gestão tendem a promover a chave mais conveniente a identificador universal. Aqui, ao menos cinco identidades convivem: o Distinguisher separa o anúncio; Color–Endpoint identifica a política; Protocol-Origin e Discriminator identificam a origem do candidato dentro do SRPM; informações de originator remontam à fonte do protocolo; o registro de mudança documenta a autoridade humana. Trocar uma pela outra produz correlações fáceis e conclusões falsas.

O receptor reconstrói a origem BGP por uma ordem definida que pode usar Route Origin Community, ORIGINATOR_ID ou o Router ID do vizinho. Isso ajuda quando um route reflector está entre o controlador e o headend. Ainda assim, um originator de protocolo não é uma identidade empresarial, e muito menos prova que uma pessoa autorizou redirecionar um serviço.

Nomes simbólicos também têm alcance limitado. Policy Name e Candidate Path Name facilitam leitura humana, mas são opcionais e podem ser truncados durante a sinalização. Uma junção baseada somente no nome pode misturar políticas homônimas ou inventar outra política quando alguém renomeia a existente.

O BGP verifica o envelope; o SRPM, a proposta

A fronteira não significa que o BGP aceite qualquer coisa. A RFC define SAFI 73, famílias de endereço permitidas, tamanho do NLRI e o formato do Tunnel Encapsulation Attribute. O tipo de túnel de SR Policy é 15. Tipo incorreto, TLV proibido ou estrutura obrigatória malformada podem tornar o anúncio inutilizável e acionar o tratamento treat-as-withdraw.

Essa resposta isola o erro sem derrubar toda a sessão. Ela protege disponibilidade, mas não certifica a semântica do que sobreviveu. A RFC manda que o BGP não faça a verificação semântica de cada campo da SR Policy e não descarte o UPDATE apenas por esse julgamento. A decisão cabe ao SRPM.

Por isso o vocabulário de incidentes precisa preservar o estágio: “retirado por erro estrutural BGP”, “sub-TLV ignorado”, “não importado neste headend”, “rejeitado semanticamente pelo SRPM”, “elegível, mas não selecionado” e “selecionado, mas ausente da FIB” apontam para responsáveis e correções diferentes. Chamá-los todos de “política inválida” destrói a localização da falha.

As regras de extensibilidade complicam ainda mais a reconstrução. Bits reservados são enviados zerados e ignorados na recepção; campos desconhecidos ou inaplicáveis podem ser ignorados e removidos; em alguns sub-TLVs de ocorrência única, apenas a primeira instância conta. Portanto, o que o controlador originou, o que o reflector propagou e o que o SRPM recebeu podem ser conjuntos diferentes. A evidência deve guardar um hash em cada fronteira, não somente a representação final.

Preference, Priority e Weight não disputam a mesma coisa

Os nomes parecem familiares e convidam à simplificação errada. Preference participa da escolha de candidate path pelo SRPM; não participa da seleção de melhor rota do BGP. Priority ordena a recomputação de políticas depois de uma mudança de topologia; não é a preferência de uma rota. Weight distribui tráfego entre listas de segmentos válidas dentro do candidato selecionado; não prova que a lista chegou à FIB nem que os pacotes seguiram a proporção.

Se um produto reduz os três campos a “prioridade”, não consegue explicar o efeito de uma alteração. Mudar Preference pode trocar o candidato ativo sem qualquer mudança na melhor rota BGP. Mudar Priority pode alterar somente a ordem de reação a uma falha. Mudar Weight pode redistribuir tráfego sem trocar candidato. O sujeito e o resultado de cada decisão precisam aparecer no registro.

O Binding SID preserva outra parcela de autoridade local. Conforme os flags e o plano de dados, o headend pode validar, alocar, aceitar ou rejeitar o valor recebido. Certos comportamentos SRv6 podem ser deixados opacos para escolha local. Traffic Class, TTL e comportamento de Explicit NULL também admitem decisões locais em condições descritas pela norma.

Assim, o anúncio não é uma ordem acabada. Ele contém propostas com graus diferentes de força. O log deve dizer quais valores foram recebidos, quais foram aceitos, quais foram substituídos por política local, o que foi selecionado e o que foi instalado.

Destinatário pretendido não é política ativa

Em uma topologia pequena, o controlador pode anunciar diretamente ao headend. Em uma implantação maior, route reflectors ou múltiplos sistemas autônomos dentro de um domínio SR confiável distribuem a informação. Route Targets identificam os headends pretendidos.

A importação por Route Target é uma decisão de audiência. Ela indica que a política local considerou aquele anúncio destinado a uma função receptora. Não prova elegibilidade semântica, vitória sobre PCEP ou configuração, obtenção de Binding SID ou instalação no hardware. Um Route Target ausente impede que um candidato correto chegue ao módulo adequado. Um Route Target amplo demais revela a política a roteadores que não deveriam conhecê-la.

O risco inclui confidencialidade. Um anúncio pode expor endpoints, endereços de nós, SIDs e desenho comercialmente sensível de caminhos. Uma sessão BGP configurada não autoriza, por si só, todas as famílias e todos os destinatários. Domínio SR aprovado, papel do peer, SAFI, Route Targets e política de exportação precisam formar um registro explícito de divulgação.

Reflexão de rotas não deve apagar essa distinção. O vizinho imediato pode ser um reflector; o originator pode ser o controlador; o aprovador pode estar em outro sistema organizacional. “Recebido de”, “originado por” e “autorizado por” são três afirmações.

Retirar uma fonte não determina o resultado

Quando uma rota BGP de SR Policy é retirada, apenas uma contribuição de origem desaparece. O SRPM pode conservar outro candidato BGP com Distinguisher diferente, um candidato PCEP, uma configuração manual ou um backup válido. A política ativa pode não mudar, trocar de candidato, ficar inválida ou desaparecer. O withdraw não escolhe o desfecho.

O inverso também ocorre. Uma nova melhor rota BGP pode ser entregue ao SRPM sem alterar o encaminhamento. Sua Preference pode perder; um segmento pode não ser verificável; o Binding SID pode conflitar; uma política local pode barrá-la. Contar UPDATEs não equivale a contar mudanças de tráfego.

A prova de efeito precisa encadear: UPDATE bruto e seu hash; resultado estrutural; melhor rota por NLRI; decisão de importação; origem reconstruída; validação semântica; conjunto completo de candidatos; decisão de ativo; estado do Binding SID; listas e pesos instalados; leitura da RIB/FIB; e pacotes observados no caminho esperado. Tempo, equipamento, versão de software e código de razão acompanham cada elo.

A especificação mínima preserva a autoridade local

A RFC 9830 padroniza uma superfície de interoperabilidade exigente: família de endereço, NLRI, atributos, campos de candidatos, propagação e tratamento de erros. Esse mínimo comum permite que implementações independentes troquem propostas. Ele não precisa confiscar decisões locais para ser útil.

É a aplicação prática do princípio de especificação inicial mínima de Heng Lu. A linguagem compartilhada encerra a ambiguidade de transporte. O SRPM local mantém o julgamento que produz consequências locais. A primazia do código em execução exige leitura do headend e do plano de dados, não confiança derivada do rótulo Standards Track. A disciplina das camadas de realidade impede que proposta, estado selecionado e comportamento do pacote virem a mesma afirmação.

Um teste revelador usa dois candidatos BGP para um Color–Endpoint, com Distinguishers distintos, e um terceiro candidato de maior Preference via PCEP ou configuração local. Registre o que o BGP conserva, o que o SRPM considera elegível, qual candidato ativa, qual Binding SID entra na FIB e por onde passam os pacotes. Depois retire cada fonte separadamente. Se o sistema chamar todas as transições de “estado BGP”, perdeu a fronteira de autoridade que a RFC preservou.

Fontes