Resumo

  • A extensão aprovada pelo IESG permite que um caminho candidato de BGP SR Policy carregue o NRP ID associado à sua Network Resource Partition pretendida.
  • O número declara uma associação dentro do domínio; não aloca recursos, não prova o seletor instalado e não garante capacidade, isolamento ou resultado do serviço.

O anúncio identifica; a infraestrutura executa

Considere dois caminhos candidatos com a mesma cor e o mesmo endpoint. Um traz NRP ID 17 e o outro, 29. A distinção é suficiente para o plano de controle dizer que cada caminho pertence a uma partição de recursos diferente.

O anúncio não transporta o estado das filas, a disponibilidade dos enlaces, a configuração das interfaces nem uma medição de isolamento. Também não confirma que o headend escolheu o candidato, instalou a lista de segmentos, converteu o ID no seletor esperado e encaminhou o serviço por aquela infraestrutura.

O cenário é ilustrativo, não um incidente noticiado. Ele delimita o que o campo pode autorizar: comunicar a associação pretendida. Todas as transições que transformam essa intenção em comportamento permanecem externas ao campo.

Em 25 de agosto de 2026, às 18h03 UTC, a IETF anunciou que o IESG aprovou a revisão 13 de “BGP SR Policy Extensions for Network Resource Partition” como Proposed Standard. A aprovação é uma notícia de governança técnica, mas não encerra a publicação nem comprova uso em produção.

A fila editorial do padrão ainda importa

O documento foi produzido pelo grupo Inter-Domain Routing. O anúncio relata discussão sobre dependências dos trabalhos TEAS e SPRING, consenso aproximado para avançar e a decisão de resolver referências normativas na fila do RFC Editor.

No congelamento de evidências de 28 de agosto, o Datatracker ainda apresentava a revisão como Active Internet-Draft. O RFC Editor registrava bloqueio por referência não recebida. A revisão da IANA indicava que a versão havia mudado e precisava de nova análise; a ação continuava em andamento. Portanto, não há base para atribuir um número final de RFC ou declarar concluídos os registros.

O anúncio menciona duas implementações. O relatório público do IDR aponta superfícies Huawei VRP e H3C Comware, mas contém linguagem referente a versão anterior e linhas de recursos ainda marcadas TBD. Isso sustenta a viabilidade e a existência de trabalho de engenharia, não conformidade completa com a revisão 13, interoperabilidade ampla ou ativação em serviço.

O identificador não contém a partição

O RFC 9543 define uma Network Resource Partition como um subconjunto de recursos do underlay com políticas associadas, capaz de apoiar um ou mais serviços de network slice. O RFC 9732 posiciona essa construção no modelo de VPN aprimorada e mostra que a conectividade pode ser mapeada aos recursos.

Capacidade, tratamento de encaminhamento, política de uso, steering e medição são elementos separados. Operadores precisam provisioná-los e relacioná-los. Um número no plano de controle não substitui nenhum deles.

Na revisão 13, o NRP ID é um identificador de 32 bits, único dentro de um domínio NRP. A configuração e a implementação locais vinculam esse nome ao NRP Selector ID do plano de dados. Ele não é global e não constitui uma reivindicação de recursos.

O escopo também é preciso: a extensão trata do desenho com seletor dedicado e válido em todo o domínio, carregado no plano de dados. Outros métodos de selecionar uma NRP podem dispensar a sinalização explícita no SR Policy e ficam fora do documento.

Seis octetos estabelecem uma regra de fio

O novo NRP ID sub-TLV fica dentro do BGP Tunnel Encapsulation Attribute quando o tipo de túnel é SR Policy. Na revisão 13, seu tipo é 123 e o comprimento obrigatório é de seis octetos: um de flags, um reservado e quatro do ID.

Flags e bits reservados saem zerados e são ignorados na recepção. O valor zero do NRP ID é reservado, não deve ser enviado e leva o receptor a ignorar o sub-TLV. O elemento é opcional, mas não pode aparecer mais de uma vez em um caminho candidato.

Comprimento diferente de seis ou duplicação torna malformada a informação NRP associada ao NLRI. O receptor aplica o treat-as-withdraw do RFC 7606. Essa regra evita que codificações conflitantes obtenham lugar no estado de roteamento.

Ela não verifica a semântica local. Um ID não zero pode estar perfeitamente codificado e ainda apontar para o seletor errado. Protocolo válido e recurso correto são conclusões diferentes.

A melhor rota entra em outra cadeia de decisão

Quando o caminho candidato é instanciado em uma NRP que usa o seletor dedicado, o originador deve incluir o sub-TLV. O receptor aplica as regras de validade e usabilidade do RFC 9830. O algoritmo comum de melhor rota BGP permanece o mesmo.

As melhores rotas selecionadas para a SAFI de SR Policy seguem então para o SR Policy Module. Esse repasse não é o fim: uma rota aceita pode não virar candidata ativa; o SRPM pode receber e não instalar; uma instalação pode aplicar seletor errado se o mapeamento local estiver defasado.

A cadeia probatória precisa unir seleção do candidato, lista de segmentos instalada, versão do mapeamento entre NRP ID e seletor, inserção no pacote, steering do serviço, filas e enlaces provisionados e resultados medidos. Uma confirmação do controlador mostra somente que uma associação foi anunciada e aceita sob condições conhecidas.

Candidatos consistentes evitam um failover semântico

A revisão 13 permite associar candidatos da mesma SR Policy a NRPs diferentes, mas classifica a configuração como válida e não recomendada. Em cenários normais, todos deveriam preservar a mesma associação.

Uma falha ou alteração de preferência pode ativar outro caminho sem mudar a chave de política observada pelo serviço. Se o novo candidato escolher outra partição, o failover também muda isolamento, capacidade, custo ou exposição de intenção sensível.

A repetição do mesmo inteiro também não basta. Headends precisam concordar sobre seu significado, o plano de dados precisa usar o mesmo seletor e o underlay precisa ter os recursos correspondentes. Um número uniforme com mapas divergentes é apenas sintaxe coordenada.

O crescimento de estado tem localização definida

O rascunho diz que mais NRPs podem produzir mais SR Policies e caminhos candidatos, aumentando proporcionalmente as informações trocadas entre controlador e headends.

O procedimento de anúncio e o melhor caminho BGP não mudam. Os headends correspondentes instalam os candidatos, portanto o acréscimo não replica o mesmo estado nos nós de trânsito. É uma limitação relevante, não uma promessa de custo nulo.

Controladores ainda criam e conciliam estado; headends recebem, validam, repassam e instalam. Métricas devem separar quantidades anunciadas, válidas, selecionadas, ativas e instaladas para que um painel verde não oculte pressão no headend.

Confiança de sessão não valida o significado

A seção de segurança herda as proteções de BGP, SR Policy e NRP e explicita o dano de uma associação errada: isolamento de tráfego e garantias de recursos podem ser afetados.

Um controlador confiável pode enviar o ID errado. Um headend confiável pode mapear o ID correto para outro seletor. Um seletor correto pode encontrar uma configuração de recursos antiga. A autenticação dos componentes não autentica o resultado combinado.

Anunciar a associação também pode revelar intenção sensível, como uma estrutura reservada a missão crítica ou interesse comercial. Cabe ao operador limitar remetentes e destinatários a roteadores e aplicações de controle confiáveis e verificar a correção da associação.

Para cada episódio, preserve identidade e versão do controlador, peer e sessão BGP, chave NLRI, origem e preferência do candidato, bytes do sub-TLV, decisões de validação e melhor rota, recepção e seleção no SRPM, lista de segmentos, mapeamento e versão, configuração de recursos, steering, seletor observado no pacote, fila, perda, latência e isolamento, retirada, fallback, rollback e os horários que unem tudo.

Fontes