Resumen

  • RFC 9917 es un Proposed Standard del IETF publicado en enero de 2026. Actualiza RFC 9350 y RFC 9843.
  • El mecanismo es direccional: el receptor puede aportar evidencia sobre la condición del extremo remoto y los Administrative Groups inversos pueden hacer que el cálculo excluya la arista de ida correspondiente.
  • El RFC no detecta fallos automáticamente, no vuelve simétrico un enlace físico y no demuestra despliegue de ningún proveedor. La telemetría, los umbrales, la codificación, el orden de las reglas y el soporte deben comprobarse.

Qué cambia el mecanismo

Hay que separar la arista dirigida que envía tráfico de la arista dirigida que representa lo que observa el otro extremo. RFC 9917 presenta el caso en que un receptor detecta errores de entrada; los errores CRC son únicamente el ejemplo del RFC. El operador puede definir un umbral y, cuando la medición lo supera, el receptor puede asignar un Extended Administrative Group a la arista en dirección inversa. Durante el cálculo de rutas, Flex-Algorithm usa esa afinidad inversa para decidir si conserva la arista de ida.

El RFC no fija un valor operativo universal. El operador debe establecer quién es dueño de la telemetría, qué evento activa la señal y qué evento la borra, además de validar la codificación. Umbrales distintos para activar y limpiar ayudan a evitar que una medición cercana al límite oscile. El throttling normal del IGP y la limitación del flooding también pueden reducir cambios repetidos y recálculos de rutas. Ninguno de esos controles define por sí mismo un umbral seguro para todas las redes.

RFC 9917 define para IS-IS y OSPF tres familias de restricciones reverse Admin Group: exclude, include-any e include-all. Exclude descarta un candidato cuya arista inversa tenga un grupo prohibido. Include-any exige al menos uno de los grupos solicitados; include-all exige todos. El formato del sub-TLV y el procesamiento del receptor son decisivos. Las longitudes mal formadas de los sub-TLV reverse-affinity se ignoran, y las apariciones duplicadas activan el comportamiento especificado para la codificación IS-IS u OSPF correspondiente. No se debe inventar una regla de «gana la última» ni una fusión automática.

El orden de poda no es opcional

Las nuevas restricciones son las reglas de cálculo 8, 9 y 10. Amplían el registro ordenado de reglas de pruning que ya existía en RFC 9350 y RFC 9843. El orden forma parte del contrato: el orden relativo de las reglas existentes no puede cambiar y las reglas no pueden eliminarse, fusionarse ni repetirse. Por eso la validación debe revisar el FAD ganador y la secuencia completa, no solo comprobar que el equipo reconoce un campo de afinidad inversa.

El soporte mixto presenta un riesgo concreto. RFC 9917 no obliga a todos los routers a soportar todas las restricciones de Flex-Algorithm, y el paquete de hechos no permite afirmar despliegues de proveedores. Un FAD aceptado sintácticamente puede producir podas distintas si cambian el soporte, el tratamiento de duplicados o la validación de la codificación. La aceptación debe comparar los atributos de ida y de vuelta, el FAD ganador, la topología podada y los estados de activación y limpieza.

Análisis — Theo March

La novedad estratégica es que un defecto de recepción en un solo sentido puede convertirse en una entrada de política de routing, sin afirmar que el enlace subyacente se haya vuelto físicamente simétrico. La capacidad es valiosa porque es condicional. El operador controla la cadena completa: telemetría, umbral, Administrative Group inverso, poda ordenada y convergencia. Si una parte no es observable, una señal útil puede terminar siendo un cambio de topología inexplicable.

La decisión no debería formularse como «activar RFC 9917». Hay que activar una restricción concreta solo cuando estén claros el dueño de la telemetría, los umbrales de activación y limpieza, la validación de la codificación de RFC 7308, el FAD ganador, el orden de las reglas, la cobertura de soporte, el impacto de convergencia y el rollback. Si falta cualquiera de esas pruebas, la función debe quedar desactivada o limitarse a un entorno controlado.

Esta tesis es distinta del replay de PCEPS de RFC 9916, del ciclo de vida de leases DHCPv6 de RFC 9915, de la proyección de rutas RPL de RFC 9914 y de la recuperación RAW de RFC 9912. Este briefing trata la evidencia direccional de un enlace como entrada ordenada de poda en un IGP Flex-Algorithm.

Ruta de decisión para la aceptación del operador

  1. Asignar al responsable de la telemetría del receptor y documentar la señal de error; CRC es solo el ejemplo del RFC, no un detector universal.
  2. Elegir y probar umbrales separados de activación y limpieza, y medir el flooding y los recálculos ante una señal ruidosa.
  3. Validar la codificación Extended Administrative Group conforme a RFC 7308, incluidas las longitudes mal formadas y las apariciones duplicadas.
  4. Confirmar el FAD ganador, las reglas 8–10 y las reglas anteriores, sin cambiar, eliminar, fusionar ni repetir el orden del registro.
  5. Comprobar el soporte de IS-IS y OSPF en todos los nodos participantes; no asumir soporte universal ni despliegue del proveedor.
  6. Observar atributos de ida y vuelta, FAD, rutas podadas, convergencia y rollback en una prueba gradual. Aceptar solo una cadena explicable de extremo a extremo.

Registro de afirmaciones y evidencia RFC

Afirmación Evidencia
Los Administrative Groups inversos pueden podar una arista de ida RFC 9917, resumen y secciones 1, 3
Errores de entrada remotos y señal inversa basada en umbral RFC 9917, sección 3
Exclude, include-any e include-all para IS-IS y OSPF RFC 9917, secciones 5–10
Longitudes mal formadas y apariciones duplicadas RFC 9917, secciones 5–10
Modelo Flex-Algorithm y selección del FAD ganador RFC 9350
Reglas de poda previas y extensiones RFC 9843
Codificación Extended Administrative Group RFC 7308
Reglas 8, 9 y 10 y orden inmutable del registro RFC 9917, secciones 11 y 12.3–12.3.1

Fuentes