Resumen

  • Para el RFC 4098, un dispositivo converge cuando completa las acciones del plano de control exigidas por la condición de prueba. Para el RFC 7747, la convergencia de la FIB termina cuando todos sus cambios están completos y todo el tráfico de prueba usa la ruta propuesta.
  • Susan Hares fue una de cinco personas firmantes de cada RFC, ambos informativos. Su continuidad en el registro permite leer juntas las dos medidas, pero no le atribuye en solitario el método, el consenso, una implementación ni el resultado de una red.

Antes de comparar cifras hay que comparar preguntas

Dos laboratorios reciben el mismo router. El primero inyecta una retirada, espera a que el proceso BGP elija otra ruta y observa cuándo la anuncia hacia el siguiente peer. El segundo mantiene tráfico para todos los prefijos ensayados, provoca el mismo evento y espera hasta que cada paquete enviado que debe seguir la alternativa deja de tocar el camino anterior. Ambos pueden publicar milisegundos. No han medido la misma cosa.

El RFC 4098 ordenó el vocabulario de la primera prueba. Howard Berkowitz, Elwyn Davies, Susan Hares, Prakash Krishnaswamy y Michael Lepp lo publicaron en 2005 para caracterizar la convergencia eBGP del plano de control de un solo dispositivo. Su foco inicial es la llegada, el procesamiento y la propagación de información de encaminamiento. El dispositivo ha convergido cuando realiza todas las acciones de control necesarias bajo la condición declarada. Si cambia la mejor ruta para un prefijo, anunciar el nuevo resultado a peers posteriores puede constituir el punto final.

Ese dato importa. Separa recepción, decisión y propagación, y permite estudiar cuellos de botella del proceso. El propio documento no lo presenta como prueba de forwarding. Señala que el inicio del reenvío a partir de información de control ya convergida, iBGP y la interacción entre varios dispositivos requieren trabajo posterior.

Por tanto, el primer cronómetro no miente cuando se detiene. Miente el informe que borra su etiqueta.

La mezcla de rutas decide qué router estamos probando

Incluso dentro del plano de control, «una tabla BGP» no es un estímulo uniforme. El RFC 4098 llama route mixture a la demografía del conjunto: distribución de longitudes de AS path, atributos y longitudes de prefijo, empaquetado en UPDATEs y tiempos entre llegadas. Un lote simple y repetido puede explorar un límite de procesamiento. Una secuencia inspirada en el tráfico real puede aproximarse a otra pregunta. Modelar fielmente la mezcla de Internet seguía siendo un problema abierto, no una configuración mágica llamada full table.

La política añade trabajo y cambia resultados. Aceptar todo no equivale a evaluar filtros, reescritura de atributos o muchas decisiones que terminan descartando rutas. También influyen el número de peers y rutas por peer, el churn, el flap damping, los timers, TCP, la autenticación y la presencia de tráfico de datos. Por eso una cifra sin política ni mezcla carece del denominador técnico que permitiría usarla.

Esta advertencia importa en compras. Si un fabricante utiliza prefijos simples con política mínima y otro utiliza una mezcla compleja con funciones de seguridad, ordenar sus cifras no ordena sus dispositivos. Ordena dos experimentos diferentes.

El RFC 7747 deja que el paquete marque el final

En 2016, Rajiv Papneja, Bill Parise, Susan Hares, David Lee e Ilya Varlashkin publicaron el RFC 7747. Define la convergencia de la FIB o del plano de datos como la terminación de todos los cambios de FIB, de modo que todo el tráfico reenviado tome la ruta recién propuesta. Afirma de forma expresa que esta convergencia es distinta de la del plano de control dentro del nodo y deja fuera de alcance las metodologías destinadas a ese plano.

La prueba rodea un único DUT BGP con topologías simples de tres o cuatro nodos para casos iBGP, eBGP y eBGP multihop. El control es una virtud experimental, pero también el borde de la afirmación. Un resultado así no incluye por defecto route reflectors distribuidos, resolución recursiva, túneles, varias tarjetas, fallos correlacionados ni la forma del tráfico de una aplicación.

El tester ofrece paquetes mientras sucede el evento. La pérdida observada permite inferir cuánto duró la transición. Esa técnica trae una limitación honesta: la distancia temporal entre dos paquetes consecutivos destinados a una ruta es la máxima precisión posible para esa ruta. Si la sonda mira cada veinte milisegundos, no puede confirmar una recuperación de dos milisegundos, aunque un registro interno tenga muchos decimales.

El reporte no termina en el tiempo. Cuenta paquetes ofrecidos y reenviados, pérdida de conectividad, pérdida de convergencia, paquetes fuera de orden y duplicados. Repite la tabla para el evento inicial y la reversión. Volver forma parte de la evidencia: una implementación que sale rápido de un camino pero tarda en recuperar el estado original muestra una asimetría que el primer cronómetro ocultaría.

La cifra lleva una larga etiqueta de condiciones

El RFC 7747 pide registrar la topología, el evento, enlaces paralelos, interfaces, sesiones y vecinos eBGP o iBGP, rutas únicas y no únicas, mezcla y empaquetado, IGP, política y funciones de seguridad. Añade tamaño de paquete, carga ofrecida, muestreo, umbral, timers de interfaz y BGP, y parámetros TCP. También exige describir cómo se aplica el evento y cómo se elige el subconjunto de rutas que recibe tráfico.

El ensayo base usa política mínima. Los opcionales deberían estar desactivados y los valores deberían volver a sus defaults salvo que la prueba declare otra cosa. Las interfaces deben mantener medio y capacidad entre iteraciones. Si se promedian repeticiones, todos los parámetros deben ser iguales. El RFC advierte que expiraciones de timers, planificación de CPU y otros efectos producen variación; la práctica estadística no se resuelve ocultando los ensayos detrás de la media.

Cada cambio de condición abre una serie nueva. Activar autenticación, modificar MRAI, usar otro conjunto de prefijos o aumentar la carga no es «otra muestra» de una propiedad eterna del equipo. Es otra pregunta sobre el equipo.

Una genealogía de medición cruzó los protocolos

El método BGP de RFC 7747 utiliza la técnica derivada de tasa del RFC 6412. Ese RFC trata IGP de estado de enlace y define observación externa de caja negra; el RFC 6413 desarrolla métodos basados en pérdida, tasa y rutas concretas. No dictan cómo debe funcionar BGP. Su contribución aquí es epistemológica: medir fuera del DUT aquello que el DUT causa fuera.

El RFC 1242 aporta vocabulario general de benchmarking y el RFC 2544 describe el banco de pruebas que envía tráfico a través de un dispositivo y verifica lo recibido. Esa tradición hace repetible un resultado acotado. No convierte el laboratorio en una réplica de producción ni autoriza a usar RFC 2544 como prueba automática de failover BGP.

El RFC 4271 describe el sustrato: BGP intercambia alcance, procesa UPDATEs y mantiene Adj-RIB-In, Loc-RIB y Adj-RIB-Out bajo políticas del AS. Esas estructuras muestran qué sabía y decidió el protocolo. Una FIB posterior muestra qué intentó instalar el equipo. El flujo externo muestra qué ocurrió a los paquetes observados. La cadena es fuerte cuando conserva las tres diferencias.

El hilo humano sin relato de inventor único

El Datatracker actual identifica a Susan Hares, también conocida como Sue Hares, y muestra su fotografía pública. La página la enumera como chair de IDR y secretaria del BGP Directorate, además de relacionar diecisiete RFC, incluidos 4098 y 7747.

Puede afirmarse que Hares contribuyó a dos documentos colectivos que, con once años de distancia, delimitan las medidas de control y forwarding. No puede afirmarse que ella sola inventara ambos enfoques, programara sus resultados futuros o controle el consenso, los productos y las redes que los emplean.

La responsabilidad está repartida. Los autores y revisores construyen un método público. El fabricante implementa las colas, RIB y FIB y decide qué telemetría expone. El laboratorio diseña el estímulo. El operador escribe la política. El dueño del servicio acepta o rechaza el impacto. Hacer visible esa cadena es más útil que una biografía heroica.

Siete piezas para una sola transición

Un expediente defendible une: el evento que inicia la prueba; las rutas y atributos recibidos; la política aplicada; la decisión y propagación de control; la instalación de FIB por prefijo o grupo; la secuencia externa de paquetes con su resolución; y el evento inverso. Un identificador y una base temporal común deben atravesar todos los niveles.

El intervalo entre el fin del control y la recuperación de los paquetes es un dato, no un fallo semántico. Puede ser amplio, estrecho o menor que la capacidad de resolución. Lo importante es no convertir «no pudimos distinguirlo» en «son el mismo instante».

Una columna llamada convergence_time debería desaparecer si no puede guardar su definición. El estándar no pide una palabra más elegante. Pide que el punto final responda a la evidencia que lo observa.

Fuentes