Resumo

  • Em 25 de agosto de 2026, o IESG aprovou draft-ietf-idr-sr-policy-seglist-id-14 como Proposed Standard. No corte da apuração, o texto ainda era um Internet-Draft ativo na fila do RFC Editor, e a IANA mostrava o valor 19 como alocação temporária.
  • O Segment List ID de 32 bits é único apenas dentro de um Candidate Path. A sequência ordenada pode mudar sem troca do ID. Uma afirmação operacional precisa ligar escopo, conteúdo vigente, UPDATE recebido, validação do SRPM, programação e tráfego.

A continuidade existia apenas no painel

Antes de uma manutenção, um controlador chama de 42 uma lista com três instruções. A configuração NETCONF e as séries de telemetria usam o mesmo número. Durante a mudança, a sequência de SIDs é substituída, mas 42 permanece. O painel continua verde.

O exemplo é analítico, não um incidente atribuído. Ele mostra que o número é uma referência, não a identidade imutável do caminho. Uma base indexada apenas por 42 perde o Candidate Path; uma base com Path e ID, mas sem horário ou impressão do conteúdo, mistura revisões diferentes.

A decisão ainda percorre a cadeia editorial

O anúncio de 25 de agosto aprovou a revisão 14, produzida pelo grupo Inter-Domain Routing. Em 28 de agosto, o Datatracker ainda indicava Active Internet-Draft, RFC Ed Queue e espera por conferência de referências e formatação. A ação da IANA seguia em curso após mudança de versão; o texto, datado de 24 de agosto, expira em 25 de fevereiro de 2027.

No registro público, o valor 19 ainda era temporário, registrado em 19 de dezembro de 2025, com vencimento um ano depois e referência a versão anterior. Aprovação, RFC numerado, registro permanente e implantação são fatos separados.

Um inteiro resolve uma correlação cara

Uma SR Policy pode ter vários Candidate Paths, cada um com várias listas. O RFC 9830 define o transporte por BGP até o headend. Sem um ID curto, estatísticas podem repetir a sequência inteira, exigindo comparação SID a SID. Referências YANG/NETCONF a listas aprendidas por BGP enfrentam o mesmo custo.

O sub-TLV opcional fica no Segment List tipo 128, sob o SR Policy Tunnel Type 15. Seu tipo é 19, o comprimento é seis octetos e quatro octetos carregam o inteiro. Valores de 1 a 0xffffffff são IDs; zero significa sem ID.

Um ID não nulo só precisa ser único entre listas de um Candidate Path. Pode reaparecer em outro Path, Policy ou headend. E pode sobreviver a uma alteração dos SIDs. Para auditoria, o registro deve unir NLRI — Distinguisher, Color e Endpoint —, Candidate Path, ID, sequência ordenada e revisão, horário ou hash do conteúdo.

O identificador do RFC 9857 em BGP-LS e as referências de gestão têm semântica próxima, mas não criam um namespace universal. Todo consumidor preserva escopo, tipo e atualidade.

Falhas parecidas produzem efeitos diferentes

Comprimento diferente de seis torna o NLRI malformado e aciona treat-as-withdraw do RFC 7606. Múltiplas instâncias na mesma lista levam o receptor a usar a primeira. IDs não nulos repetidos entre listas do mesmo Candidate Path são erro semântico tratado pelo SRPM, que pode remover todas as associações.

Em uma frota mista, um headend sem suporte pode considerar o Candidate Path inutilizável segundo o comportamento padrão do RFC 9830. A recomendação é anunciar seletivamente aos nós compatíveis. “Opcional” no formato não significa neutro na operação.

BGP transporta a descrição; SRPM valida; seleção ativa, programação e passagem de pacotes vêm depois. A evidência deve separar estado documental e IANA, capacidade por vizinho, UPDATE recebido, vínculo Path–ID–conteúdo, validação, seleção, forwarding, contadores da mesma revisão e resultado do tráfego.

O texto também alerta que IDs podem revelar informação sensível. Alocação entre controladores, colisões, reutilização, retenção e rollback ficam fora do padrão. As declarações de H3C e ZTE são autorrelatadas, baseadas na revisão 3 e atualizadas em fevereiro de 2025; não são endosso do IETF nem verificação independente.

Fontes