Resumo

  • O draft-ietf-idr-fsv2-ip-basic-08 adiciona User Order, componentes obrigatórios ou opcionais e Dependent Filters Chain, porém cada nó decide localmente se a regra pode ser instalada.
  • A operação precisa de um recibo por alvo: objeto recebido, capacidade, validação, ordem efetiva, omissões, estado em software e hardware, contadores, remoção e resultado observado nos pacotes.

A malha recebeu uma regra e produziu vários efeitos

O controlador anuncia um filtro de emergência. Route reflectors o distribuem e todos os vizinhos esperados acusam recebimento. O plano de controle parece concluído.

Um roteador instala o match e todas as ações. Outro não suporta um componente obrigatório e invalida localmente também as regras da mesma cadeia. Um terceiro remove um componente opcional e instala o restante. Um equipamento antigo continua propagando uma action community cujo significado não conhece.

O objeto chegou; a política efetiva se dividiu. A revisão 08, publicada em 28 de setembro de 2026, descreve esse limite e afirma que o BGP ainda não oferece uma função action-reply.

UPDATE recebido comprova transporte, não execução.

Um Internet-Draft ativo não é prova de implantação

O Datatracker mantém a revisão 08 como draft ativo do IDR, em I-D Exists. O texto diz Standards Track, enquanto a ficha não informa o status RFC pretendido. AFI, SAFI e alguns tipos permanecem TBD; há notas editoriais e mecanismos completos de múltiplas ações ficam para outros trabalhos.

O documento é evidência do desenho em discussão, não de suporte em produto ou rede nomeada.

RFC 8955, RFC 8956 e RFC 9117 formam a base do FSv1. O FSv2 usa famílias diferentes, permitindo coexistência “ships in the night”. Durante a transição haverá pares com as duas versões, uma delas ou nenhuma.

O pacote, entretanto, encontra apenas uma ordem efetiva em cada caixa. Separação no protocolo não garante composição igual no dataplane.

User Order carrega intenção

Cada NLRI FSv2 contém User Order de 32 bits; números menores têm precedência melhor. O campo permite ao operador corrigir uma classificação padrão que não representa sua intenção.

A ordem muda o resultado. Uma exceção específica antes de um descarte amplo não equivale à mesma exceção depois dele. O draft recomenda FSv2 antes de FSv1 e uma base local comum.

Ainda assim, o receptor combina regras locais, resolve empates, valida match e ações e programa software ou hardware. O BGP não devolve a sequência finalmente ativa. A ordem anunciada e a instalada precisam de registros separados.

DFC compartilha destino apenas dentro do nó

Dependent Filters Chain reduz o risco de instalação parcial. O exemplo do draft combina uma regra específica que permite SMTP e marca DSCP com outra mais ampla que descarta. Se a primeira não entrar porque o equipamento não suporta DSCP, mas o drop entrar, tráfego legítimo é bloqueado.

Um DFC não zero liga regras. Quando uma é inválida localmente, todas com o mesmo DFC também ficam inválidas naquele dispositivo e não são instaladas.

Isso não é transação distribuída. Outro nó pode aceitar o conjunto; um reflector pode validar somente sintaxe. DFC não compara a frota, não responde ao originador e não desfaz regras já ativas em outro lugar.

É fail-closed local, não commit de rede.

Opcional pode alterar o conjunto de pacotes

Componente obrigatório não suportado invalida a regra. Se for opcional, o equipamento pode omiti-lo e instalar o restante como válido.

A migração fica mais fácil, mas o match pode se alargar. Um prefixo com qualificador novo e restritivo será preciso em hardware recente; no equipamento antigo o qualificador desaparece e a ação restante alcança mais tráfego.

A omissão deve virar evento observável: o que saiu, qual conjunto sobrou, que ação continua e quem autorizou a variação. Válido não significa idêntico.

Para ações não instaláveis, defaults ou configuração local podem decidir a validade. A revisão deixa recursos mais completos de ordem e validade para o futuro. Não há razão para presumir efeito uniforme numa frota mista.

Os bytes atravessam quem não entende o pedido

Ações FSv2 são associadas por Extended Communities. O RFC 4360 define transporte e transitividade. Um nó antigo pode propagar uma ação nova sem reconhecer que ela foi solicitada.

O comportamento vira best effort para o que ele entende. Uma mitigação que pede marcação, amostragem e redirecionamento pode virar apenas um subconjunto local. A solução completa de interação depende de trabalho posterior com containers. A community na RIB não prova a ação no hardware.

Validar, tornar elegível e instalar são estados distintos

FSv2 valida estrutura do NLRI, propriedades da rota e ações. Por padrão, a viabilidade depende de prefixo de destino e rota unicast relacionada, embora configuração explícita possa relaxar partes.

Malformação irrecuperável pode exigir reset da sessão. Outros erros usam treat-as-withdraw do RFC 7606. O draft alerta que uma retirada malformada de NLRI antes válido pode deixar uma stuck route e exige notificação.

Portanto, ausência de anúncio não comprova ausência de filtro. É preciso observar retirada da RIB, policy store, classificador, hardware e efeito sobre pacotes.

Distribuição rápida, confirmação mais lenta

RFC 4760 e route reflectors dão escala. Extended Communities carregam ações. O BGP é rápido justamente porque não espera a programação de cada alvo.

A revisão sugere complementar a distribuição com consultas via NETCONF ou RESTCONF. RFC 6241 e RFC 8040 fornecem request/response, mas não criam automaticamente um recibo FSv2 comum. Uma resposta pode confirmar aceitação, datastore ou tabela de software sem comprovar hardware e pacote.

O modelo útil tem duas velocidades: BGP inicia uma intervenção limitada e com prazo; outro ciclo confirma regra, contadores, resultado e remoção em cada nó.

O recibo necessário

Registrar versão e identificadores; autoridade e alvos; NLRI, User Order, DFC e flags; action communities; dados de validação e relaxamentos; horários por peer; capacidades; itens desconhecidos, não suportados e omitidos; decisão do DFC; ordem FSv1/FSv2 efetiva; identidades em software e hardware; contadores; expiração, withdraw e remoção observada; decisão de manter, reduzir ou reverter.

Recepção prova transporte. Validação prova conformidade local. Entrada de tabela prova programação. Contador prova encontro com tráfego. Nenhum recibo inventa o seguinte.

Primazia do código em execução é julgar pelo estado que o equipamento realmente produziu.

Fontes