Resumo

  • O IETF publicou às 09:22:08 UTC de 19 de agosto a revisão 38 da proposta de recuperação de topologia inter-AS por BGP-LS. A única alteração substantiva em relação à revisão 37 remove Multi-Topology Identifier, TLV 263, da lista de descritores do Inter-AS Link NLRI.
  • MT-ID continua existindo no BGP-LS. O que mudou foi a identidade proposta para o novo objeto, tornando retirada limpa, ausência de duplicatas e isolamento de topologias os próximos testes relevantes.

Um controlador reconstrói uma rede a partir de identidades. Se dois anúncios usam conjuntos diferentes de campos para representar o mesmo meio-link, ele precisa decidir se recebeu uma atualização, um segundo objeto ou uma ligação que pertence a outra topologia.

O histórico do Datatracker registra a revisão 38 como disponível em 19 de agosto, às 09:22:08 UTC. Uma comparação estrutural das fontes oficiais das revisões 38 e 37 encontra apenas uma mudança técnica: a linha do TLV 263 saiu da lista de descritores adicionais.

A proposta tenta fechar uma lacuna entre domínios IGP. O BGP-LS do RFC 9552 permite que cada domínio envie sua topologia a um consumidor, como uma aplicação SDN. Quando uma mesma operadora administra vários domínios e ASes, o controlador pode conhecer cada mapa interno sem receber os links que os conectam.

Para representar essa passagem, o texto define o tipo NLRI 7 para o Inter-AS Link e três TLVs: número do AS remoto, identificador IPv4 do roteador de borda remoto e seu equivalente IPv6. Cada lado anuncia uma representação unidirecional. O consumidor pareia os dois half-links, junta as topologias e, no caso de uso descrito, calcula um caminho de ponta a ponta.

Na revisão 37, a lista incluía identificadores local e remoto do link, endereços de interface e vizinho em IPv4, os equivalentes em IPv6 e MT-ID. A revisão 38 encerra a lista no endereço IPv6 do vizinho. O alerta que vem em seguida continua: outros TLVs usados como descritores podem dificultar a correlação das duas metades quando implementações produtoras divergem.

Isso não equivale a retirar MT-ID do protocolo. O RFC 9552 ainda define o tipo 263 como Multi-Topology Identifier. No Link NLRI comum, o campo é obrigatório quando o link IGP pertence a uma topologia não padrão, e cada identificador de topologia exige um NLRI próprio. A seção de segurança da revisão 38 também continua tratando MT-ID como informação crítica da rede.

O ponto exato é a identidade proposta do novo Inter-AS Link NLRI. Um produtor baseado na revisão 37 pode usar o TLV 263 como parte dessa chave; outro, atualizado para a revisão 38, pode deixá-lo de fora. Um consumidor pode manter duas identidades para a mesma metade. Outra implementação pode fundi-las e apagar uma distinção legítima entre topologias.

O procedimento de transição já tem uma regra no RFC 9552. Ao adicionar, remover ou alterar um TLV de um Link-State NLRI, o produtor deve retirar o NLRI anterior. Sem isso, objetos duplicados e inconsistentes podem permanecer na tabela BGP-LS. Essa possibilidade orienta o teste; as fontes observadas não relatam um incidente em produção.

O registro de parâmetros BGP-LS da IANA também mostra uma etapa pendente. Consultado em 19 de agosto, ele informava 7 de agosto como a última atualização, ainda chamava o tipo 7 de Stub Link NLRI e apontava para a revisão 17. O texto 38 o chama de Inter-AS Link NLRI. Os TLVs 270–272 já aparecem com os nomes do AS e do ASBR remotos, mas a referência continua na revisão 17.

A página do documento coloca esse descompasso dentro do processo. O projeto pretende chegar a Proposed Standard, foi enviado ao IESG e está em AD Followup. A revisão da IANA voltou a Version Changed - Review Needed; os pareceres de especialistas aparecem como concluídos. Ainda não há RFC, matriz de suporte de fabricantes nem resultado público de interoperabilidade.

Há também um limite de divulgação. O caso de uso considera vários ASes sob uma única entidade e chama endereços, identificadores de links, ASes e topologias de informação crítica. O texto recomenda mantê-los nesse ambiente fechado ou filtrá-los antes de sair. A visão que melhora a automação também descreve com mais precisão a estrutura que precisa ser protegida.

Para uma equipe de rede, a revisão 38 vira uma lista de aceitação: o objeto da revisão 37 desaparece, apenas a nova identidade permanece, as duas metades formam o link certo, topologias não padrão não se misturam e os dados não cruzam o limite administrativo previsto. Antes disso, existe uma especificação revisada, não uma capacidade operacional comprovada.

Fontes