Resumen

  • La etiqueta externa de OSPF definida por RFC 1403 registraba si se había generado automáticamente, si la información era completa y si el camino tenía cero, uno o más componentes.
  • Ese campo no era un AS_PATH reducido. Una etiqueta manual era información local opaca y una automática solo conservaba clases de longitud.
  • Cuando el camino estaba truncado o debía llegar en un registro BGP separado, la ruta no podía reexportarse desde la proyección OSPF.

Traducir una ruta también era decidir qué olvidar

BGP y OSPF compartían destinos, pero no el mismo modelo. En el exterior, BGP llevaba una secuencia interdominio; dentro del AS, OSPF calculaba alcance, coste y siguiente salto. Un router de borde podía importar el anuncio y otro podía encontrar después esa ruta interna e intentar devolverla al exterior.

RFC 1403 puso una advertencia dentro de la propia proyección. De los 32 bits de la etiqueta externa OSPF, uno indicaba generación automática, uno la completitud y dos una clase de PathLength. Doce quedaban para un tag arbitrario y dieciséis para un número de AS.

La etiqueta describía el estado de la evidencia. No guardaba una secuencia arbitraria de sistemas autónomos.

Cuando Automatic valía cero, los 31 bits restantes eran LocalInfo configurado por el operador. Era el valor por defecto para mantener compatibilidad. El RFC ordenaba no inferir de ahí las características de la ruta. Solo con Automatic igual a uno adquirían Completeness y PathLength el significado común.

Eso no autenticaba nada. El documento dejó la seguridad fuera de su alcance. El bit explicaba cómo leer el registro; no demostraba que el router, la entrada o la política fuesen correctos.

La ausencia podía significar pérdida o espera

Una ruta local o un camino de un vecino todavía cabían en una representación limitada. Un camino más largo no.

Si ya se había truncado, la etiqueta solo podía decir «incompleto y de más de un tramo». Otro ASBR tenía prohibido reexportarlo a BGP. La especificación no convirtió el hueco en una licencia para inventar la secuencia.

Si el camino completo seguía existiendo, el remedio era distinto. OSPF transportaba la proyección de alcance, mientras BGP distribuía la historia íntegra entre los routers de borde del AS. El ASBR debía esperar esa actualización BGP antes de anunciar fuera. RFC 1403 llamó “out of band” a este segundo registro: no era un canal secreto de datos, sino otro protocolo que conservaba lo que el tag no podía expresar.

Un estado significaba evidencia destruida; el otro, evidencia disponible en otra autoridad. Ambos negaban que el resumen pudiese sustituir al original.

Estar en la tabla no concedía permiso de publicación

La prudencia también aparecía en los valores por defecto. Ninguna ruta OSPF debía salir a BGP sin una decisión explícita. Ninguna ruta BGP debía entrar en OSPF sin selección. El default route interno tampoco podía nacer sin configuración.

Aprender, importar y anunciar eran acciones separadas. La presencia de un destino en OSPF no demostraba que su procedencia BGP siguiera íntegra ni que el administrador quisiera divulgarla.

Las métricas tampoco se trataban como números intercambiables. El coste OSPF y el INTER-AS METRIC de BGP-3 tenían anchos y funciones distintas. RFC 1403 dejaba ausente por defecto la métrica opcional de BGP. Transformar un valor no transfería automáticamente su significado.

Para correlacionar registros, el BGP Identifier y el OSPF router ID de un equipo debían coincidir. Si varios ASBR introducían el mismo destino, el router anunciante tenía que identificar qué salida usaba realmente su ruta OSPF y asociarla con el camino exterior de ese ASBR.

En 1994, RFC 1745 actualizó el esquema para BGP-4 e IDRP, prefijos variables, conjuntos de caminos, MULTI_EXIT_DISC y LOCAL_PREF. Con salidas de igual coste podían combinarse caminos en un set. Sin embargo, la prohibición central sobrevivió: un camino truncado nunca debía reexportarse, y un camino completo demasiado largo para el tag debía llegar por BGP/IDRP antes de un nuevo anuncio.

La correspondencia entre Forwarding Address y NEXT_HOP evitaba saltos innecesarios. No probaba que un paquete fuese reenviado, que el destino respondiera o que una aplicación funcionara. Ruta fuente, importación, procedencia del tag, completitud, permiso de exportación, camino íntegro, anuncio, forwarding y resultado remoto son capas distintas.

RFC 1403 y RFC 1745 son hoy Historic. No documentan la práctica actual ni un incidente. Su límite sigue siendo útil: si un sistema declara que un registro está incompleto, debe retirar las facultades que requieren el dato ausente.

Fuentes

Estas fuentes prueban el estado documental, la semántica de los campos y las obligaciones descritas, no una adopción presente, autenticidad, forwarding correcto ni resultado de usuario.