Resumen

  • RFC 9815 hace de la alcanzabilidad y de la aptitud para tránsito dos hechos de aceptación independientes. Si un Node NLRI vuelve a anunciarse sin el TLV SPF Status que antes llevaba valor 2, el estado anterior queda implícitamente retirado y el nodo vuelve a ser elegible para tránsito; eso no prueba que ningún flujo vaya a atravesarlo.
  • La aceptación posterior a un reinicio necesita separar intención anunciada, resultado del cálculo y comprobación de tráfico. RFC 9816 permite usar la visibilidad de topología para gestión y menciona la verificación del camino de datos como capacidad adicional; una prueba negativa solo respalda los flujos definidos y el momento en que fueron probados.

En una revisión hipotética de puesta en servicio, las dos columnas pueden terminar así:

Hecho de aceptación Resultado
Alcanzabilidad del servicio Aprobada. Los prefijos de servicio siguen siendo alcanzables en las comprobaciones definidas.
Intención de no tránsito Sin evidencia superviviente tras el reinicio. No se ha confirmado que el Node NLRI vuelva a llevar SPF Status 2.

La primera celda no rescata la segunda. El RFC 9815 es un documento Standards Track y define que todos los routers de un dominio BGP-SPF anuncian incondicionalmente su Node NLRI. El TLV opcional SPF Status para ese Node NLRI es precisamente lo que modifica cómo debe tratarse el nodo en el cálculo. Según la sección 5.2.1.1, si el TLV no está presente, el nodo se considera activo y disponible para tráfico de tránsito.

Ese detalle convierte una ausencia en semántica operativa. Si antes se recibió un Node NLRI con un SPF Status y una versión posterior llega sin ese TLV, el estado anterior se considera implícitamente retirado. Para un nodo que había estado en estado 2, la consecuencia protocolaria es que desaparece la restricción de no tránsito. No hay que confundir esa consecuencia con una afirmación más fuerte. La ausencia devuelve al nodo al conjunto de opciones que el SPF puede considerar para tránsito; no obliga al algoritmo a seleccionarlo y mucho menos demuestra que un paquete concreto lo atraviese.

Estado 2: alcanzable no significa expandible para tránsito

La sección 6.3 de RFC 9815 permite precisar la diferencia sin convertirla en una metáfora. En el paso 3 del cálculo, un nodo con estado 1 se ignora como nodo inalcanzable. En el paso 4, una vez que el nodo actual es alcanzable, se consideran sus prefijos. En el paso 5, si ese nodo actual tiene estado 2, no se expanden sus Link NLRIs salientes para construir tránsito a través de él.

Por eso el valor 2 no equivale a “nodo apagado”. El nodo y sus prefijos pueden seguir siendo alcanzables mientras el algoritmo evita usar sus enlaces salientes para continuar el árbol SPF a través de ese nodo. Es una restricción estrecha y verificable en el mecanismo definido por la norma. También explica por qué una comprobación de servicio puede pasar sin decir nada concluyente sobre la persistencia de la intención de no tránsito.

El estado 1 tiene una semántica distinta: nodo inalcanzable respecto de BGP SPF. El estado 2 significa nodo que no admite tráfico de tránsito respecto de BGP SPF. Los valores 3–254 están sin asignar; un valor desconocido se propaga, pero se ignora en el cálculo SPF, y una implementación puede registrarlo para análisis. Los valores 0 y 255 están reservados. Para el SPF Status de Node NLRI, un valor reservado vuelve malformado ese NLRI y activa el tratamiento treat-as-withdraw descrito en RFC 9815 §7.1.

La omisión cambia elegibilidad, no demuestra uso de camino

Ésta es la frontera que una revisión operativa necesita conservar. Tras un reinicio, un Node NLRI sin SPF Status 2 ya no contiene la señal que impedía la expansión de enlaces salientes. De ahí se puede inferir que el nodo ha recuperado elegibilidad de tránsito en el cálculo. No se puede inferir, solo a partir de esa omisión, que vaya a ser seleccionado en un camino.

La elección sigue dependiendo de la topología visible al cálculo, de las métricas aplicables y del SPF resultante. Después existe otra frontera: qué rutas quedan efectivamente instaladas en el estado de reenvío. Y todavía queda una tercera: si los flujos concretos que interesan siguen o no el camino que el equipo esperaba. La aceptación rigurosa no colapsa esas capas en una sola luz verde.

Esta distinción también evita un error de lenguaje frecuente en las revisiones de cambio: llamar “restauración de tránsito” a la mera desaparición del valor 2. Lo que el protocolo restaura es la posibilidad de ser tratado como nodo de tránsito. El uso efectivo requiere condiciones adicionales. Una formulación prudente es, por tanto, “elegibilidad restaurada”; cualquier afirmación sobre tráfico observado necesita evidencia del plano correspondiente.

RFC 9816 limita el caso de uso, no inventa motivos

El RFC 9816 acompaña a RFC 9815 con consideraciones de uso y aplicabilidad. Su sección 7 ofrece dos aplicaciones concretas de la capacidad de nodo no tránsito. Una es un servidor que hace accesibles servicios de aplicación en el dominio BGP-SPF sin querer actuar como router. La otra es un controlador residente en un servidor que debe ser alcanzable directamente en todo el dominio sin transportar tránsito.

Eso es todo lo que esas líneas autorizan a afirmar. No demuestran que una red determinada use la capacidad. Tampoco definen el estado 2 como señal de mantenimiento, sobrecarga o degradación. Esos significados adicionales podrían existir como decisiones locales, pero no deben atribuirse a RFC 9816 sin evidencia independiente.

La diferencia importa en gobernanza técnica porque el motivo operativo y la semántica de protocolo son capas distintas. El protocolo dice qué hace el valor. El operador decide por qué lo aplica. Una revisión posterior necesita saber cuál de esas dos afirmaciones está comprobando, especialmente cuando el reinicio puede conservar la alcanzabilidad positiva mientras pierde la restricción negativa.

Dos registros IANA, dos preguntas diferentes

La identificación de los números también exige precisión. RFC 9815 §8.2 y el registro de BGP-LS Parameters de IANA sitúan el código 1184 como SPF Status dentro de los TLV de BGP-LS. Por separado, RFC 9815 §8.3 y el registro BGP Shortest Path First de IANA enumeran los valores de estado de Node NLRI: 0 reservado, 1 inalcanzable, 2 no tránsito, 3–254 sin asignar y 255 reservado.

No son la misma tabla ni responden a la misma pregunta. Una identifica el tipo de TLV; la otra define el espacio de valores para el estado de nodo. Mantener esa separación evita atribuir los códigos a una página IANA más general que no es la fuente de estas asignaciones.

Visibilidad y verificación del camino no son la misma evidencia

La sección 5.5.2 de RFC 9816 explica que los anuncios BGP-LS-SPF pueden utilizarse para construir visibilidad de la topología con fines de gestión, resolución de problemas y comprobaciones de consistencia. Añade que un controlador central u otra herramienta de gestión también podría utilizarse para verificación del camino de datos, dejando los algoritmos y heurísticas concretos fuera de alcance.

Ese “también” es operativo: ver la topología no equivale por sí mismo a probar el trayecto de los paquetes. Y una verificación de tráfico tampoco produce una negación universal. Si se prueban determinados flujos, desde determinados orígenes hacia determinados destinos y en un intervalo definido, un resultado negativo respalda únicamente ese conjunto y ese momento. Puede ser una evidencia fuerte para una aceptación bien acotada; no demuestra que ningún otro flujo, en ningún otro instante, haya usado el nodo como tránsito.

Para la revisión de puesta en servicio, la consecuencia es directa. El éxito de un servicio responde a “¿puedo alcanzar esto?”. La persistencia del estado 2 responde a “¿sigue anunciado el límite de no tránsito?”. El SPF y el estado instalado responden a “¿qué eligió el sistema para reenviar?”. Las pruebas de flujo responden a “¿qué ocurrió para estas trayectorias observadas?”. Son preguntas vinculadas, pero ninguna sustituye automáticamente a las demás.