Resumen

  • El head-end solicita la protección y conserva sin modificar las restricciones de FAST_REROUTE. El PLR calcula o selecciona un respaldo elegible y lo activa localmente; el punto de merge vuelve al LSP protegido.
  • Un desvío uno a uno mantiene estado separado para cada LSP. Un bypass de facility puede proteger varios LSP elegibles, normalmente con apilamiento de etiquetas, pero introduce capacidad y dependencias de destino compartidas.
  • RFC 8796 añade señalización FRR resumida para reducir intercambios y presión de escala. RFC 9705 añade mantenimiento y limpieza independientes del refresco. Ninguna actualización implica soporte universal.

Tres autoridades, una secuencia

RFC 4090 se aplica a LSP RSVP-TE explícitamente enrutados, no a LSP unicast IGP que cambian dinámicamente. El LER head-end inserta el objeto FAST_REROUTE y los LSR posteriores no deben modificarlo. El objeto incluye prioridad de establecimiento y de retención, ancho de banda solicitado o estimado, límite de saltos, método de protección y filtros de atributos de enlace o afinidad. El head-end puede solicitar protección local, registro de etiquetas, protección de nodo y protección de ancho de banda.

La prioridad de establecimiento decide si una sesión puede obtener recursos desplazando otra; la prioridad de retención decide si sus recursos reservados pueden ser desplazados. Si no hay ancho de banda disponible, puede generarse un PathErr, salvo que puedan desplazarse reservas elegibles de menor prioridad. Son reglas sobre recursos, no una prueba de que exista un respaldo operativo.

El PLR es la autoridad local. Al detectar el fallo de un enlace o nodo protegido, redirige datos y control hacia el respaldo seleccionado. La detección es una entrada, no autoridad de reparación: no permite que el detector invente un camino. El PLR debe respetar la solicitud de protección elegible y el estado de reenvío disponible. local-protection-available exige un camino de respaldo disponible y el estado de reenvío necesario, según aclara la Errata verificada 4203. Cuando la protección está activa, el PLR marca local-protection-in-use y debería notificar al head-end mediante un PathErr.

El punto de merge cumple otra función: retira el contexto del bypass cuando corresponde y devuelve el tráfico al LSP protegido. En un bypass de facility, el PLR aplica la etiqueta del LSP protegido y apila la etiqueta del túnel bypass; el punto de merge elimina ese contexto. El PLR no adquiere la autoridad del head-end y el punto de merge no diseña el LSP. La reoptimización global permanece en el head-end.

Desvío individual frente a bypass compartido

El desvío uno a uno pertenece a un LSP protegido. Puede expresar restricciones precisas, pero sus túneles, etiquetas, señalización y reservas crecen con cada LSP. El bypass de facility protege varios LSP que comparten la facility y el punto de merge. Puede reducir construcciones repetidas, pero su capacidad, compatibilidad y estado común afectan a un conjunto mayor. Análisis: intercambia estado por LSP por una dependencia compartida; un bypass caído o un estado obsoleto puede ampliar el grupo potencialmente afectado. Ancho de banda, protección de enlace o nodo, afinidad y límite de saltos establecen elegibilidad, no garantía.

RFC 8796 actualiza el bypass de facility con señalización FRR resumida, destinada a reducir los mensajes entre PLR y punto de merge y la presión de control cuando muchos LSP comparten un bypass. RFC 9705 actualiza la protección de facility para que el mantenimiento y la limpieza de estado obsoleto no dependan necesariamente de temporizadores breves de refresco; incorpora procedimientos explícitos de capacidad, adyacencia y desmontaje. La compatibilidad de una implementación concreta sigue siendo desconocida.

Reversión, beneficios y coste

RFC 4090 distingue la reversión global, en la que el head-end reoptimiza los LSP TE afectados con una visión más amplia, de la reversión local opcional en el PLR. Recomienda el modo global y advierte que la reversión local puede añadir interrupciones durante la fluctuación de recursos. El PathErr avisa al head-end; no convierte el camino local temporal en el nuevo diseño extremo a extremo.

Análisis: los servicios sensibles a latencia o pérdidas pueden obtener continuidad local, y el operador puede evitar esperar la propagación y el cálculo de toda la red. El coste incluye capacidad reservada o susceptible de preempción, estado de etiquetas y señalización, limpieza, pruebas y acoplamiento entre LSP que comparten un bypass. Sin reparación preestablecida, esperar la convergencia del head-end o del enrutamiento puede prolongar la exposición y las pérdidas. El riesgo opuesto es desviar con rapidez hacia una reserva agotada o un estado obsoleto que ya no cumple la hipótesis original.

Los hechos proceden de los RFC citados y de las erratas verificadas; las consecuencias de liderazgo son análisis. No hay alegaciones. Se desconocen proveedores, despliegues, márgenes de capacidad, calidad de detección, tiempos medidos, resultados de clientes, fallos simultáneos, comportamiento ante inestabilidad e interoperabilidad entre versiones. El objetivo normativo de redirección uno a uno es del orden de decenas de milisegundos, no un resultado universal medido.

Fixtures de verificación

  1. Autoridad: originar un LSP RSVP-TE explícitamente enrutado con FAST_REROUTE, registro de etiquetas, protección de nodo, ancho de banda, prioridades, límite de saltos y filtros de afinidad. Confirmar que el head-end inserta el objeto y que nadie lo modifica.
  2. Disponibilidad: revisar el PLR antes del fallo. Confirmar que local-protection-available solo aparece con respaldo elegible y estado de reenvío; probar la interpretación de la Errata 4203.
  3. Fallo: retirar un enlace protegido y después un nodo. Capturar operaciones de etiquetas del PLR, local-protection-in-use, redirección y PathErr hacia el head-end.
  4. Método: comparar desvío uno a uno y bypass de facility. Verificar en el PLR la etiqueta del LSP protegido más la etiqueta del bypass y, en el punto de merge, la retirada del contexto bypass.
  5. Recursos: solicitar ancho de banda con prioridades concurrentes de establecimiento y retención. Verificar preempción, PathErr, protección de enlace, protección de nodo y desajuste de afinidad.
  6. Ciclo de vida: probar reversión global, reversión local e inestabilidad repetida. Probar RFC 8796 y RFC 9705 solo cuando la implementación declare esas capacidades.

Fuentes