Resumen

  • El borrador individual de metodología ROV inicia una medición con el primer PDU RTR pertinente y la termina cuando se estabilizan la RIB BGP y la FIB. La segunda empieza después de instalar la actualización VRP y llega al mismo final.
  • La primera incluye entrega RTR, instalación, nueva validación y convergencia. La segunda deja fuera la entrega e instalación. Si el informe solo publica una, el borrador exige indicar cuál se midió.
  • Las poblaciones de VRP y rutas definen cargas de ensayo; el apéndice B también publica mediciones de un sistema BIRD/Linux, que no son cifras de otros equipos. Una comparación útil necesita el mismo comienzo, el mismo final y una carga declarada.

El router recibe datos nuevos sobre qué orígenes pueden anunciar determinados prefijos. Todavía no ha cambiado necesariamente la decisión que gobierna sus paquetes. Debe actualizar su tabla local de VRP, revisar los caminos BGP afectados, escoger los mejores y programar el reenvío. Si la compra se basa en cuánto tarda una corrección de seguridad en llegar al plano de datos, el reloj debe cubrir ese recorrido entero.

RFC 8210 especifica el intercambio RPKI-to-Router entre caché y router. RFC 6811 describe las etiquetas Valid, Invalid y NotFound para el origen de una ruta BGP; la política que aplica el router a cada etiqueta es local. Recibir una etiqueta y cambiar la ruta reenviada son hechos distintos. Entre ambos caben transmisión, instalación, cálculo de estado, selección de camino y escritura de la FIB. Llamar «latencia ROV» a una parte no identifica qué parte se ha cronometrado.

El borrador del 2 de noviembre resuelve esa ambigüedad en la prueba de convergencia activada por VRP. Su reloj completo empieza cuando el emulador RTR envía el primer PDU de actualización pertinente. Solo se detiene cuando la RIB BGP y la FIB están estables. El reloj posterior a la instalación comienza cuando el dispositivo bajo prueba ha incorporado la actualización VRP pertinente y termina en ese mismo estado estable. El primero sirve para saber cuánto transcurre desde los datos nuevos hasta el reenvío decidido. El segundo ayuda a aislar lo que cuesta la fase BGP posterior.

El incentivo comercial aparece sin necesidad de acusar a fabricante alguno. Si dos routers alcanzan una FIB estable en el mismo momento, el que inicie su cronómetro más tarde publicará un tiempo menor. La aritmética favorece al marcador tardío, aunque los paquetes no hayan cambiado antes. Para atribuir un resultado a un equipo concreto faltan las marcas de tiempo de ambos inicios y del final compartido, tomadas durante la misma ejecución.

El documento ofrece más puntos de control. En la prueba de instalación de VRP se anota el primer PDU RTR y cuándo la tabla del equipo refleja el cambio; con instrumentación suficiente se distingue primer VRP, último VRP y procesamiento del lote. Otra prueba sigue el cambio de estado de validación de los prefijos BGP afectados. La prueba de convergencia sigue la selección de mejores rutas, las retiradas o sustituciones y la estabilidad de RIB y FIB. Pedir solo «milisegundos de validación» permite que cada vendedor entregue una estación diferente de la misma línea.

También hay que leer la letra grande de la carga. El borrador propone ejemplos con 50.000, 100.000, 500.000 y un millón de VRP. Menciona como línea de base posible un millón de rutas IPv4 y 250.000 IPv6, o pruebas separadas por familia si se declaran. Son parámetros de laboratorio, no el tamaño afirmado de la tabla mundial ni resultados medidos. El informe debe indicar la cantidad efectiva de ROA y VRP, la proporción de rutas BGP cubierta, los solapamientos, las longitudes de prefijo y cuántos prefijos cambian de estado.

El apéndice B permite comprobar la distinción con datos propios. En un sistema de prueba BIRD 2.19.2/Linux, con 1.060.368 VRP iniciales, 1.000 prefijos seleccionados y 1.230 operaciones VRP, diez ejecuciones dieron una media de 5.027,552 ms de extremo a extremo y 4.813,556 ms después de instalar. Los cerca de 214 ms de diferencia corresponden al tramo excluido por la salida tardía en ese entorno; la mayor parte del tiempo transcurrió después de la instalación. Esos resultados no miden otro router. Sí demuestran que inicio, carga y final deben acompañar cada cifra.

Una actualización concentrada en una zona de la estructura de validación puede exigir un trabajo diferente de otra distribuida. El borrador pide ensayar ambas. Parte de un estado sincronizado de RTR, VRP y BGP, calienta el equipo y recomienda desactivar o limitar registros, telemetría en tiempo real y tareas de fondo que alteren la medición. Así se obtiene un experimento repetible. La red que conserva esas funciones encendidas tiene otra carga: debe repetir la prueba con su configuración antes de reservar margen operativo según una cifra de laboratorio.

No hay un fabricante ganador en este borrador. Hay una pregunta que puede cambiar una licitación: ¿el tiempo ofrecido incluye el camino desde la primera actualización RTR hasta la FIB estable? El reloj corto sirve para diagnosticar. El largo es el que compromete al sistema completo.

Borrador ROV, revisión 00 · RFC 8210 · RFC 6811