Resumen

  • La principal aportación de la versión 03 es integrar RFC 7606. Su sección 6.4.1 ordena cuatro respuestas a errores UPDATE: reiniciar la sesión, deshabilitar una familia de direcciones, retirar las rutas del mensaje afectado o descartar un atributo inocuo.
  • La clase de error determina la acción permitida. Treat-as-withdraw exige que se pueda leer el NLRI; el descarte de atributos se reserva a los que carecen de efecto en la selección o instalación de rutas.

Llega un UPDATE mal formado desde un vecino. La pregunta operativa es cuánto debe abarcar la respuesta.

El borrador draft-ietf-idr-bgp4-rfc4271bis, fechado el 22 de octubre, lleva esa cuestión al texto base de BGP-4. Su apéndice B describe como principal aportación de la versión 03 la integración de RFC 7606, la revisión del manejo de errores en mensajes BGP UPDATE publicada en 2015. La sección 6.4.1 organiza cuatro tratamientos, del más fuerte al más débil. La escala mide el alcance; cada clase de error tiene una respuesta definida, y una implementación puede configurarse para volver al reinicio de sesión.

Cuatro tamaños para el mismo susto

El primer nivel es reiniciar la sesión. El router envía una NOTIFICATION y termina la relación BGP. El alcance incluye todas las familias de direcciones intercambiadas por ese vecino. Después, las rutas entran en los mecanismos de convergencia y recuperación del operador. Si el parser ya no puede encontrar con seguridad los prefijos del mensaje, el protocolo carece de base para fingir que el problema cabe en una lista pequeña.

El siguiente nivel, deshabilitar AFI/SAFI, aísla una familia de direcciones dentro de esa sesión. AFI y SAFI identifican el protocolo de red y el tipo de información de alcance. El borrador remite al procedimiento de Multiprotocol BGP que permite ignorar las rutas posteriores de esa familia recibidas del mismo vecino. IPv4 unicast puede quedar afectado mientras IPv6 unicast sigue viajando por la sesión. El perímetro es una familia en un peering; el vecino completo permanece aparte.

Treat-as-withdraw limita la respuesta a las rutas incluidas en el UPDATE defectuoso. Esas rutas salen de Adj-RIB-In como si el mensaje las hubiera retirado. Para hacerlo, el router tiene que interpretar correctamente el NLRI. Si no sabe qué prefijos venían en el mensaje, inventar una lista de retiradas sería precisión teatral.

El cuarto tratamiento es descartar el atributo. Se elimina el atributo mal formado y el resto del UPDATE continúa. La perturbación es menor y la condición es estricta: ese atributo no puede afectar la selección ni la instalación de la ruta. Tirar un valor de preferencia, un next hop o cualquier dato que cambie la decisión de encaminamiento convertiría una avería semántica en una decisión silenciosa.

La clave es separar la escala de respuesta de la evidencia que aún conserva el parser. Cuando las longitudes de los atributos se contradicen, el borrador usa la longitud total de atributos para ubicar el NLRI y exige treat-as-withdraw, salvo que haya un error más grave. Si el NLRI no se puede analizar con confianza, las reglas pertinentes vuelven al reinicio de sesión.

La versión 03 reúne el trabajo

RFC 7606 ya establecía un tratamiento revisado para errores en UPDATE. La versión 03 lleva esa lógica al texto principal de BGP-4. También deja obsoletos varios subcódigos de error UPDATE cuyas condiciones ya no producen NOTIFICATION con los procedimientos revisados. Para un NEXT_HOP semánticamente incorrecto, cambia “ignorar” por treat-as-withdraw y permite configurar una vuelta al reinicio de sesión.

La integración es parcial: las modificaciones de RFC 7606 que afectan a otros RFC permanecen fuera del borrador. El 24 de octubre, Datatracker lo clasifica como Active Internet-Draft del grupo IDR y muestra el estado IESG “I-D Exists”. El hito previsto es presentar el texto base de BGP al IESG en mayo de 2027 para convertirlo en Internet Standard. La cabecera indica que actualizaría RFC 7606 si se aprueba.

Las consecuencias llegan mucho más allá del parser. Reiniciar una sesión convierte un mensaje defectuoso en un incidente de vecindad. Deshabilitar una familia cambia la recuperación de ese servicio sobre el peering. Treat-as-withdraw puede mover el tráfico de los prefijos afectados mientras los demás UPDATE siguen circulando. Descartar un atributo conserva la ruta y elimina información; su seguridad depende de la semántica concreta de ese atributo.

La red en ejecución es el lugar donde se comprueba la regla. Para cada clase de error, el operador necesita enlazar la causa registrada, la respuesta definida, la respuesta observada y el conjunto de rutas que cambió. El estado Established contesta una pregunta. La evidencia útil sigue la decisión del UPDATE por Adj-RIB-In, la ruta elegida, la FIB y un paquete.

Fuentes