Resumen

  • El 31 de agosto de 2026, el IESG aprobó la revisión 05 de Dynamic Flooding on Dense Graphs para publicarla como RFC experimental. En la documentación revisada todavía no había un número de RFC definitivo.
  • Un Area Leader calcula una topología escasa para difundir información de estado de enlace. La topología base, más densa, sigue siendo la superficie por la que se reenvían los datos.
  • El borrador exige siete resultados antes de un posible avance, entre ellos tres implementaciones independientes e interoperables y experiencia operativa documentada. El expediente identifica una sola implementación IS-IS.
  • «Aceptable» califica la convergencia, la reducción de inundación y la calidad operativa, pero no tiene un umbral numérico común. El operador debe fijar su definición antes de ver los resultados.
  • La prueba necesita un registro versionado con la revisión, el código, ambos grafos, los parámetros, el denominador, los fallos inyectados, el modo de repliegue y la persona que decide.

El estatus Experimental es parte de la decisión

La aprobación no afirma que haya aparecido una topología óptima. El grupo de trabajo Link State Routing alcanzó un consenso fuerte sobre la utilidad de experimentar con una solución común. La motivación es conocida: cuantos más enlaces útiles contiene un área, más copias de cada anuncio de estado pueden circular mediante inundación clásica.

El algoritmo separa la abundancia física de la ruta de distribución. Los enlaces del grafo base no desaparecen y continúan sirviendo al tráfico. El líder del área calcula un subgrafo para los mensajes de estado. Ese subgrafo debe incluir todos los nodos alcanzables, ser biconexo cuando sea posible, limitar el diámetro y repartir el grado para no convertir unos pocos equipos en embudos.

Un ejemplo del documento parte de diez nodos con 45 aristas y obtiene un subgrafo de 12. El diámetro sube de uno a cuatro. La cifra explica el intercambio: menos aristas de inundación pueden significar más saltos para distribuir un cambio. No es una medición de campo ni promete ese ahorro en otra topología.

La elección del cauce Experimental responde también al punto de partida. El shepherd encontró una implementación IS-IS. El cambio operativo es considerable y usa el marco experimental de RFC 9667. Los autores no presentan su algoritmo como solución normalizada ni garantizan que sea el mejor. Piden experiencia suficiente para saber si puede evolucionar hacia un Proposed Standard o si debe corregirse o retirarse.

Los siete criterios no se miden solos

La revisión 05 enumera una agenda exigente: tres implementaciones independientes que interoperan; experiencia de despliegue documentada; ausencia de objeciones fundamentales; validación de las consideraciones de seguridad; calidad operativa aceptable; convergencia y reducción aceptables; y robustez bajo cambios de topología.

Esa lista coloca límites útiles. Una demostración del único código conocido no cumple el requisito de independencia. Tres aparatos que incorporan la misma base de software tampoco lo cumplen por llevar marcas distintas. Y la interoperabilidad no termina en aceptar un paquete: el Area Leader debe codificar el grafo según RFC 9667 y los nodos deben deducir de forma coherente qué adyacencias usan para inundar.

La dificultad está en convertir los adjetivos en observaciones. «Aceptable» no puede significar lo mismo para un backbone con un presupuesto estricto de convergencia y para un laboratorio. La especificación hace bien en no imponer una cifra imaginaria a todos.

Pero la decisión local necesita una regla visible. Si el umbral nace después de la prueba, el resultado se vuelve negociable: se puede cambiar la ventana temporal, excluir la peor transición o informar solo de los nodos compatibles. La primera obligación del experimento es declarar qué evento abre el reloj, qué observación lo cierra, qué población cuenta y qué nivel obliga a retroceder.

El nombre del algoritmo oculta varias decisiones

Dos implementaciones pueden aplicar «dynamic flooding» y calcular grafos diferentes. El recorrido en profundidad, el orden de los vecinos, el desempate y la elección de enlaces adicionales quedan en manos del implementador. El registro debe conservar esas elecciones, no solo el nombre del mecanismo.

También importa quién ejerció de líder. Solo el Area Leader ejecuta el cálculo y anuncia la topología. Hay que observar la elección, la versión de su base de estado de enlace, el momento de activación y la sustitución del líder. El borrador señala que la gestión debería mostrar el líder y las adyacencias activas, pero no impone una interfaz uniforme.

En un despliegue parcial, los nodos heredados siguen inundando por todas sus interfaces. Esa compatibilidad evita partir el área, aunque reduce el beneficio. Un informe que usa como denominador únicamente los equipos actualizados describe un ensayo distinto de la red real.

La prueba decisiva aparece cuando el grafo deja de estar quieto. Pérdidas de enlace, caída de un nodo, particiones, recuperación y cambios rápidos obligan a combinar inundación temporal y nuevo cálculo. Si el repliegue llega tarde o una parte acepta un grafo distinto, los routers pueden construir estados inconsistentes. El promedio de mensajes de una hora tranquila no informa de esa frontera.

Qué debe conservar un registro de experimento

La primera sección identifica la revisión del borrador, el nivel de RFC 9667, la implementación y compilación, su madurez y licencia, el responsable y las fechas. Existe una divulgación de propiedad intelectual vinculada a estos trabajos; el operador puede registrar que la revisó, sin convertir una nota técnica en opinión jurídica.

La segunda fija la topología: huella del grafo base, recuentos de nodos y enlaces, participantes y equipos heredados, líder, elección, huella del grafo calculado, orden y desempates. Se pueden usar identificadores seudónimos estables para no publicar direcciones o una cartografía sensible.

La tercera preinscribe las métricas. Debe definir la convergencia, las interfaces que cuentan en el volumen de inundación, la carga por nodo, el diámetro, la distribución de grado, la pérdida tolerada y la ventana. Los percentiles y los extremos adversos deben acompañar a la media.

La cuarta enumera fallos antes de inyectarlos: enlace, nodo, líder, partición, cambios consecutivos, convivencia con nodos antiguos y vuelta a inundación clásica. Para cada caso se guardan la detección, el inicio del modo temporal, el nuevo grafo, la consistencia observada, el tiempo de recuperación y la intervención manual.

La última sección asigna la decisión. Avanzar, reducir el alcance, detener o revertir requiere un nombre, una autoridad, el umbral invocado y una fecha de revisión. Los registros fallidos no se sustituyen por una captura limpia posterior.

RFC 7942 ya ofrece un lenguaje útil para informar de código en ejecución: identidad, madurez, cobertura, compatibilidad, licencia, experiencia y pruebas de interoperabilidad. Como esos datos caducan, el lugar adecuado es un registro vivo que pueda alimentar el informe final del experimento.

Límites de la noticia

Las fuentes no prueban un despliegue de producción, tres códigos independientes, un ahorro concreto ni un incidente. El ejemplo de diez nodos no debe convertirse en una garantía de rendimiento. Tampoco corresponde extraer conclusiones legales de la divulgación IPR.

La revisión operativa de la versión 04 encontró problemas importantes: faltaba explicar mejor el despliegue incremental, la interacción de algoritmos, la operación y los fallos de nodos. La revisión 05 añadió Consideraciones Operativas. Es una señal de que la revisión mejoró el borrador, no una certificación de toda implementación futura.

La idea de especificación mínima de Heng Lu sirve de manera acotada. Las reglas comunes deben poder verificarse, mientras las decisiones posteriores conservan dueño y evidencia local. No aporta datos sobre la IETF ni sobre un operador concreto.

La aprobación pone por fin una pregunta común delante de varios implementadores. La respuesta no será el sello IETF, sino un conjunto de resultados comparables cuya definición no cambió después de obtenerlos.

Fuentes

  1. IESG — anuncio de la acción de protocolo
  2. IETF Datatracker — Dynamic Flooding on Dense Graphs, revisión 05
  3. IETF — informe del shepherd
  4. OPS Directorate — revisión de Last Call
  5. RFC 9667 — marco de inundación dinámica
  6. RFC 7942 — información sobre implementaciones
  7. IETF — divulgación IPR 4044
  8. Heng Lu — Minimum Initial Specification