Resumen

  • La revisión del 28 de octubre de una propuesta individual de enrutamiento según ancho de banda elimina dos métodos para iniciar el regreso desde rutas alternativas.
  • Su nueva primera condición se cumple cuando todo el tráfico ya está en la ruta principal y su utilización queda bajo un umbral posterior al retorno. El texto no define qué observación permite iniciar ese regreso.

El carril de emergencia tiene salida, pero la llave está al otro lado

Una fibra de un enlace agregado se rompe. El enlace sigue conectado, pero, en el ejemplo del propio borrador, la capacidad cae a la mitad y la ruta más corta no cambia. Los paquetes siguen llegando a la misma carretera, que ahora tiene menos carriles. La propuesta permite que un nodo cercano mida su enlace, reparta algunos flujos por alternativas y use caminos estrictos de Segment Routing; los pesos UCMP consideran ancho de banda disponible y utilización. El nodo no tiene que esperar a que el controlador central vuelva a calcular toda la red.

Pero un desvío temporal requiere una orden de regreso. La sección 4.4 define ese regreso como mover tráfico desde las rutas alternativas a la principal. Inmediatamente después, enumera dos condiciones. La primera exige que todo el tráfico ya haya vuelto y que la utilización de la ruta principal no supere un umbral denominado «Post-restore Threshold». La segunda exige que la primera siga cumpliéndose durante un «Restore Period» configurable. Como condición para comenzar el retorno, la primera describe el resultado que todavía falta producir.

No era así en la versión 00 de julio. Allí había dos métodos de activación: medir que la utilización del enlace congestionado había caído bajo un umbral de restauración, o decidir dinámicamente que el enlace local podía soportar todo el tráfico sin congestión. Ambos requerían estabilidad durante un tiempo configurable. La revisión de octubre borra esa pareja de métodos. El apartado general aún habla de un descenso bajo un umbral, pero el procedimiento detallado sitúa la comprobación después de devolver todos los flujos.

Una predicción de la carga que tendría la ruta principal con todos los flujos podría resolverlo. También podría servir una devolución gradual con mediciones y un criterio para detenerse. La sección 4.4 no elige ninguno. La carga observada mientras parte del tráfico está desviada no demuestra cuál será la carga cuando vuelva. La pieza que falta es una prueba anterior al primer movimiento. Si aparece en la siguiente versión, cambia el juicio sobre esta condición.

El registro del IETF identifica el documento como borrador individual. El fallo señalado está en el texto de la propuesta, no en una red operativa identificada. Precisamente porque el diseño entrega la reacción a un nodo local, su regla de recuperación tiene que poder ejecutarse con información disponible en ese nodo antes de actuar. El mecanismo para salir de la congestión ya está narrado; el de dejar de usar el desvío empieza por el final.

Fuentes