Resumen

  • was-the-last-lie-accepted confirma solo que el Link Information Element recibido más recientemente superó la aceptación en una interfaz. No certifica ThreeWay, la jerarquía ZTP, la base TIE, el RIB/FIB ni una entrega.
  • Las acciones de clear reinician conexiones; no prueban su recuperación. La prueba exige observar de nuevo la secuencia completa y conservar el estado anterior a la intervención.

La distancia entre recibir y demostrar

RFC 9719 define un modelo YANG 1.1 de RIFT compatible con NMDA y ampliado sobre el modelo de routing del IETF. Su hoja was-the-last-lie-accepted es de solo lectura. Vale true cuando el LIE recibido más recientemente fue aceptado; si se rechazó, last-lie-reject-reason y las notificaciones neighbor-error aportan el motivo.

El dato es exacto, pero no es extensible por intuición. No confirma que el otro extremo haya reconocido al nodo, que la adyacencia esté en ThreeWay, que la elección de nivel sea correcta, que la información topológica esté sincronizada o que el tráfico haya llegado.

RFC 9692 separa esos hechos en la máquina de estados. TwoWay ya supone un LIE válido, aunque todavía no un LIE ThreeWay válido. Solo con ThreeWay se anuncia la adyacencia y se permiten los intercambios TIE, TIDE y TIRE. Aceptar una entrada es una condición previa; demostrar reciprocidad es otra observación.

Leer el modelo como una investigación

El modelo expone el estado de la interfaz y la razón de rechazo; el estado FSM y el vecino; las ofertas ZTP enviadas y recibidas; la mejor oferta y las retiradas con sus motivos; contadores y colas LIE/TIE/TIDE/TIRE; la base TIE local; los tiempos SPF y el TIE que disparó el cálculo; y notificaciones de error de vecino y TIE.

Ante un rechazo, primero se conserva la razón, el vecino, la notificación y el tiempo. Los mensajes concretos pueden diferir entre implementaciones, por lo que el estado normalizado debe acompañar al registro local.

Ante una aceptación, se inspecciona la progresión a ThreeWay. Quedarse en TwoWay no contradice el primer dato: identifica el punto exacto en que un mensaje válido no obtuvo confirmación recíproca.

Después se revisan las ofertas. Un LIE aceptable no demuestra que ZTP haya elegido el nivel y la dirección previstos. Las ofertas recibidas, la mejor candidata y las eliminaciones son decisiones separadas.

La siguiente capa es la sincronización. Hay que contrastar la base TIE, la actividad TIDE/TIRE, las colas, el número de vecinos y el disparador SPF. ThreeWay no corrige por sí solo una base incompleta.

Por último se sale del plano RIFT. RFC 9692 deja fuera cómo cada implementación programa el reenvío. El RIB, el FIB, los contadores del hardware y una prueba real de entrega son evidencias independientes. El estado de control explica una intención operativa; no reproduce el trayecto del paquete.

Un clear inicia trabajo

RFC 9719 incluye clear-neighbor y clear-all-neighbors. Una respuesta correcta indica que el dispositivo aceptó la acción. No afirma que la conexión se haya reconstruido ni que haya desaparecido la causa. La sección de seguridad advierte que el uso no autorizado puede forzar reconstrucciones repetidas y dañar la estabilidad.

Antes de limpiar, se captura el estado. Durante la acción, se limita el alcance. Después, se vuelven a comprobar LIE, ThreeWay, ofertas, TIE, SPF, instalación de rutas, reenvío en hardware y entrega. Reiniciar puede retirar estado obsoleto, pero también destruir la pista que explicaba el fallo.

La aportación operativa

RFC 9719 permite automatizar comprobaciones encadenadas: alertar por rechazos repetidos, esperar a ThreeWay antes de validar la base, relacionar un TIE con la duración SPF y comparar la configuración prevista con las ofertas observadas.

Lo que no permite es convertir un booleano local en el estado de toda la red. Su mayor aporte consiste en hacer legibles las fronteras de cada evidencia.