Resumen

  • El plan de RIS para el tercer trimestre de 2026 afirma que ya terminó la migración de datos RIS/RIPEstat a servidores bare metal alquilados. El seguimiento del procesamiento, la limpieza de deuda técnica y el estudio de alternativas de almacenamiento para depender menos de HBase siguen en curso.
  • La sustitución de máquinas Kafka y la actualización de versión aparecen como un proyecto distinto, antes aplazado por falta de recursos. No hay base para presentar esa renovación como prueba de que la migración de datos falló.
  • El plan histórico de RIPEstat reconoce latencia adicional hacia los sistemas de backend durante el cambio. El equipo estudió consultas paralelas y vigiló el efecto, pero no publicó un valor ni describió una caída del servicio.
  • Hace falta un recibo delimitado por componente: alcance de los datos, generaciones técnicas, ventana de corte, decisión de replay o backfill, pruebas separadas para MRT, RIS Live y RIPEstat, excepciones conocidas, responsables y periodo de observación.

Una frase que contiene un mapa de responsabilidades

La página de planificación trimestral de RIS ofrece algo más útil que una barra de progreso. RIPE NCC dice que ha terminado la migración de datos RIS/RIPEstat a bare metal alquilado. Acto seguido, define como trabajo posterior la mejora de la monitorización del procesamiento y la reducción de deuda técnica. También investiga arquitecturas de almacenamiento alternativas para reducir la dependencia de HBase. El estado de ese bloque es «en curso».

En otra línea, RIPE NCC está reemplazando las máquinas Kafka y actualizando la versión del software. Ese trabajo había sido pospuesto por limitaciones de recursos y también figura en curso. No hay contradicción: se trata de objetos distintos. El problema aparecería si el lector convirtiera «datos migrados» en «cadena completa renovada y aceptada».

Tampoco corresponde hacer la inferencia opuesta. Que la monitorización siga abierta no demuestra pérdida, corrupción, indisponibilidad ni un corte fallido. Es razonable observar una plataforma después del cambio; es razonable que un ciclo de hardware no coincida con un traslado de datos; es razonable investigar el siguiente almacén después de estabilizar el actual.

La cuestión pública es cómo conservar esas diferencias dentro de un registro que sobreviva al calendario del proyecto. Dentro de seis meses, el título del ítem quizá haya desaparecido del plan. Los datos, las consultas y los estudios que atraviesen la ventana de cambio seguirán necesitando una procedencia.

La observación de BGP atraviesa varias custodias

Según la descripción del Routing Information Service, redes voluntarias establecen sesiones BGP con Remote Route Collectors distribuidos, normalmente situados en puntos de intercambio. Los colectores reciben anuncios y retiradas; RIPE NCC conserva y publica datos para que operadores e investigadores examinen el sistema de enrutamiento.

Cada verbo introduce una custodia. El participante decide qué vista entrega. El RRC observa esa sesión. Un sistema de transporte mueve mensajes. Los procesos ordenan, agregan o transforman. Un almacén conserva generaciones. Distintas interfaces entregan un archivo, un flujo o la respuesta a una consulta. Finalmente, un usuario selecciona un intervalo y formula una conclusión.

La migración puede modificar una sola custodia o varias. Sin un recibo, un resultado obtenido cerca del corte deja preguntas elementales: ¿qué generación lo procesó?, ¿qué rango ya estaba en el nuevo almacén?, ¿se reprodujo una cola?, ¿hubo un periodo en paralelo?, ¿la verificación miró una salida pública o el contenido subyacente?

Estas preguntas no acusan a la plataforma. Son la diferencia entre una observación repetible y un resultado cuyo origen depende de la memoria de los equipos.

RIPEstat demuestra que el consumidor tiene su propio reloj

El plan archivado de RIPEstat dice que el proyecto introdujo latencia adicional entre RIPEstat y sistemas de backend. El equipo apoyó la migración, buscó formas de ocultar esa latencia —incluidas consultas en paralelo— y vigiló cuidadosamente el impacto. El ítem aparece completado en el tercer trimestre de 2026.

No se publica cuánto aumentó la latencia. Tampoco hay un objetivo incumplido, una lista de consultas afectadas ni una afirmación de que el paralelismo se convirtiera en la solución definitiva. Por eso el dato no debe convertirse en una historia de avería.

Su valor está en otro lugar. Una base puede estar trasladada y aceptada mientras el servicio que la consulta todavía gestiona una nueva distancia. Medir el almacenamiento no sustituye medir la consulta. Una respuesta HTTP tampoco certifica el percentil de cola, el grado de paralelismo o la frescura de cada conjunto de datos.

Un buen recibo podría nombrar clases de consulta y mostrar distribuciones antes, durante y después del corte. No necesita exponer consultas de usuarios ni direcciones internas. Basta con indicar qué se midió, durante cuánto tiempo y con qué mitigación.

MRT y RIS Live no son testigos intercambiables

La documentación de MRT fija una unidad pública útil: archivos por colector. Un bview representa el estado de enrutamiento en un momento; un archivo de actualizaciones conserva los cambios de un intervalo. En la documentación actual, los dumps se crean cada ocho horas y las actualizaciones cada cinco minutos.

Ese patrón permite construir expectativas: qué nombres e intervalos deberían existir para cada RRC. Pero comprobar un nombre no valida todo el contenido ni todas las demás salidas. Hay que asociar el archivo a la generación que lo creó, registrar tamaño o hash, tratar excepciones y señalar cualquier repetición o backfill.

RIS Live ofrece mensajes BGP cerca del tiempo real. Tiene otra semántica. Un flujo reciente puede funcionar mientras un archivo histórico se publica tarde. Una colección de archivos puede estar completa mientras una consulta RIPEstat absorbe más latencia. Las fuentes revisadas no autorizan a dibujar una única ruta interna común a las tres superficies.

Eso obliga a pruebas independientes. Para MRT: intervalos esperados por RRC y comprobaciones de contenido acotadas. Para RIS Live: una métrica de frescura propia del flujo. Para RIPEstat: clases de consulta y percentiles. Después se pueden relacionar los resultados, pero no sustituir uno por otro.

La historia del servicio advierte contra borrar generaciones

Los planes archivados de RIS muestran por qué la procedencia debe acompañar al estado. RIPE NCC reemplazó en 2023 el pipeline que genera dumps MRT públicos, con menos retraso y cambios en la estructura de los archivos. Eso significa que dos intervalos históricos pueden pertenecer a generaciones de producción distintas aun cuando ambos sean válidos.

En 2025, RIPE NCC informó de que había resuelto una inconsistencia: datos de un único peer IPv6 retirado seguían apareciendo en datasets. El proyecto para documentar públicamente ese y otros artefactos se aplazó. La precisión es importante. La inconsistencia fue descrita como resuelta; lo pospuesto fue la documentación. No hay base para decir que continúa.

También hubo planes de Kafka externo y de código abierto para RIS Live que fueron despriorizados. Son historia de producto, no una descripción del despliegue actual. El prototipo público de Kafka no debe confundirse con el hardware Kafka que ahora se reemplaza. Un recibo bien escrito incluye también estas no-equivalencias.

El recibo: diez campos y ninguna topología sensible

La primera sección debe responder qué se migró: datasets, rangos temporales, colectores y productos incluidos o excluidos. La segunda debe fijar las generaciones aplicables de captura, transporte, procesamiento y almacenamiento. Si Kafka no pertenece a una ruta concreta, el campo debe decirlo; no hay que forzar una relación para completar una tabla.

La tercera sección separa los momentos del corte. Extracción, carga inicial, ejecución simultánea, cambio de escrituras, paso de tráfico y retirada del entorno anterior son decisiones diferentes. La transcripción de RIPE 88 las presenta por separado dentro de una conversación histórica más amplia sobre plataformas de datos. Sirve para entender la secuencia, no para afirmar cuál es la topología actual de RIS.

Después vienen las pruebas: muestras equivalentes a ambos lados del corte, intervalos MRT, recencia de RIS Live, percentiles RIPEstat, tolerancias y periodo de observación. El recibo registra si el replay o backfill no fue necesario, está completo, es parcial o queda pendiente. Añade los artefactos conocidos, sus superficies y su estado.

Por último, cada componente conserva un responsable y una fecha de aceptación. El documento puede publicar rangos, hashes, identificadores de build, recuentos y agregados. No necesita nombres de hosts, credenciales ni logs privados.

Así, el recibo no diluye la declaración de RIPE NCC. La fortalece. Permite que la migración de datos esté terminada sin fingir que Kafka, la arquitectura de almacenamiento, la monitorización del procesamiento y la experiencia RIPEstat son una sola tarea. Para una infraestructura que convierte BGP efímero en evidencia duradera, esa frontera vale más que otra etiqueta verde.

Fuentes