Resumen

  • James Bensley explicó en RIPE 93 que la expansión recursiva de un AS-SET dejaba a su red con un problema de filtros incluso después de que un cliente rechazara retirar entradas anidadas.
  • Su borrador individual excl-members propone que el titular del conjunto omita ASN o AS-SET concretos durante la resolución recursiva. Datatracker solo muestra una versión individual: no es una RFC ni una función desplegada.

El cliente podía marcharse

La conversación fue directa. Bensley dijo que su equipo pidió a un cliente que limpiara su AS-SET y le advirtió que podían cortar el enlace. El cliente tenía otros proveedores y se negó. El equipo de red seguía cargando con la expansión desordenada; el cliente podía elegir otra salida.

En RIPE 93, Bensley dijo que un AS-SET asociado a AS5405 se expandía a unos 76.000 ASN y 1,3 millones de prefijos. Según su relato, las referencias anidadas incluían redes que no eran sus proveedores de tránsito. Los pares que usaban el conjunto no podían generar los filtros que necesitaban para su red.

Son cifras que Bensley dio en la transcripción de la reunión, no un recuento actual de la base RIPE. La transcripción no indica la fecha exacta de medición ni la configuración del resolutor. Sí deja claro el choque: el dato usado para producir filtros se había alejado de las relaciones que el operador quería representar.

Un nombre no revisa a sus miembros

RPSL permite que un AS-SET enumere sistemas autónomos o remita a otro conjunto. El resolutor puede seguir esos enlaces por el árbol y reunir los miembros que aparecen más abajo. Los nombres jerárquicos ayudan a determinar quién puede crear un conjunto bajo un objeto padre. La documentación de RIPE Database aclara por separado que los miembros referenciados no tienen que existir cuando se crea el conjunto. Un nombre correcto, por tanto, no acredita que cada miembro anidado pertenezca al cono de clientes del operador.

Los incentivos tampoco resolvían esa brecha. Un cliente con varios proveedores podía rechazar la limpieza mientras la red que generaba filtros asumía las consecuencias. Amenazar con desconectarlo sirve poco si puede llevarse el tráfico a otro sitio.

Poner la exclusión en el conjunto padre

En abril, Bensley publicó un borrador individual de Internet-Draft que define excl-members para objetos AS-SET y route-set. El campo permitiría que el titular nombre un ASN o un conjunto identificado por registro que el resolutor debe omitir al expandir recursivamente los miembros. La exclusión seguiría esa rama por los conjuntos anidados, sin cruzarse a una rama hermana.

La intervención ya no depende de que el cliente corrija su propio objeto. El titular del conjunto padre podría reducir el resultado que publica aunque el objeto hijo siguiera igual. En los ejemplos del borrador, la exclusión se aplica durante la resolución y prevalece sobre una inclusión posterior dentro de la misma rama.

Ese control tiene un coste. Si el titular excluye el conjunto equivocado, un filtro posterior puede perder rutas que debía aceptar. El borrador exige identificar el registro de los AS-SET excluidos y limita la regla a la rama donde se declara. Eso hace más precisa la propuesta; no demuestra que un registro o resolutor la haya implementado.

La solución sigue en borrador

Datatracker solo enumera la versión 00 de draft-bensley-rpsl-exclude-members, como Internet-Draft individual con estado previsto Informational y fecha de caducidad del 17 de octubre de 2026. El borrador GROW relacionado, sobre miembros identificados por registro, aparece expirado y archivado desde el 24 de octubre. Ninguno es una RFC, y la transcripción de RIPE 93 no muestra un despliegue de producción.

La transcripción documenta el conflicto sobre la generación de filtros, no una fuga de rutas ni una caída. Una traza fechada del resolutor antes y después de la regla, con las versiones exactas de cada conjunto, permitiría comprobar si la propuesta corrige la expansión descrita.

Fuentes