Resumen

  • RFC 9855 activa una lista de reparación TI-LFA preinstalada y sin bucles cuando el PLR detecta un fallo directamente conectado.
  • Esa evidencia de reenvío local no prueba que hayan convergido todos los routers ni que un servicio, una sesión o una operación haya vuelto.

«El tráfico se recuperó» puede describir un hecho muy preciso: el PLR detectó un enlace o vecino fallido y aplicó una lista de segmentos calculada antes del incidente. Es un control valioso porque no espera a que la convergencia del IGP termine. Pero el hecho sigue siendo local al router, al recurso protegido y al modelo de fallo considerado.

RFC 9855 construye la lista sobre la ruta esperada después de converger. Bajo las condiciones de FIB que fija el RFC, la ruta explícita evita el recurso fallido y no forma bucles. La protección se activa al detectar el fallo y dura hasta que el IGP converge en ese PLR. Ninguna de esas frases dice que el resto de la red convergió al mismo tiempo.

El propio RFC limita el alcance. La operación local no controla los microbucles que puedan aparecer en otros routers por inconsistencias transitorias ni los que puedan aparecer cuando vuelve un enlace antes fallido. La lista puede ser correcta para un enlace, nodo o SRLG modelado y seguir siendo irrelevante para un fallo remoto, un límite de hardware, una dependencia de aplicación o una reducción de capacidad.

P-space, Q-space y segmentos de nodo o adyacencia construyen una respuesta de forwarding, no una prueba de experiencia. Los contadores del PLR muestran que una lista se activó; no demuestran que el DNS, TLS, la sesión, la base de datos remota o la transacción del cliente sobrevivieron. RFC 5286, RFC 7490 y RFC 5715 dan contexto, pero no convierten ese salto en una afirmación de servicio.

Sources