Resumen

  • RFC 9815 permite que un fabric denso distribuya su topología mediante muchas menos sesiones BGP, pero la sesión con el reflector o controlador deja de ser la prueba de vida de cada enlace representado.
  • La arista que SPF utiliza necesita dos relatos direccionales compatibles, una fuente autorizada, orden y estado válidos, preparación EoR cuando se exige, un cálculo local y una comprobación posterior en el plano de reenvío.
  • El ahorro de sesiones no debe pagarse con una autoridad opaca: quien detecta, quien origina, quien replica y quien decide retirar una ruta son funciones distintas aunque un mismo producto las empaquete.

El ahorro cambia el lugar de la prueba

Un fabric Clos puede ofrecer decenas de caminos de igual coste entre niveles. Ejecutar una sesión BGP en cada enlace hace que el número de sesiones y de copias de cada anuncio crezca con esa malla. La RFC 9816 describe una alternativa: mantener solamente suficientes sesiones para que la distribución sea redundante, incluso mediante reflectores o controladores, y dejar que cada nodo calcule la topología completa.

Ese diseño resuelve una carga, pero desplaza una función. En el modelo de sesión EBGP de un salto por enlace, el estado de la sesión ayuda a declarar disponible ese mismo enlace. En el peering entre loopbacks o en el modelo disperso, una única sesión puede transportar afirmaciones sobre varios enlaces que no recorre. Su estado solo demuestra la conectividad de su propio camino de control.

La RFC 9815 lo dice sin ambigüedad: en esos modelos, el descubrimiento de la conexión directa y la detección de vida ocurren fuera de BGP. Recomienda BFD, no porque BFD sea una verdad absoluta, sino porque está diseñado para detectar fallos en el trayecto entre motores de reenvío. El operador puede elegir otros mecanismos. Lo que no puede elegir honestamente es dejar sin nombre al testigo.

Cuando una sesión hacia un reflector está Established y una interfaz del fabric está muerta, no hay contradicción. Son caminos diferentes. Un cuadro de mando que colorea la arista por el estado del reflector mezcla el mensajero con el hecho que transporta.

La cadena mínima de una arista

Conviene leer el diseño como una cadena de custodia:

  1. Un mecanismo con alcance conocido observa una dirección del enlace.
  2. El nodo local decide que esa observación autoriza una Link NLRI.
  3. El registro identifica al nodo local, al remoto, al enlace, a la familia y a la métrica.
  4. Una secuencia estrictamente creciente ordena sus versiones y un estado SPF puede marcarlo como no alcanzable.
  5. Uno o varios pares distribuyen el objeto; pueden hacerlo antes de ejecutar su propio SPF.
  6. El consumidor busca en el nodo remoto un anuncio que apunte de vuelta y forma una arista bidireccional.
  7. El router calcula desde sí mismo, cambia Local-RIB y GLOBAL-RIB y programa el reenvío.
  8. Una observación del plano de datos comprueba el efecto desde puntos definidos.

Cada eslabón tiene un dueño y una posibilidad de fallo. BFD puede estar unido al trayecto equivocado. El originador puede usar una identidad remota imprecisa. El reflector puede portar una copia vieja. El consumidor puede excluir un atributo mal formado. El SPF puede programarse con retraso. La FIB puede aplicar parcialmente el cambio. La sonda puede medir un único ingreso y no otro.

La secuencia de 64 bits no borra esas diferencias. RFC 9815 exige que aumente con cada versión auto-originada y que su monotonicidad sobreviva, por los medios disponibles, a la vida del equipo. Los receptores prefieren normalmente la versión mayor. Las reglas para vecinos directos permiten corregir estado antiguo tras un arranque frío.

Eso prueba precedencia, no exactitud. Un sensor mal asociado puede producir la mentira más nueva. Un par autenticado pero comprometido puede emitir una topología manipulada con una secuencia impecable. Por ello, el recibo operativo debe guardar origen, contenido, camino de recepción y evidencia de la observación, no solo el número final.

El reflector tiene poder de distribución, no de percepción

En RFC 9815, cada NLRI de enlace o nodo lleva descriptores que señalan un origen local. Si dos hablantes originan la misma NLRI, la especificación lo trata como posible error de configuración o ataque de suplantación. El reflector selecciona y retransmite; no debería renombrarse como autor para simplificar un inventario.

Esta limitación sigue vigente aunque la sesión use TCP-AO. La autenticación ayuda a saber con qué par BGP se mantiene el canal. No demuestra que ese par esté libre de compromiso, que haya observado la interfaz correcta o que el enlace remoto transporte. La propia RFC advierte que un par autorizado comprometido puede anunciar nodos, enlaces o prefijos modificados, causar rutas erróneas o provocar cálculos SPF excesivos.

La distinción tiene una consecuencia institucional. Si el controlador recibe telemetría, origina anuncios en nombre de nodos, los refleja y aprueba su retirada, concentra observación, escritura, difusión y veto. Esa arquitectura puede funcionar, pero debe declarar la concentración y ofrecer controles independientes. Presentar cuatro poderes como «la plataforma conoce la topología» impide atribuir un fallo.

EoR: terminar de aprender antes de atraer tráfico

End-of-RIB no es un latido. En BGP-LS-SPF puede exigirse el marcador EoR antes de anunciar el enlace asociado con un par. Si la implementación ofrece esa configuración, debe ser coherente en el dominio; activada, la espera por defecto es indefinida, aunque puede existir un máximo configurable.

La finalidad es evitar que un nodo atraiga tráfico antes de poseer el estado inicial necesario para reenviarlo. Una política desigual de EoR puede crear microbucles y descartes temporales. En el ejemplo de topología con controlador, este puede esperar el EoR de ambos nodos y los dos anuncios direccionales antes de liberar el enlace.

Ese conjunto mejora la evidencia de preparación, pero todavía no atestigua vida física. Un EoR recibido a las 10:00 no dice que la óptica siga transmitiendo a las 10:01. Dos Link NLRI dicen que ambos extremos publicaron relatos compatibles; no dicen que una carga útil haya cruzado. El control de calidad necesita estados diferentes para aprendizaje completo, observación del enlace, consenso de extremos y prueba de datos.

Los dos sentidos tienen que describir la misma arista

SPF no debería caminar por una flecha solitaria. El algoritmo busca una Link NLRI del nodo remoto que regrese al nodo actual. En enlaces numerados cruza la dirección de interfaz de un extremo con la dirección vecina del otro. En enlaces no numerados utiliza identificadores Local/Remote y un descriptor de familia de direcciones.

Sin ese descriptor de familia, el enlace no participa ni en el SPF IPv4 ni en el IPv6. Puede anunciarse uno por familia. Si no se conoce el identificador remoto, se usa cero como comodín. Es una salida interoperable, pero en enlaces paralelos puede crear periodos donde los extremos no estén de acuerdo sobre cuál está operativo. Por eso la sección de gestión recomienda descubrir o configurar el identificador remoto.

El Erratum 8835 verificado corrige la condición recíproca de la sección 6.3. El original repetía que Remote actual debía coincidir con Local remoto. La segunda igualdad correcta enlaza Local actual con Remote remoto. Es la diferencia entre comprobar dos veces un extremo y cerrar el par completo.

No hay evidencia de que un fabricante siguiera la frase duplicada ni de que causara un incidente. La corrección sí sirve para diseñar pruebas: intercambiar los identificadores, introducir cero en una pareja paralela y demostrar qué arista termina en el grafo. El EID 8836, por su parte, solo alinea TIME_TO_LEARN_INTERVAL con la terminología de RFC 8405. Una evaluación seria no suma ambas correcciones como si tuvieran idéntico efecto.

Una retirada no debe esperar a que desaparezca la última copia

La replicación dispersa deja versiones del mismo enlace por varios caminos. Si el origen se limita a retirar su anuncio, una copia positiva vieja puede sobrevivir hasta que se elimine la última ruta seleccionada. RFC 9815 propone una negación más rápida: originar una versión nueva con SPF Status de enlace no alcanzable y, después de un intervalo, retirarla. Sugiere dos segundos para LinkStatusDownAdvertise.

La nueva secuencia permite que el estado negativo gane a las copias positivas antiguas. Cuando el enlace vuelve dentro de la ventana, otra versión más nueva elimina el estado Down. El receptor actuará en su siguiente cálculo SPF.

Dos segundos no son una garantía de restauración. Entre el cambio físico y el paquete recuperado están el detector, la creación del anuncio, la cola de distribución, el back-off SPF, la instalación y la convergencia del hardware. La misma RFC recomienda registrar el NLRI disparador, el momento programado, el inicio y el fin del cálculo, el estado de back-off y contadores. Un programa de adopción debe añadir los tiempos del detector, la recepción por consumidor, el diff de FIB y sondas.

El protocolo conserva objetos que no permite usar

Hay un límite especialmente útil para las herramientas de observación. Si un UPDATE pierde el atributo BGP-LS por el tratamiento de errores, la NLRI puede conservarse y propagarse, pero no debe entrar en SPF. Si un TLV de estado o de familia está mal formado, el objeto se trata como retirado. Por tanto, «recibido por BGP» y «elegible para el LSDB» son campos diferentes.

La pérdida de sincronización también tiene su propio acto. Salvo que exista otro mecanismo de resincronización, debe reiniciarse la sesión y enviarse la notificación definida. La detección de esa pérdida queda fuera del alcance. Quien compra una implementación debe preguntar cómo compara generaciones, cuándo declara divergencia y qué evidencia conserva antes del reset.

La separación entre familias ayuda a contener daños. RFC 9815 recomienda, en escenarios comunes, instancias o sesiones separadas para BGP-LS-SPF y otras AFI/SAFI. El underlay resuelve next hops para servicios superiores; compartir indiscriminadamente el mismo fallo operativo aumenta el radio de impacto.

Prueba de aceptación para una topología dispersa

El laboratorio debe tener un grafo de sesiones diferente al grafo físico, enlaces paralelos no numerados y más de un reflector. Primero se fija una línea base: detectores asociados, NLRI de ambos sentidos, secuencias, EoR, huellas LSDB iguales, resultados SPF y tráfico por cada miembro esperado.

Después se rompe un sentido sin tocar la sesión al reflector. El operador demuestra, con tiempos, que cambia el detector correcto; que solo el originador autorizado aumenta la secuencia; que el estado Down vence a las copias viejas; que el enlace inverso deja de emparejar; y que el next hop sale de la FIB. La recuperación usa una versión posterior y vuelve a medir datos.

Las variaciones obligatorias incluyen descriptor de familia ausente, métricas discordantes, identificadores cruzados, comodín cero, EoR tardío, atributo descartado, origen duplicado, reinicio en frío, desincronización y pérdida de un reflector. También debe filtrarse una NLRI en solo una parte del dominio: RFC 9816 avisa de que conjuntos distintos producen tablas distintas y pueden inducir destinos inaccesibles o bucles.

El resultado no es un informe «pass/fail» general. Es un libro de juntas: evento físico, alcance del detector, identidad del enlace, origen, huellas de NLRI, secuencia, estado, pares recorridos, EoR, razón de admisión, generación LSDB, tiempos SPF, cambios RIB/FIB y tráfico observado. Otro equipo debe poder reconstruir la decisión sin consultar la memoria del proveedor.

Lo que las fuentes no permiten afirmar

Ni RFC 9815 ni RFC 9816 documentan una implantación nominada, una tabla de soporte comercial, una medición universal de convergencia, una caída o un ataque real. Las mejoras descritas son propiedades previstas del diseño. La adopción voluntaria sigue necesitando pruebas locales.

Tampoco existe un único peering disperso correcto. La redundancia del grafo, el método de vida, los filtros, las métricas, la ubicación de controladores y los temporizadores son decisiones del operador. Esa es una virtud de una especificación inicial mínima: el estándar coordina lo imprescindible sin convertir una arquitectura en mandato. Pero la libertad local no transfiere la responsabilidad al RFC.

Fuentes

  1. Registro Datatracker de RFC 9815
  2. Historial de RFC 9815
  3. RFC 9815
  4. Errata de RFC 9815
  5. Versión informativa con errata incorporada
  6. RFC 9816
  7. RFC 9552: BGP-LS
  8. RFC 4271: BGP-4
  9. RFC 5880: BFD
  10. RFC 4724: End-of-RIB
  11. RFC 8405: espera progresiva de SPF
  12. RFC 7606: errores en BGP UPDATE
  13. RFC 5925: TCP-AO
  14. Heng Lu: Running-Code Primacy
  15. Heng Lu: Minimum Initial Specification
  16. Heng Lu: On Reality Layers
  17. Referencias formales de RFC 9815
  18. Documentos que citan RFC 9815
  19. Ficha informativa de RFC 9815
  20. Ficha informativa de RFC 9816