SR Policy mantiene CP1 válido con capacidad supuesta a la mitad

Resumen

Un borrador del grupo SPRING plantea una ruta candidata que transporta 200 Mbps por dos listas de segmentos de 100 Mbps supuestos cada una. Si falla una lista, la regla recomendada por RFC 9256 puede mantener «válida» a CP1 aunque la capacidad restante del ejemplo sea de solo 100 Mbps.
El borrador propone exigir un número mínimo de listas válidas y una suma mínima de sus pesos. El operador debe decidir qué pérdida tolera, mantener las cifras alineadas con la capacidad real y comprobar qué umbral recibió el nodo de cabecera.

El camino sobrevivió; la cuenta no

La aritmética es menos indulgente que una etiqueta de estado. En el ejemplo del borrador de SPRING, CP1 conduce 200 Mbps repartidos por dos Segment Lists. SL1 y SL2 pesan 1 cada una, y el documento supone que cada lista admite 100 Mbps. El reparto por flujo deja 100 Mbps en cada lado. Cuando uno deja de ser válido, el otro no adquiere por cortesía la capacidad que falta. Sin embargo, CP1 puede seguir siendo el camino activo conforme al criterio recomendado en RFC 9256: basta con una lista constituyente válida.

La regla comprueba que queda un camino. Quien compra o promete capacidad necesita saber algo distinto: si el camino restante admite la carga asignada. Una consola puede mostrar ambos asuntos como una sola luz verde. Ese pequeño ahorro de espacio en pantalla resulta caro cuando el controlador y el equipo de servicio usan la palabra «válido» con significados diferentes.

La política POL1 tiene CP1 y CP2. CP1 gana por preferencia mientras sea válido. La sección 5.1 de RFC 9256 deja inválido un camino candidato explícito cuando pierde todas sus listas válidas. La pérdida de una sola lista puede dejar a CP1 delante de CP2, aun con la mitad de la capacidad supuesta en el ejemplo. El borrador no revela la capacidad de CP2 ni un registro de paquetes después de un cambio de selección. Presentarlo como un relevo seguro sería dibujar un puente donde la fuente solo muestra otra puerta.

Dos umbrales para despedir a CP1 antes de tiempo

El primer control es un mínimo de listas válidas representado en ocho bits. Si el operador fija 2 para el ejemplo, la pérdida de SL1 o SL2 invalida CP1. Un 0 no añade condición de conteo; 0xff exige que todas las listas sean válidas. El segundo control fija, en 32 bits, una suma mínima de los pesos de las listas válidas. Con pesos 1 y 1, poner 2 lleva al mismo resultado: una lista perdida deja la suma en 1. El cero retira el límite de peso; 0xffffffff exige todas las listas. Si se fijan ambos, CP1 debe superar ambos. Con dos ceros se mantiene el mecanismo de RFC 9256.

El conteo tiene una virtud política: cualquiera puede verificar si quedan una o dos listas. Su defecto es que trata por igual una lista grande y una pequeña. El peso admite más matiz, pero tampoco mide Mbps por sí mismo. En el ejemplo, cada peso 1 acompaña una capacidad supuesta de 100 Mbps. En una red donde la capacidad cambie y el peso permanezca igual, superar el umbral puede ser una descripción exacta de una configuración desactualizada. La seguridad depende de una relación mantenida entre demanda, capacidad y pesos, no del encanto de un campo nuevo.

El nodo de cabecera podrá recibir esos parámetros por configuración, PCEP o BGP, según el borrador. Los detalles de extensión de protocolo se reservan a otro documento; aquí no se solicita ninguna asignación a IANA. La pregunta de gobierno aparece precisamente en ese margen: ¿quién elige el umbral, quién lo envía, quién comprueba la versión aplicada y quién lo revisa cuando cambia la carga? Ningún comité puede establecer con una sola cifra la tolerancia de todas las redes. La organización que asume el servicio conoce la obligación que intenta cubrir.

Una lista, un candidato, una política

RFC 9256 distingue niveles que un panel de control suele comprimir. Una Segment List puede dejar de ser válida por sus reglas de resolución o verificación. CP1 puede conservar su validez gracias a otra lista. La SR Policy completa solo resulta inválida cuando todos sus caminos candidatos lo son. Un cambio de validez obliga a repetir la selección y escoger entre los candidatos válidos por preferencia. Los umbrales propuestos atacan el punto intermedio: deciden cuándo CP1 debe salir de la competición, sin esperar a perder la última lista.

Por eso no conviene confundir este asunto con Drop-Upon-Invalid, que gobierna el comportamiento opcional de una política entera ya inválida. Aquí la situación incómoda es anterior. CP1 todavía conserva una lista y el sistema puede felicitarse por la continuidad, aunque la carga del ejemplo ya exceda la capacidad supuesta del superviviente. Invalidar CP1 da ocasión a elegir de nuevo; la capacidad de la opción elegida sigue necesitando una prueba propia.

No hay en el borrador un incidente de producción ni mediciones de congestión. Para juzgar un resultado real harían falta el umbral desplegado, la capacidad disponible, la demanda observada y la selección resultante. Hoy la fuente prueba el choque entre una regla de existencia y una hipótesis de capacidad, además de describir dos instrumentos para que el operador declare su tolerancia.

La cifra que debe poder explicarse después

El expediente útil de una caída de lista incluiría la demanda atribuida a CP1, el estado de SL1 y SL2, el conteo y el peso supervivientes, los mínimos configurados y el origen de esa configuración. Si un controlador cree haber enviado 2 y el nodo aplica 0, el desacuerdo es más importante que el color del panel. Una revisión de capacidad debería quedar unida a una revisión de peso y umbral. De otro modo, el sistema puede seguir firmando certificados de validez para una red que ya no existe.