Resumen

  • Lighthouse, el portal que InterLAN IX describe para sus miembros, plantea cambios con vista previa por router, temporizador de reversión y confirmación individual. Si no puede probarse una recuperación segura, entra una persona.
  • La base de datos conserva el estado previsto y los cambios manuales aparecen como desviaciones. La IA solo lee y redacta informes. La facilidad para pedir un cambio no se convierte en autoridad para gobernar todo el intercambio.

El botón tiene buena publicidad; el segundo router, menos

En una página de autoservicio todo parece razonable hasta que aparece el segundo router. El primero acepta la nueva configuración, el segundo la rechaza y el tercero todavía espera. Un menú elegante no resuelve qué ocurre durante ese intervalo. En un punto de intercambio, el intervalo pertenece también a las redes de otros miembros.

El resumen de la charla de InterLAN IX en RIPE 93 describe Lighthouse precisamente en ese terreno incómodo. Andrei Dinu presenta una red que combina routers Nokia SR OS y switches Arista EOS. Una solicitud puede afectar varios routers; cada uno recibe una vista previa de la configuración, un temporizador de marcha atrás y una confirmación separada. Si no puede acreditarse una recuperación segura, un operador humano toma el relevo. La página de RIPE todavía no ofrece transcripción, diapositivas ni grabación. Tampoco publica cifras de cambios, fallos o recuperaciones. La historia disponible es el diseño de la autoridad, no una medalla de rendimiento.

InterLAN dice que su plataforma ofrece peering público mediante dos servidores de rutas, VLAN privadas y puertos de respaldo. Son piezas de infraestructura compartida. El catálogo exacto de cambios admitidos por Lighthouse no aparece en el resumen, así que no hace falta inventar una orden de producción. Basta observar la estructura del problema: quien solicita una modificación ve una necesidad propia; quien opera el intercambio debe responder por la coherencia del conjunto.

El temporizador de reversión tampoco funciona como una máquina del tiempo. Puede ordenar a un equipo que vuelva a su configuración anterior, pero el estado intermedio ya existió y quizá transportó tráfico. Por eso importa que Lighthouse confirme dispositivo por dispositivo y detenga la automatización cuando no logra demostrar una salida segura. Un incidente con un responsable identificable ofrece al menos una vía de decisión. «Lo decidió el sistema» suena estupendo hasta que alguien pide el teléfono del sistema a las tres de la mañana.

El libro mayor de la intención

La decisión más seria del diseño no está en la pantalla. Según el resumen, la base de datos es la dueña del estado previsto; un cambio hecho a mano en un dispositivo se muestra como desviación y jamás se adopta en silencio. Así se impide que un arreglo urgente se convierta, por pura inercia, en la política permanente del intercambio. La configuración observada y la configuración autorizada pueden diferir; borrar esa diferencia sería borrar la pregunta que permite investigar.

La Note 73 de Heng Lu exige separar participación de mandato. Aquí el miembro participa mediante una solicitud. El operador conserva la decisión sobre su infraestructura común. El ingeniero puede actuar ante una emergencia. El registro de intención debe explicar cuál de esas intervenciones recibió autorización duradera. El autoservicio es un canal; no es una escritura de propiedad del router.

El resumen añade un gemelo digital construido a partir de instantáneas de producción para ensayar cambios. Es una idea útil si quedan registradas la fecha de la instantánea, sus diferencias con la red real y el resultado del ensayo. El material público no incluye esos expedientes. Para evaluar Lighthouse, una sola transacción documentada serviría más que diez diapositivas: solicitud, configuración prevista en cada equipo, ensayo, aprobación, confirmaciones, detección de desvíos y resultado de la reversión.

La IA ocupa una posición deliberadamente menos heroica. Sus herramientas son de solo lectura; puede escribir informes y planes de migración, pero no cambiar configuraciones, dice la propia ficha de la charla. Un texto convincente no es un permiso operativo. Un humano debe decidir si el plan merece pasar por las mismas pruebas que cualquier otra propuesta.

La FAQ del operador añade otra frontera: las sesiones BGP con sus servidores de rutas son opcionales y cada participante elige su política de peering. InterLAN controla el tejido compartido; los miembros conservan decisiones sobre sus relaciones de interconexión. RIPE RIS sitúa el colector RRC22 en InterLAN-IX, Bucarest, y observa información de rutas desde fuera. Esa observación puede mostrar efectos; el registro de Lighthouse tendría que mostrar quién autorizó la configuración. No son la misma prueba.