Resumen

  • RFC 9791, Informational de julio de 2025, describe el caso de uso NFFRR: una segunda FRR sobre un paquete ya reparado puede producir un bucle. No normaliza por sí sola un mecanismo NFFRR.
  • draft-kompella-mpls-nffrr-04 y draft-li-mpls-mna-nffrr-01 expiraron. Sus mecanismos y posiciones TBA no son asignaciones actuales ni prueba de despliegue.
  • RFC 9994, Proposed Standard de junio de 2026, define codificación in-stack MNA, ámbitos y tratamiento de acciones desconocidas, pero no NFFRR. El 20 de septiembre de 2026, IANA no mostraba NFFRR en «Network Action Flags Without Ancillary Data».
  • Un veto de segunda reparación solo es defendible si puede vincularse a una topología, un modelo de fallo, una capacidad conocida y una frontera de confianza.

Cuando dos reparaciones razonables cierran un bucle

El ejemplo documental más claro está en el borrador expirado draft-kompella-mpls-nffrr-04. En una topología EVPN active-active, CE2 está conectado a PE2 y PE3. Si CE2 cae, PE2 ve su adjunto como fallido y desvía el tráfico hacia PE3. PE3 ve su propio adjunto como fallido y devuelve el tráfico hacia PE2. Una sola caída aparece como dos fallos locales, y dos decisiones de protección razonables componen un ping-pong hasta que expira el TTL.

No es un incidente de producción medido. Es un ejemplo diseñado para mostrar que la racionalidad local no garantiza seguridad global. RFC 9791 incorpora el caso de uso: después de una primera FRR, una segunda puede hacer que el tráfico siga circulando entre LSR, con posible congestión y más pérdida.

NFFRR cambia entonces la pregunta. El primer punto de reparación ya no se limita a escoger un desvío. Al marcar el paquete, también condiciona al siguiente nodo: «no vuelvas a repararlo». Es un veto delegado sobre una decisión futura.

Quién puede sacrificar la segunda oportunidad

Ese veto cambia la distribución del riesgo. El paquete puede llegar a un nodo que dispone de otra alternativa local, pero la marca le ordena abstenerse. El sistema acepta una pérdida deliberada porque el daño potencial de un bucle —capacidad consumida, colas, trabajo de reenvío y pérdida para otros paquetes— puede ser mayor.

RFC 7490 ya expone una tensión parecida en Remote LFA: ante ciertos riesgos de bucle, descartar puede ser menos perjudicial que permitir la circulación, aun cuando eso elimine paquetes que habrían podido entregarse. NFFRR lleva esa tensión al plano de una señal asociada al paquete.

La legitimidad del veto depende de supuestos concretos. El primer PLR necesita actuar sobre una topología suficientemente conocida, un modelo de fallo apropiado y una expectativa de que la segunda reparación es más peligrosa que el descarte. También necesita confiar en que los nodos posteriores interpretan la señal con la misma semántica y el mismo ámbito. Si cualquiera de esas premisas cambia, una orden prudente puede volverse obsoleta.

Topología y fallo no son detalles de implementación

RFC 5286 define LFA para fallos de enlace, nodo y SRLG, y deja claro que la cobertura depende de la topología. También advierte que un fallo más amplio que el previsto puede producir bucles temporales. RFC 7490 extiende la protección con Remote LFA, pero distingue el fallo de enlace de fallos peores de lo supuesto, como nodo, SRLG o fallos concurrentes.

RFC 9855, sobre TI-LFA con Segment Routing, amplía la cobertura bajo un marco definido: redes de dos conexiones, IGP de estado de enlace y reparación sobre trayectorias posconvergencia esperadas. Incluso aquí, «topology independent» no significa independencia de todo modelo de red o fallo.

Por eso una marca NFFRR no debería entenderse como verdad atemporal. Una decisión tomada bajo «falló un enlace» puede ser demasiado restrictiva si después existe una segunda salida segura, o insuficiente si el primer síntoma era solo una manifestación de un fallo de nodo. El veto debería poder vincularse a la versión de topología y al modelo de fallo que lo justificaron.

Capacidad mixta y semántica parcial

RFC 9789 enmarca MNA y subraya que los operadores necesitan conocer qué acciones soportan los nodos. RFC 9994 define la codificación in-stack, los ámbitos I2E, hop-by-hop y Select, y el tratamiento de acciones desconocidas. Con U=0, un nodo omite la acción que no entiende; con U=1, descarta el paquete, mantiene un contador local y puede emitir una notificación limitada en tasa.

Eso no crea NFFRR. Define cómo viajan y se procesan acciones MNA. En una ruta con capacidades mixtas, ignorar una acción que pretendía bloquear una segunda FRR puede anular el veto precisamente donde era necesario; forzar descarte ante una acción desconocida puede convertir una brecha de soporte en pérdida. La capacidad relevante, por tanto, no es solo «soporta MNA», sino «reconoce esta acción, en este ámbito, con esta conducta».

Al 20-09-2026, el registro IANA MPLS Network Actions mostraba sin entradas «Network Action Flags Without Ancillary Data». El bit TBA de draft-li-mpls-mna-nffrr-01 y las propuestas del otro borrador expirado no son una asignación vigente.

Señales falsas, ausentes o caducadas

Una marca puede faltar porque el primer PLR no soporte el mecanismo o porque se pierda en un camino heterogéneo. Puede quedar caducada tras un cambio de topología o política. Puede ser malinterpretada por un nodo con otra semántica operacional. Y puede ser falsificada: draft-kompella-mpls-nffrr-04 advierte que un LSR malicioso o comprometido podría insertar NFFRR e impedir una reparación válida, causando pérdida innecesaria.

RFC 5920 ofrece el marco general de seguridad MPLS/GMPLS: inyección, modificación, control de acceso, zonas de confianza, detección y reporte. Las fuentes revisadas no especifican una autenticación NFFRR concreta. La inferencia más limitada es que procedencia, filtrado fronterizo y observabilidad deben formar parte de la política si una señal puede retirar una opción de recuperación.

Propuesta editorial: un recibo de contención FRR

Propongo, como Daniel Kade y no como requisito de un RFC, un «recibo de contención FRR»: un registro auditable que explique por qué se ejerció el veto y qué ocurrió después. Debería conservar clase de servicio; primera y segunda observación; primer PLR y reparación; versión de topología y modelo de fallo; identidad, ámbito, inserción y ubicación de la acción; prueba de capacidad; procedencia y filtrado fronterizo; reconocimiento aguas abajo y disposición final; contadores, congestión y pérdida; propietario de política; y disparador de revisión o caducidad.

«Prueba de capacidad» debe distinguir soporte MNA, soporte de la acción, reconocimiento en el ámbito usado y conducta ante lo desconocido. «Disposición final» debe separar entrega, descarte por veto, descarte por acción desconocida y expiración de TTL cuando esos resultados sean observables.

Ninguna fuente revisada demuestra incidentes NFFRR de producción, implementaciones, interoperabilidad, prevalencia ni efectos cuantificados. El recibo no llena ese vacío retrospectivamente. Sirve para definir la evidencia que tendría que existir antes de afirmar que el veto funciona como política de contención y no solo como una intención de diseño.

Fuentes