Resumen

  • Stefan Wahl dijo que los directorios que analizó todavía reducen un IXP a una LAN de peering y a la conexión entre un ASN miembro y un puerto.
  • Cuando varios servicios comparten un intercambio, esa simplificación también deja sin ámbito claro a los filtros, los límites de prefijos y las fuentes de confianza.

Una ficha puede contar un IXP en una línea. La red que opera allí ocupa varias capas. En RIPE 92, Stefan Wahl contrastó el modelo tradicional de una LAN de peering con lo que ya ofrecen los intercambios: peering remoto, accesos a la nube, cachés alojadas, varios ASN y servicios que atraviesan las capas 2 y 3.

Wahl, CTO de Route128 y miembro del consejo de Euro-IX, llevó la discusión a un caso de San Francisco. Allí, explicó, convivían servicios de capa 3 y la malla de peering de capa 2; dos VRF permitían pasar tráfico entre ambas. Lo llamó un intercambio de “capa 2,5”. El modelo del directorio no tenía un objeto claro para describir ese servicio. Wahl señaló que la instalación ya transportaba tráfico: no era un dibujo de futuro.

Con varios servicios, una etiqueta para todo el intercambio no sirve para decidir qué ocurre en cada uno. ¿Qué prefijos acepta? ¿A qué punto de presencia o route server se conecta? ¿Qué fuentes IRR o criterios RPKI se aplican? Si la ficha solo dice “miembro conectado al IXP”, cada sistema que automatiza filtros debe adivinar dónde termina el servicio al que se refiere.

Wahl propuso avanzar hacia una identidad y un vocabulario de servicio que pudieran compartirse entre directorios y API. Los filtros y la confianza seguirían el ámbito del servicio. También citó las mallas IPv6-only, las direcciones link-local y los límites de prefijos por VLAN como datos que los campos comunes actuales no expresan bien.

No pidió fusionar directorios, sustituir las prácticas operativas ni construir un validador en tiempo real. El estado de aprovisionamiento local y la intención de cada miembro siguen perteneciendo a las herramientas de los operadores. La pregunta para el grupo de trabajo es más acotada: dar a cada servicio una descripción estable o dejar que cada cliente deduzca qué servicio está mirando. La transcripción de RIPE 92 registra la propuesta, pero no una decisión de adopción ni una fecha.

Fuentes