Resumen

  • RFC 9494 permite conservar determinadas rutas después del intervalo normal de Graceful Restart, con una Long-Lived Stale Time distinta para cada AFI/SAFI; LLGR_STALE las identifica y las sitúa por debajo de toda ruta no degradada.
  • Enke Chen figura entre los autores de RFC 4724 y RFC 9494. La extensión no acredita que el reenvío siga sano: el receptor limita el tiempo, NO_LLGR excluye rutas, End-of-RIB cierra la sincronización y los riesgos de bucle o agujero negro condicionan el uso.

Un dato antiguo todavía puede mover paquetes

La caída del canal de control y la caída del plano de reenvío son sucesos relacionados, no idénticos. Un proceso BGP puede reiniciarse mientras el hardware conserva nexos, etiquetas o túneles. Si el vecino borra todo de inmediato, una avería del control puede propagarse hacia servicios que aún tenían un camino funcional. Si conserva todo sin fecha, el estado antiguo puede ocultar una pérdida real durante horas.

La dificultad aumentó a medida que BGP dejó de transportar únicamente alcance unicast convencional. En redes tunelizadas, el camino interno de un paquete puede no depender del mismo salto que muestra la sesión perdida. En VPN, descubrimiento o señalización, la información distribuida por BGP se parece a veces más a estado operativo que a una instrucción directa de siguiente salto. Cada familia tiene una relación distinta entre silencio de control y validez de reenvío.

Por eso el problema no se resuelve preguntando si la conservación es buena. Hay que preguntar qué afirmación se conserva, quién soporta el error, cuánto envejecimiento acepta y qué señal la elimina. LLGR es útil precisamente porque no responde esas preguntas con una única duración mundial.

El límite breve de Graceful Restart

RFC 4724, publicada en 2007, tiene como autores a Srihari Sangli, Enke Chen, Ramachandra Fernando, John Scudder y Yakov Rekhter. Define la capacidad Graceful Restart y el marcador End-of-RIB. El hablante que reinicia puede preservar estado de reenvío; su vecino puede retener las rutas aprendidas, marcarlas stale y esperar la reconstrucción de la sesión.

La espera normal está acotada en el propio formato. Restart Time ocupa doce bits y, por tanto, no puede codificar más de 4.095 segundos. RFC 4724 recomienda un valor predeterminado no superior al HOLDTIME del mensaje OPEN. Si la sesión no vuelve, el receptor elimina lo retenido; si descubre antes que el reenvío del par ya no funciona, puede retirarlo sin agotar el reloj.

Durante esa ventana, la ruta stale no pierde preferencia. Se evita el churn suponiendo que la recuperación será corta. RFC 8538 amplió posteriormente los tipos de cierre que pueden usar el procedimiento y creó Hard Reset para solicitar la limpieza completa. Ninguna de esas mejoras convierte una pausa de control en prueba de alcance.

Una segunda fase con menos autoridad

RFC 9494, publicada en noviembre de 2023, está firmada por James Uttaro, Enke Chen, Bruno Decraene y John G. Scudder. La coautoría de Chen en la norma base y en la extensión es un hecho verificable dentro de dos resultados colectivos de la IETF; no lo convierte en inventor único ni demuestra el comportamiento de ningún producto.

La capacidad LLGR usa el código 71 y contiene tuplas <AFI, SAFI, Flags, LLST>. Cada familia de direcciones puede anunciar su propia Long-Lived Stale Time. La norma no propone un valor predeterminado, porque conservar alcance unicast, señalización o datos de VPN no presenta la misma exposición. El receptor puede aplicar un mínimo, un máximo o ambos, y reducir el valor recibido.

LLGR necesita que el vecino anuncie también Graceful Restart. Sin esa capacidad acompañante, se ignora. Cuando ambos periodos son positivos, primero opera GR sin cambiar la preferencia y después comienza LLGR. Un Restart Time de cero omite la primera fase. La transición no sólo añade segundos: cambia la valoración del dato.

Durante el periodo ordinario, la red concede una breve presunción a un estado que espera refrescar pronto. En la fase larga, esa presunción ya no basta. La ruta sobrevive, pero pierde su lugar frente a nueva evidencia.

LLGR_STALE evita que la duda desaparezca

Al comenzar LLGR, el helper pone en marcha un LLST por AFI/SAFI y añade la comunidad bien conocida LLGR_STALE, cuyo valor es 0xFFFF0006. Esa ruta debe considerarse menos preferida que cualquier opción que no sea least preferred. Si sólo quedan candidatos degradados, los criterios normales vuelven a ordenar entre ellos.

La consecuencia es intencionada. Una alternativa fresca desplaza el camino antiguo. Si no hay ninguna, la ruta stale puede seguir siendo best path y mantener el servicio. El mecanismo conserva una última posibilidad, no una afirmación de salud.

La etiqueta debe viajar con la ruta. No debería anunciarse a un vecino que no haya ofrecido capacidad LLGR, salvo la opción restringida a pares internos o de una confederación. Si se propaga, no puede quitarse LLGR_STALE. El siguiente receptor necesita saber que el origen de control permanece ausente; de otro modo, la incertidumbre se blanquearía en cada salto.

La comunidad NO_LLGR, valor 0xFFFF0007, expresa el límite contrario. Una ruta marcada así no puede conservarse con el procedimiento largo y debe desaparecer según BGP normal. El emisor puede declarar que cierta información no debe sobrevivir; la política local del receptor puede imponer la misma exclusión. Capacidad común y consentimiento por ruta no son lo mismo.

Volver a hablar no equivale a ponerse al día

Cuando la sesión se restablece, el LLST no recibe automáticamente una vida nueva. La sincronización de una familia termina con End-of-RIB o con el límite de aplazamiento de selección. Si el reloj vence antes de que una ruta sea refrescada, el helper elimina ese estado. Los reinicios consecutivos tampoco deben encadenar periodos completos para un dato que nunca fue confirmado.

También se pierde la excepción si el par regresa sin las capacidades necesarias, omite una AFI/SAFI o no acredita la conservación del estado donde corresponde. La norma diferencia tres momentos: contacto recuperado, información reenviada y sincronización terminada. Sólo el primero pertenece a la sesión.

Uno de los ejemplos usa un segundo de Restart Time y 3.600 segundos de LLST. Al terminar el primer segundo, las rutas reciben LLGR_STALE y bajan de rango. Sin respaldo, el borde continúa usándolas y las reanuncia a un par externo capaz. Al expirar LLST, las borra y envía retiradas. Si la resincronización termina a los 180 segundos, las rutas frescas pierden la marca. Si el par externo nunca anunció LLGR, recibe la retirada al comenzar la fase larga.

El prefijo más específico no lee comunidades

La primera advertencia surge de la relación entre selección BGP y búsqueda IP. LLGR_STALE rebaja un camino frente a otro para el mismo prefijo. Pero una ruta stale más específica sigue capturando el tráfico antes que una ruta fresca menos específica. Puede existir una salida aparentemente sana en la tabla y, aun así, los destinos del prefijo estrecho caer en un agujero negro.

La segunda advertencia es una posible divergencia interna. RFC 9494 muestra dos routers que terminan prefiriendo salidas distintas cuando uno degrada la ruta antigua y otro aún la considera atractiva. Los paquetes circulan entre ellos. GR ordinario puede producir incoherencias breves; un estado long-lived hace que el defecto sea persistente.

De ahí la regla cardinal: no se recomienda LLGR para rutas usadas en reenvío hop-by-hop dentro de un AS. Los túneles, como MPLS, eliminan algunos bucles de este tipo; la información BGP que no programa directamente el siguiente salto también reduce la exposición. Reducir no significa anular. Los bits de Forwarding State deben reflejar estado realmente preservado y los límites deben proceder del dominio de fallo real.

En VPN, el tiempo de las etiquetas añade otra frontera. Tras retirar una ruta, su etiqueta podría asignarse a otro contexto. Si una copia stale sigue viva, el mismo número ya no designa el mismo destino. Antes de activar LLGR para una familia VPN, el mínimo de reutilización de etiquetas debería superar el máximo de LLST. El reloj protege aquí la separación entre clientes.

La norma describe; el receptor decide

El texto de Lu Heng sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria permite leer la extensión con una distinción posterior. El núcleo compartido define capacidad, alcance por familia, marca de degradación, señal de exclusión, menor preferencia y caducidad. El operador conserva las elecciones que sólo su red puede responder: pares admitidos, tope temporal, uso de túneles, ciclo de etiquetas y disparadores de retirada.

Así, interoperabilidad no se convierte en una orden central de conservar. Tampoco permite que una política local quite la marca y presente lo antiguo como actual. El estado tiene un significado común; aceptar su riesgo sigue siendo una decisión del receptor.

La primacía del código en funcionamiento exige observar las tuplas negociadas, el LLST recibido y el aplicado, cuántas rutas entran y salen, qué best path cambia, qué vecino recibe una retirada, cuándo llega End-of-RIB, si aparecen pérdida o bucles y si la limpieza final es completa. Esta es la aplicación analítica posterior de Sofia Ren a partir de Lu Heng, no una intención privada atribuida a Chen o a los autores de la RFC.

RFC 9494 no es valiosa porque haga inmortal una ruta. Es valiosa porque obliga a llamarla stale durante el tiempo prestado. En esa palabra se concentra la disciplina: persistir sin fingir actualidad, servir sólo como última opción y desaparecer cuando ya no queda evidencia suficiente.

Fuentes