Resumen

  • Un estudio de 2026 estima que los UPDATE alrededor de eventos reconstruidos del RPKI representan menos del 1 % del volumen observado.
  • El método cuenta todos los mensajes de una ventana de convergencia, una regla que puede elevar el volumen atribuido.
  • La cuota no mide la carga de cada par, los cambios de camino, Route Refresh ni la conectividad de los usuarios.

El porcentaje importa porque sabemos qué cuenta

El hallazgo merece crédito. Samuele Quinzi, Cristel Pelsser y Giuseppe Di Battista estiman en un artículo revisado por pares el volumen de UPDATE de BGP observado alrededor de cambios en ROA. El resumen, publicado en Proceedings of the ACM on Networking, informa que las actualizaciones asociadas quedan por debajo del 1 % del total observado, incluso mientras crecen el RPKI y la tabla de rutas. La pregunta concreta es si esos eventos dominan el flujo observado de mensajes. En la serie estudiada, no.

En una entrada invitada de APNIC, Quinzi explica que los autores reconstruyen eventos con datos históricos del RPKI y cuentan como relacionados todos los UPDATE dentro de una ventana de convergencia. Algunos pueden tener otra causa; incluirlos tiende a ampliar el numerador. La cifra describe mensajes asociados temporalmente según una regla amplia, no demuestra que cada mensaje haya sido causado por el RPKI.

La estabilidad tiene varias dimensiones

El cociente compara UPDATE asociados con todos los UPDATE observados. No mide la proporción de routers afectados, prefijos cuyo estado de validación cambia, caminos seleccionados que se modifican ni tráfico de clientes interrumpido. UPDATE lleva información de encaminamiento; no indica directamente si una aplicación sigue accesible.

RIPE RIS recibe datos mediante sesiones BGP. Su colector RRC00 figura en Ámsterdam como multihop y de alcance global. “Global” describe el alcance del colector, no un censo de todos los caminos, del trabajo de CPU en cada par o de la experiencia de cada usuario. La cuota agregada tampoco muestra si la actividad se concentra en algunos vecinos.

La inferencia contraria también sería débil: muchos UPDATE no prueban una pérdida de servicio. Volumen de mensajes, carga por par, cambios de camino, tiempo de convergencia y conectividad están relacionados, pero no son intercambiables.

Route Refresh es otra carga

La RFC 9324 describe otro mecanismo: al recibir nuevos datos de validación, algunas implementaciones pidieron Route Refresh a sus pares para volver a evaluar rutas. La RFC advierte que eso puede trasladar una carga seria a los vecinos y recomienda conservar las rutas afectadas para evitar peticiones innecesarias. También registra casos de desactivación de ROV y rupturas de peering.

Es un riesgo concreto y una mitigación, no el comportamiento de todas las implementaciones ni una refutación del porcentaje del estudio. Una petición Route Refresh y la reanunciación posterior son observaciones distintas de contar UPDATE dentro de una ventana. Deben medirse por separado.

Ampliar la evidencia sin mezclar indicadores

Una respuesta más amplia requiere varias medidas: UPDATE por evento y por par; peticiones Route Refresh y rutas reanunciadas; tiempo hasta que se estabiliza el estado; frecuencia y duración de cambios de camino; y, si es posible, señales independientes de conectividad. Cada métrica debe declarar punto de observación, periodo, denominador y datos ausentes.

El archivo histórico del RPKI de RIPE usa instantáneas diarias; APNIC señala que cambios breves pueden quedar entre ellas. RPKI-Flutter registra eventos con más frecuencia, aunque en un periodo reciente más corto. La entrada informa que ambas estimaciones de UPDATE son parecidas durante el intervalo compartido. Eso respalda la reconstrucción del volumen comparado, no mide automáticamente la carga por par ni la experiencia de usuario.

La conclusión justa no es “sin riesgos” ni “desestabilizador”. El estudio ofrece tranquilidad sobre una pregunta delimitada: en la serie observada, los eventos RPKI no explican una parte grande de los UPDATE. Para hablar de estabilidad en general hay que nombrar primero el recurso, camino o servicio que se quiere proteger.

Fuentes

Fuentes primarias y referencias del protocolo: