Resumen

  • El borrador individual publicado el 28 de octubre de 2026 propone medir la calidad de varias listas de segmentos de una ruta candidata activa y modificar sus pesos según una función de puntuación. La selección de métricas y su agregación quedan configurables.
  • Según RFC 9256, el peso relativo asigna una fracción de flujos y la precisión depende de la plataforma. Cambiar la fracción prevista no demuestra cuántos bytes pasaron por cada camino ni si mejoró la aplicación.

Una avería, tres listas y una palabra que manda

El ejemplo del borrador coloca tres listas de segmentos bajo la misma ruta candidata activa. Tienen pesos iguales. Una se degrada; la asignación fija sigue enviándole una tercera parte del tráfico en el dibujo. La solución propuesta consiste en medir los caminos, calcular su calidad y dar más peso al que parezca mejor. Los operadores conocen el atractivo de esta escena: si el desvío está disponible, ¿por qué esperar a que alguien cambie un número a mano? La pregunta difícil es quién escribió la fórmula que convierte un camino «mejor» en más flujos.

El texto da nombres a las piezas del circuito. Los nodos intermedios y finales pueden vigilar pérdida, latencia y utilización. Envían informes a un agente lógico de calidad de ruta candidata, CPQA. Ese agente reúne datos, obtiene una puntuación por lista, aplica una función F y entrega una nueva tupla de pesos. El head-end la instala en el plano de reenvío. Medir, informar, agregar, calcular y aplicar son actos distintos. El borrador dibuja sus enlaces y dice que los pesos deben ser proporcionales a la puntuación de calidad. No fija una fórmula universal para combinar las métricas ni un umbral de calidad válido para toda aplicación.

Un enlace puede tener poca demora y escaso margen de capacidad. Otro puede aceptar transferencias largas sin ofrecer la mejor latencia a peticiones pequeñas. La revisión 01 añade una motivación ligada a cargas de IA: el entrenamiento con comunicación colectiva busca rendimiento sostenido; las peticiones de inferencia y los mensajes de control sufren por la latencia inicial y extrema. Son categorías del argumento de los autores, no una medición publicada de una red determinada. Precisamente por eso la función F importa. El mismo conjunto de muestras puede producir dos órdenes de preferencia distintos según el tráfico al que el operador haya decidido servir.

El peso cuenta flujos, no promete megabits

RFC 9256 describe la arquitectura estable de SR Policy. Una política puede tener varias rutas candidatas; la activa proporciona las listas de segmentos usadas para enviar tráfico, salvo las excepciones previstas para respaldo. Con varias listas en la ruta activa, el head-end aplica ECMP ponderado por flujo. Una lista de peso w recibe una fracción prevista w / suma de pesos de los flujos. El RFC advierte que la precisión del balanceo depende de la implementación de la plataforma. No dice que la misma fracción de bytes, ancho de banda o satisfacción del usuario viaje por ese camino.

En el dibujo de tres listas iguales, «un tercio» es una proporción del modelo de encaminamiento. Un flujo enorme puede transportar más bytes que cientos de intercambios pequeños. Tras una actualización dinámica, la lista premiada por la puntuación puede recibir más flujos y aun así menos datos; la lista castigada puede conservar un gran flujo. El efecto tampoco se deduce solo de la configuración, porque el hash de la plataforma y la mezcla de tráfico cuentan. Si el controlador presume de haber aumentado el peso de la ruta buena, el operador necesita ver el estado que instaló el head-end y el tráfico que salió por cada lista.

La propuesta mantiene un límite útil: cambia pesos dentro de la ruta candidata activa. No altera su prioridad ni sustituye la composición de listas. Además presenta un modo separado para mover flujos congestionados identificados hacia una lista menos cargada. Cambiar una regla proporcional y seleccionar flujos concretos son dos mandos distintos. El segundo obliga a decidir cuáles son los flujos afectados, cuánto tiempo dura el desvío y cómo se demuestra el alivio. El borrador plantea ambos modos; ninguno viene acompañado de una prueba de rendimiento de una red con nombre.

El propietario de F puede cambiar sin mover un cable

El CPQA puede vivir en un controlador central: recibe informes, calcula pesos y manda la nueva tupla al head-end mediante una interfaz descendente, con PCEP citado como ejemplo. También puede vivir en el propio head-end: los monitores le informan directamente y él calcula y aplica los pesos localmente. El documento no define un nuevo mensaje PCEP. Su sección IANA no solicita una asignación ahora; una futura extensión de protocolo podría necesitarla. La arquitectura propuesta distribuye responsabilidades antes de estandarizar un nuevo botón en el cable.

El controlador central ofrece una visión conjunta y una única regla de cálculo. Una regla equivocada también puede difundirse a muchos head-ends. La variante local permite reaccionar con estado cercano, pero distintos equipos pueden entender la calidad de distinta manera. En ambos casos, la auditoría debe identificar quién aprobó la función, qué muestras recibió, cómo trató retrasos y datos ausentes, qué tupla pidió y qué tupla entró realmente al plano de reenvío. «Automático» describe quién no pulsó el botón durante el cambio; no responde quién diseñó el botón.

La seguridad del canal importa. La propuesta exige autenticación de los mensajes entre monitores, CPQA y ejecutor, y recomienda TLS o TCP-AO. Como los informes pueden revelar el estado interno de la red, aconseja considerar el cifrado si hay una preocupación de privacidad. También pide resistencia a inundaciones de informes falsos y recomienda limitar la tasa y validar fuentes. Una fuente autenticada puede seguir enviando una muestra atrasada o medir un punto que no representa toda la ruta. La identidad del remitente y la pertinencia del dato necesitan comprobaciones diferentes.

La amortiguación es otra decisión que no cabe esconder en una etiqueta. El texto propone evitar oscilaciones por cambios transitorios, pero este marco no fija un algoritmo ni un umbral universal. Una respuesta demasiado rápida mueve flujos, cambia la utilización y puede volver a moverlos persiguiendo su propio efecto. Una respuesta demasiado lenta mantiene carga en el camino degradado. El operador elige la cadencia y necesita conservarla junto a la versión de F.

La fecha de la revisión tampoco debe venderse como estreno del mecanismo. La versión 00 de julio ya contenía la secuencia medir-informar-calcular-aplicar. La 01 añade la motivación de cargas de IA y otro autor. Datatracker la clasifica como Internet-Draft individual. Los originales disponibles no incluyen una traza de interoperabilidad ni un ensayo que vincule muestras, función F, pesos instalados y resultado de una aplicación. Una serie de ese tipo permitiría juzgar un despliegue concreto.

Fuentes