Resumen

  • El IETF publicó a las 09:22:08 UTC del 19 de agosto la revisión 38 de su propuesta para recuperar topología inter-AS mediante BGP-LS. Frente a la revisión 37, el único cambio sustantivo del cuerpo elimina Multi-Topology Identifier, TLV 263, de la lista de descriptores del nuevo enlace.
  • MT-ID sigue existiendo en BGP-LS. Lo que cambia es la identidad propuesta para un Inter-AS Link NLRI, por lo que la evidencia decisiva será una migración sin objetos antiguos, emparejamientos rotos ni pérdida de aislamiento entre topologías.

Un controlador no ve un enlace físico. Ve identificadores recibidos en anuncios y decide cuáles describen dos mitades del mismo enlace. Por eso la desaparición de una sola línea puede importar más que varias páginas nuevas de explicación.

El historial de Datatracker registra la disponibilidad de la revisión 38 el 19 de agosto a las 09:22:08 UTC. La comparación de los textos oficiales 38 y 37 muestra una sola modificación técnica: ya no figura el TLV 263 en la lista adicional de descriptores del Inter-AS Link NLRI.

La propuesta parte de una limitación de la norma base. BGP-LS puede llevar la topología de un dominio IGP hasta un consumidor, como una aplicación SDN. Si un mismo operador divide su red en varios dominios y AS, el consumidor puede recibir cada mapa interno sin conocer los enlaces que los unen. El proyecto crea el tipo NLRI 7 para describir esa interconexión y añade campos para el AS remoto y el identificador IPv4 o IPv6 de su router fronterizo.

Cada dominio anuncia su mitad unidireccional. El consumidor debe unir los dos half-links para representar el enlace lógico antes de calcular una ruta de extremo a extremo. La calidad de esa unión depende de que productores distintos usen una identidad compatible.

La revisión 37 enumeraba identificadores local y remoto del enlace, direcciones de interfaz y vecino para IPv4 e IPv6, y por último MT-ID. La revisión 38 termina la lista con la dirección IPv6 del vecino. Conserva, justo después, una advertencia: otros TLV usados como descriptores pueden dificultar la correlación de las dos mitades cuando las implementaciones productoras difieren.

El alcance debe expresarse con cuidado. El RFC 9552 sigue definiendo Multi-Topology Identifier como TLV 263. En el Link NLRI ordinario, exige incluirlo cuando el enlace del IGP pertenece a una topología no predeterminada y generar un NLRI distinto para cada identificador. La revisión 38 también conserva MT-ID en su lista de información crítica dentro de las consideraciones de seguridad.

No se ha borrado, por tanto, la noción de topología múltiple del protocolo. Se ha retirado ese campo del conjunto propuesto para identificar el nuevo objeto inter-AS. Esa diferencia puede separar a un productor basado en la revisión 37 de otro basado en la 38: uno puede incorporar TLV 263 en la clave y el otro omitirlo.

La transición tiene una regla de higiene ya publicada. RFC 9552 obliga a retirar el NLRI antiguo cuando se añade, elimina o modifica uno de sus TLV. Si no se hace, pueden quedar objetos de estado de enlace duplicados e incoherentes. El riesgo es verificable en laboratorio; las fuentes actuales no documentan que haya ocurrido en una red operativa.

También falta alinear el registro. Consultado el 19 de agosto, el registro BGP-LS de IANA indicaba como última actualización el 7 de agosto, llamaba Stub Link NLRI al tipo 7 y remitía a la revisión 17. El proyecto 38 lo denomina Inter-AS Link NLRI. Los TLV 270, 271 y 272 tienen ya los nombres de número de AS remoto e identificadores del ASBR remoto, pero mantienen la referencia a la revisión 17.

La página de estado del documento explica el momento institucional. El texto aspira a Proposed Standard, está enviado al IESG y pasó de necesitar una revisión a AD Followup. La revisión de IANA volvió a Version Changed - Review Needed; la evaluación de expertos figura como satisfactoria. Ninguno de esos estados equivale a un RFC publicado.

El mapa que se intenta construir es además sensible. El documento habla de varios AS dentro del “jardín vallado” de una sola entidad y recomienda mantener allí los identificadores, direcciones y características del enlace o filtrarlos antes de que salgan. La visibilidad que ayuda a automatizar ingeniería de tráfico también puede revelar con precisión la estructura interna.

La lectura operativa es concreta. Antes de confiar en la revisión 38, una prueba debe observar la retirada del objeto anterior, la llegada de una única identidad nueva, la unión correcta de ambas mitades y la conservación de topologías no predeterminadas. Hasta que existan esas trazas, la revisión es una propuesta más precisa, no una capacidad demostrada.

Fuentes