Resumo

  • A RFC 9514 leva pelo BGP-LS informações de nós, enlaces, Locators e SIDs SRv6 para consumidores como motores de cálculo de caminhos.
  • Um Prefix NLRI com o SRv6 Locator TLV 1162 é apenas uma declaração de Locator se não vier também com o Prefix Metric TLV 1155; a Errata 7737 corrige a referência equivocada ao TLV 1095 no texto publicado.
  • Uma operação auditável registra separadamente o anúncio, a classificação de alcançabilidade, a associação de SIDs, o cálculo, a instalação e o resultado observado em pacotes.

Há um tipo de incidente que começa sem alarme algum. A sessão BGP-LS está ativa. O consumidor recebeu um Prefix NLRI válido. O objeto contém o SRv6 Locator TLV 1162, um algoritmo e uma métrica. O inventário mostra o Locator, e o mecanismo de cálculo consegue associá-lo ao nó de origem. Tudo parece verde.

Mas o painel respondeu a uma pergunta menor do que aquela que o operador imagina. Ele provou que o Locator foi anunciado; ainda não provou que o prefixo foi anunciado como alcançabilidade comum.

A RFC 9514 estabelece uma fronteira objetiva. O Locator é transportado em um Prefix NLRI com o SRv6 Locator TLV. Esse mesmo NLRI só representa também alcançabilidade de prefixo quando está associado ao Prefix Metric TLV aplicável. Sem esse segundo campo, continua sendo uma declaração de Locator — útil para organizar o espaço em que o nó provisiona SIDs, mas não equivalente a uma rota.

A métrica que não pode herdar o significado de outra

O texto publicado aponta para o IGP Metric TLV 1095. O registro de erratas verificado corrige a referência para o Prefix Metric TLV 1155. A razão acompanha o modelo de objetos: 1095 está associado a Link NLRI; o Locator está associado a Prefix NLRI.

Isso importa porque o próprio Locator TLV já contém um campo Metric, copiado do anúncio de Locator do IS-IS ou do OSPFv3. É tentador concluir que uma métrica qualquer satisfaz a condição. Não satisfaz. A métrica interna descreve a declaração do Locator. O TLV 1155 é a evidência separada que permite classificar o prefixo também como alcançabilidade comum. Campos de nomes parecidos não recebem, por proximidade, o mesmo direito de decisão.

Para uma auditoria, a diferença deve aparecer como estado, não como nota de rodapé. Locator presente / 1155 ausente e Locator presente / 1155 presente são objetos operacionais distintos. Um consumidor que siga o número errado pode consultar a classe errada, aceitar a métrica interna como substituta ou divergir de outro consumidor atualizado — mesmo quando ambos decodificam o BGP sem erro.

O grafo exportado tem ciclos de vida independentes

A RFC 9514 não se limita ao Locator. Ela distribui dados SRv6 por superfícies de nó, enlace, prefixo e SID. Capacidades, algoritmos e tipos de Maximum SID Depth aparecem no nó. End.X, LAN End.X e limites específicos do enlace aparecem no enlace. Locators aparecem no prefixo. Cada SID de nó recebe um SRv6 SID NLRI tipo 6 com descritores próprios.

Separar cada SID evita que uma única alteração obrigue o produtor a republicar um grande atributo de nó. A vantagem de escala cria, porém, uma obrigação de reconciliação: o consumidor precisa unir SID, nó, Protocol-ID, identificador de topologia, comportamento de endpoint e época do Locator. Se um SID for retirado, a permanência dos objetos vizinhos não o mantém vivo por inferência.

Todo SID NLRI exige o Endpoint Behavior TLV. SIDs EPE PeerNode ou PeerSet carregam contexto de par, e o SID Structure TLV opcional pode registrar os comprimentos de bloco do Locator, nó, função e argumento. A RFC 8986 define os comportamentos de endpoint; a RFC 8402 fornece a arquitetura de Segment Routing. Ainda assim, um código de comportamento é uma instrução declarada, não uma observação de que um equipamento a executou.

A proveniência também não é uniforme. A RFC 9514 copia campos das extensões SRv6 de OSPFv3 ou IS-IS. Em BGP EPE ou com o Direct Protocol-ID, o nó local fornece a informação em seu próprio nome. A RFC 8814 define o transporte BGP-LS dos limites MSD. Reunir essas fontes em um banco de topologia não as transforma em uma única observação onisciente.

O envelope chega pelo BGP; o significado fica com o consumidor

A própria RFC deixa a verificação semântica e de conteúdo, inclusive a associação correta entre TLV, NLRI e BGP-LS Attribute, sob responsabilidade do consumidor. BGP valida o envelope e a sintaxe. Não certifica que um Locator devia ser tratado como rota, que o SID continua instalado, que a política permite determinado algoritmo ou que o caminho calculado corresponde à rede em execução.

O modelo-base atual do BGP-LS, a RFC 9552, ajuda a distribuir responsabilidade entre produtor, propagador e consumidor. O produtor deriva uma projeção; o propagador seleciona e transporta; o consumidor reúne e usa. Um update válido é um recibo de trânsito entre componentes, não um recibo de interpretação correta.

Por isso, o registro operacional deve reter produtor, protocolo-fonte, Protocol-ID, Identifier, descritores do nó local e época da topologia. Deve guardar o Prefix NLRI exato, o Locator TLV 1162, algoritmo e métrica do Locator. Em campo separado, registra se o Prefix Metric TLV 1155 estava presente, ausente, duplicado ou rejeitado e qual regra, já corrigida pela errata, foi aplicada.

Quando houver SID, entram no mesmo encadeamento o SID NLRI, o Information TLV 518, o Endpoint Behavior TLV 1250, o contexto de par aplicável, a estrutura opcional e o histórico de retirada. Depois vêm recibos diferentes: fotografia do consumidor e restrições usadas no cálculo; política e conjunto de candidatos; aceitação no dispositivo; instalação em RIB, FIB ou política SR; teste controlado de pacotes; resultado de serviço.

Ler o padrão junto com seu histórico de correção

O conjunto oficial permite conferir tanto a norma quanto sua reparação. O RFC Editor mantém a ficha informativa, o texto simples e o XML. O Datatracker preserva o histórico da RFC, a revisão final do Internet-Draft e o grafo de referências. O registro BGP-LS da IANA mantém os pontos de código. Esse material prova o vocabulário comum e a leitura corrigida; não prova o resultado de uma implantação específica.

Três ensaios declarados de Heng Lu orientam a leitura editorial: a primazia do código em execução, a especificação inicial mínima e a adoção voluntária e as camadas da realidade. Eles não são requisitos do IETF. Servem aqui para uma disciplina precisa: o símbolo do padrão, o modelo do controlador, o estado instalado e o pacote observado não podem representar um ao outro sem recibos intermediários.