Resumo

  • A contribuição principal da versão 03 é integrar a RFC 7606. A seção 6.4.1 ordena quatro respostas a erros de UPDATE: reiniciar a sessão, desativar uma família de endereços, retirar as rotas da mensagem afetada ou descartar um atributo inofensivo.
  • O tipo de erro determina a ação prevista. Treat-as-withdraw exige NLRI legível; descartar atributo só cabe quando ele não afeta a seleção nem a instalação da rota.

Chega um UPDATE malformado de um vizinho. A pergunta operacional é quanto da rede precisa pagar por esse erro.

Datado de 22 de outubro, o draft-ietf-idr-bgp4-rfc4271bis traz essa escolha para a especificação-base do BGP-4. O apêndice B descreve como principal contribuição da versão 03 a integração da RFC 7606, publicada em 2015 para revisar o tratamento de erros em mensagens BGP UPDATE. A seção 6.4.1 apresenta quatro respostas, da mais forte à mais fraca. É uma escala de impacto, não um menu para o roteador escolher por gosto. Cada classe de erro recebe sua resposta; a implementação pode ser configurada para voltar ao reset de sessão.

Quatro dimensões do estrago

No topo está o reset de sessão. O roteador envia uma NOTIFICATION e encerra a sessão BGP. O alcance inclui todas as famílias de endereços negociadas com aquele vizinho. O estado das rotas passa então pelos mecanismos de convergência e recuperação do operador. Se o parser já não consegue localizar as rotas na mensagem com segurança, não há base para reduzir o defeito a uma lista pequena de prefixos.

Um nível abaixo, desativar AFI/SAFI isola uma família de endereços naquela sessão. AFI e SAFI identificam o protocolo de rede e o tipo de alcance anunciado. O rascunho aponta para o procedimento Multiprotocol BGP que permite ignorar rotas posteriores daquela família recebidas do mesmo vizinho. IPv4 unicast pode ser afetado enquanto IPv6 unicast continua usando a sessão. O limite é uma família em um peering, e não a relação inteira com o vizinho.

Treat-as-withdraw atinge as rotas carregadas no UPDATE que contém o erro. Elas são removidas do Adj-RIB-In como se tivessem sido retiradas na própria mensagem. A precisão depende de uma condição: o NLRI precisa ser interpretado com sucesso. Um roteador que não consegue saber quais prefixos estavam ali não pode improvisar uma lista confiável de retirada.

Na ponta mais leve está o descarte do atributo. O atributo de caminho malformado é removido e o restante do UPDATE continua em processamento. A perturbação diminui; a condição é rígida. O atributo não pode influenciar a seleção nem a instalação da rota. Descartar preferência, next hop ou outra informação que mude a decisão de encaminhamento transforma uma alteração de rota em uma “limpeza” silenciosa.

A distinção central separa a escala da resposta das informações que o parser ainda consegue confiar. Quando os comprimentos dos atributos entram em conflito, o rascunho usa o comprimento total de atributos para localizar o início do NLRI e exige treat-as-withdraw, salvo erro mais grave. Se o NLRI não puder ser analisado com segurança, as regras aplicáveis voltam ao reset de sessão.

O que a versão 03 reuniu

A RFC 7606 já havia introduzido um tratamento revisado para erros em UPDATE. A versão 03 incorpora essa lógica ao texto-base do BGP-4, juntando especificação principal e política de erro. Ela também deprecia subcódigos antigos de erro UPDATE cujas condições deixam de gerar NOTIFICATION sob o tratamento revisado. Para um NEXT_HOP semanticamente incorreto, troca “ignorar” por treat-as-withdraw e permite que a implementação restaure o reset por configuração.

A integração da RFC 7606 é parcial: suas mudanças a outras RFCs continuam fora deste rascunho. Em 24 de outubro, o Datatracker o classifica como Active Internet-Draft no grupo IDR, com estado IESG “I-D Exists”. O marco indicado é enviar o texto-base do BGP à IESG em maio de 2027 como Internet Standard. O cabeçalho diz que a proposta atualiza a RFC 7606 se aprovada.

O efeito chega à rede. O reset converte um erro de mensagem em evento de vizinhança. Desativar uma família altera a recuperação daquele serviço naquele peering. Treat-as-withdraw pode redirecionar o tráfego dos prefixos atingidos enquanto outras mensagens UPDATE continuam circulando. Descartar um atributo mantém a rota e elimina informação; a segurança depende do significado preciso desse atributo.

A rede em operação é o teste. Para cada classe de erro, o operador precisa ligar a causa registrada, a resposta prescrita, a ação executada, as rotas alteradas e a consequência no encaminhamento. O indicador Established responde uma pergunta sobre a sessão. A evidência que importa acompanha a decisão do UPDATE pelo Adj-RIB-In, pela rota selecionada, pela FIB e pelo pacote.

Fontes