Resumo

  • A IETF publicou em 5 de setembro de 2026 a revisão 18 de Traffic Steering using BGP FlowSpec with SR Policy. No fechamento da pesquisa, ela continuava como Internet-Draft em AD Evaluation::External Party, e não como RFC aprovada.
  • A revisão 17 determinava o retorno ao Redirect-to-IP comum quando havia alvo de redirecionamento, mas faltava um Color válido. A 18 proíbe esse retorno quando há intenção SR incompleta e manda descartar o tráfego ou aplicar uma política local de falha.
  • Uma rota FlowSpec válida permanece na Loc-RIB e pode continuar sendo anunciada mesmo se a SR Policy estiver Down, não puder ser resolvida ou não entrar na FIB/TCAM. O estado do plano de controle não prova a ação sobre os pacotes.
  • O próprio texto diz que um headend sem suporte à extensão pode ignorar Prefix-SID e executar Redirect-to-IP. Em uma frota mista, a mesma atualização pode gerar descarte num equipamento e redirecionamento em outro.
  • O Working Group Last Call anterior cobriu a revisão 13. Depois da 17, o Area Director pediu aos chairs de IDR uma nova consulta de consenso. O resultado deve indicar a revisão e os ramos de falha que realmente foram aceitos.

A lacuna deixou de autorizar o caminho mais fácil

FlowSpec usa BGP para distribuir critérios de seleção de pacotes e ações. A proposta liga essas regras a Segment Routing. O endereço de Redirect-to-IP e uma Color Extended Community formam a tupla (Endpoint, Color) que seleciona uma SR Policy. No segundo modo, específico para SRv6, um atributo BGP Prefix-SID pode carregar o SID de serviço que será executado no egresso.

Isso cria três mensagens parecidas. Redirect-to-IP sozinho, sem sinal SR, continua sendo redirecionamento IP comum. Alvo e Color válido pedem steering por SR Policy. Alvo e Prefix-SID sem Color válido revelam uma tentativa de SR sem a chave que identifica a policy.

A revisão 17 resolvia o último caso ignorando o Prefix-SID e voltando ao redirecionamento normal. A 18 prefere não adivinhar. Um headend compatível não pode buscar policy padrão ou de “cor nula”, não pode usar o atributo de serviço e não pode tratar a mensagem como simples Redirect-to-IP. Os pacotes correspondentes são descartados ou entram na política local de falha.

O alcance é menor do que uma regra “sem Color, descarte”. O redirecionamento puro continua válido. A proibição vale quando a própria combinação de atributos já anuncia uma intenção SR incompleta. Em vez de entregar o tráfego por um caminho não autorizado e chamar isso de sucesso, a nova versão torna a falha visível — possivelmente como interrupção.

A rota sobrevive à ação

Se a SR Policy está indisponível, não pode ser resolvida ou falha na programação de forwarding, a revisão 18 conserva a rota FlowSpec na Loc-RIB, desde que ela passe pela validação BGP. O anúncio também continua rumo aos peers. Uma falha de underlay ou de policy não transforma a mensagem em rota inválida.

No plano de dados, a entrada de steering deve permanecer desativada ou ser marcada como Down. O mesmo vale para uma policy ativa cujo SID de serviço de egresso esteja inalcançável no RIB/FIB local. O headend não pode cair silenciosamente no caminho IP mais curto. Descarte é a ação local recomendada por padrão, sem eliminar a autoridade do operador para definir outra resposta. Ações não relacionadas ao steering, como limitação de taxa, continuam válidas.

Essa dissociação ajuda a recuperação, mas impede usar “rota presente” como comprovante de serviço. O registro precisa mostrar separadamente aceitação na Loc-RIB, propagação, instalação na FIB e resultado de um pacote testemunha.

O novo texto pede notificação, causa de falha e contadores de bytes ou pacotes descartados. Durante uma enxurrada de erros ou exaustão de recursos, logs individuais podem ser limitados, agregados ou suprimidos para preservar o controle. Por isso, silêncio não significa ausência de descarte. O estado da supressão e o total agregado precisam acompanhar o número de alarmes.

O equipamento sem suporte lê outra instrução

Um headend pode implementar FlowSpec básico e Redirect-to-IP sem conhecer esta extensão. Como Prefix-SID é opcional e transitivo, ele pode propagar o atributo sem entendê-lo, ignorá-lo no forwarding e usar o redirecionamento que já conhece.

Assim, os mesmos bytes chegam a dois resultados. O equipamento alinhado à revisão 18 reconhece intenção SR incompleta e bloqueia o retorno. O equipamento antigo enxerga apenas um redirecionamento válido. Não é necessário erro de parsing nem queda da sessão: basta uma fronteira de capacidade não registrada.

O projeto exige controles administrativos para ativar os atributos por vizinho e por serviço, além de filtros nos limites do domínio confiável. Isso reduz o alcance, mas não descobre a versão do receptor. O emissor precisa de inventário de capacidades e de grupos homogêneos antes de distribuir a combinação nova.

A aceitação deve testar ausências: Redirect-to-IP puro, modos 1 e 2 válidos, Color ausente ou corrompido, policy Down, SID inalcançável, falta de recurso de forwarding e receptor sem suporte. Em cada linha devem aparecer Loc-RIB, anúncio, FIB, contador de descarte/redirecionamento, pacote de teste, alarme, supressão e recuperação.

O consenso da revisão 13 não assina a 18

O shepherd write-up associa o apoio anterior a um WGLC curto, de uma semana, sobre a revisão 13. A avaliação do Area Director veio depois e acrescentou dois modos, resolução sequencial de atributos, novas ações de serviço, regras de falha, compatibilidade e limites operacionais e de segurança.

Em 26 de agosto, após a revisão 17, o Area Director pediu aos chairs de IDR que consultassem de novo o grupo antes do avanço. O estado passou a AD Evaluation::External Party. Em 5 de setembro, a revisão 18 alterou novamente a parte mais sensível: substituiu o fallback do caso incompleto, incluiu o SID inalcançável e detalhou montagem de segmentos, filtros, notificações e contadores.

Essa nova consulta tem conteúdo real. É possível apoiar o objetivo do protocolo e discordar da escolha entre falhar aberto e falhar fechado. Um serviço pode considerar o desvio fora da policy um dano intolerável; outro pode considerar o descarte evitável pior. Rough consensus exige que a objeção técnica seja compreendida e tratada, não que o nome do documento herde aprovação de uma tabela antiga.

A pergunta pública precisa citar a revisão 18 e seus pontos: ausência de Color, manutenção da rota, policy ou SID indisponível, política local e comportamento legado. O encerramento deve preservar argumentos e avaliação dos chairs, não apenas um resultado binário solto.

Running code também tem versão

O documento relata quatro implementações de roteador e quatro controladores em testes conjuntos de interoperabilidade organizados pela China Mobile entre julho e outubro de 2021. Também relata uso em produção no backbone da empresa desde agosto de 2022. O aviso da própria seção limita a afirmação: os dados vieram de contribuidores, não foram verificados de forma independente e não equivalem a endosso da IETF.

As datas impõem outro limite. As fontes não ligam aqueles testes à matriz atual da revisão 18, ao novo caso de SID inalcançável, às regras de substituir ou acrescentar SID nem a uma frota com headends compatíveis e antigos. Uma revisão posterior não pode reescrever a lista de casos de um teste passado.

Preservar essa experiência exige registrar a versão. Cada linha deve trazer build, revisão, recurso ativado, combinações negativas, capacidade do peer e resultado observado do pacote. Um novo teste pode ampliar o registro de 2021 sem apresentar idade como abrangência.

Um recibo que una texto, equipamento e pacote

O bloco de consenso fixa hash da revisão 18, período, pergunta, respostas arquivadas, objeções e julgamento dos chairs. O bloco de interop usa a mesma fonte e reproduz a matriz: redirecionamento simples, modos válidos, Color inválido, policy Down, SID inalcançável e FIB sem recurso.

Cada caso separa headend compatível de não compatível e mostra quatro estados: rota aceita, anúncio propagado, ação instalada e pacote observado. Contadores, alarmes e supressão de logs completam o caminho de evidência.

O rollout registra remetente, grupos receptores, versões, filtros, intervalos de SID autorizados, política local, repetição, canário e gatilho de rollback. Endereços podem ser pseudonimizados; versão e resultado não. Uma correção deve ser acrescentada sem apagar a primeira falha.

A especificação mínima de Heng Lu serve aqui somente como teste editorial. O significado comum precisa ser pequeno, determinístico e verificável. O operador preserva a decisão sobre o risco local, mas deve mostrar quem decidiu e o que ocorreu. O rótulo da IETF não pode escolher o prejuízo pelo serviço.

A revisão 18 pode ser melhor que a 17. Antes de receber autoridade, porém, ela precisa de consentimento ligado ao texto presente e de prova de que equipamentos novos e antigos não transformarão a mesma ordem em duas promessas incompatíveis.

Fontes

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — texto da revisão 18
  3. IETF — texto da revisão 17
  4. IETF Author Tools — comparação das revisões 17 e 18
  5. IETF Datatracker — histórico do documento
  6. Lista IDR — pedido de nova consulta de consenso
  7. IETF — document shepherd write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification