Resumen

  • El RFC 1863 daba la espera menor al servidor con menos clientes informados y lo hacía más probable ganador; nunca afirmó haber eliminado la carrera.
  • La lista de clientes informados expresaba qué servidor asumía enviar rutas, no qué había recibido, elegido, instalado o utilizado el cliente.
  • El cliente debía sustituir copias idénticas y el relevo debía caber dentro del Hold Time. El RFC 4223 cerró después la cuestión de adopción: no existían implementaciones del diseño específico.

Una decisión tomada con copias que podían llegar tarde

El RFC 1863 propuso en 1995 sustituir muchas sesiones directas BGP/IDRP por route servers. Varios servidores formaban un clúster y cada cliente mantenía sesiones con todos ellos. La redundancia exigía, sin embargo, que normalmente uno solo enviara la información completa.

Los servidores intercambiaban mensajes LIST con sus clientes informados. Cada uno guardaba la lista propia y una copia de la de cada compañero. Las ordenaba por cantidad de clientes y, en caso de empate, por dirección. Si un cliente nuevo no aparecía en ninguna, el servidor de posición N esperaba (N-1) × DelayGranularity.

La máquina menos cargada tenía la espera más breve y era la más probable en ganar. Al vencer su temporizador, volvía a leer todas las listas. Si otra ya contenía al cliente, no enviaba. Si seguía ausente, lo añadía a la propia lista, programaba su difusión y comenzaba las actualizaciones.

La operación reducía la ventana, no congelaba el mundo. Dos servidores podían iniciar el reloj con versiones distintas y llegar a conclusiones simultáneas. El RFC decía abiertamente que su conciliación no eliminaba por completo las carreras.

Menos conexiones no significaban menos estado

El route server debía retransmitir las rutas externas y sus atributos sin elegir la mejor para distribuir. El cliente aplicaba su propia política, como ante un vecino directo. La propuesta denominó peering virtual a esa relación.

El propio texto limitó el beneficio: bajaba la cantidad de conexiones que cada router fronterizo debía mantener, no el volumen de información de rutas almacenado en cada cliente. Una sesión central podía simplificar operación sin comprimir la evidencia necesaria para decidir.

Por ello conviene separar los recibos. El servidor recibió una ruta. Luego la retransmitió. El cliente la recibió, la comparó, quizá la seleccionó y quizá la instaló. Después el plano de datos pudo o no alcanzar el destino. Ninguna fase hereda automáticamente el resultado de la siguiente.

Informado era el verbo del servidor

Una entrada LIST no procedía del cliente. Decía que un servidor lo tenía bajo su responsabilidad de anuncio. No confirmaba una UPDATE concreta ni el estado de la tabla receptora.

La fase de inicio lo demostraba. Un servidor podía aceptar sesiones y procesar rutas entrantes, pero no enviaba actualizaciones hasta vencer un temporizador inicial —cinco minutos sugeridos— o recibir todas las conexiones y listas internas configuradas. Conectado no significaba todavía autorizado por el estado de coordinación para difundir.

Si la carrera producía dos emisores, el cliente debía contenerla. Ante una ruta con atributos completamente idénticos a otra llegada desde un servidor del mismo clúster, sustituía la copia previa sin generar un nuevo anuncio. Así reducía memoria duplicada y evitaba convertir el cambio de servidor en un flap.

La igualdad completa era una frontera crucial. Dos rutas al mismo prefijo con atributos distintos no eran el mismo objeto. La regla de sustitución tampoco certificaba que la ruta fuera válida o mejor; sólo hacía tolerable la repetición exacta.

El relevo era una reconstrucción condicionada

Al caer una sesión entre servidores, un superviviente examinaba la lista del compañero perdido. Consideraba cada cliente únicamente si aún conservaba una sesión directa con él y si ninguna lista activa lo reclamaba. Después repetía el proceso del cliente nuevo, incluida la espera y la segunda lectura.

No había un traspaso instantáneo de propiedad. El superviviente reconstruía responsabilidad a partir de observaciones incompletas. Sólo después de conciliar podía descartar la lista asociada a la sesión rota.

El RFC convirtió el tiempo disponible en una desigualdad. Hold Time entre servidores más DelayTimer máximo debía ser menor que dos tercios del Hold Time cliente más pequeño. Su ejemplo combinó 90 segundos en clientes, 30 entre servidores y una granularidad de 15 segundos para tres servidores.

Ese margen buscaba que el relevo terminara antes de que el cliente invalidara la sesión. Haber cumplido el cálculo no probaba que la tabla superviviente estuviera al día ni que el tráfico continuara. Medía el presupuesto, no el resultado.

Identificar al anunciante no era autenticarlo

El atributo ADVERTISER conservaba la dirección del router fronterizo que había entregado originalmente la ruta al servidor. Permitía al cliente aplicar política como si la actualización hubiese llegado directamente de ese router. Si faltaba, se suponía que el servidor era el anunciante.

La suposición pertenecía a la sintaxis del protocolo. El apartado de seguridad decía que el documento no discutía esas cuestiones. ADVERTISER no demostraba control de la identidad, autorización ni veracidad del prefijo.

RCID_PATH cumplía otra función entre clústeres: registrar identificadores recorridos y detener un retorno hacia un clúster ya presente. Se eliminaba antes de enviar a clientes que no eran servidores. Era memoria local contra bucles, no procedencia integral.

Una especificación sin observación operativa

La ficha del RFC Editor marca hoy el documento como Historic. El RFC 4223 afirmó en 2005 que no existían implementaciones del route server definido por RFC 1863 y que no se usaba como alternativa al full mesh.

La afirmación no se extendía a todos los route servers. El mismo RFC excluyó otros usos del término. Señaló route reflection, confederaciones y números AS privados como alternativas existentes. El RFC 2796 y el RFC 4456 describen reflectores que seleccionan mejor ruta y manejan otros atributos contra bucles; el RFC 3065 describe confederaciones.

Tampoco se debe convertir no implementado en refutado. La evidencia sólo permite decir que este diseño no acumuló experiencia de despliegue. Sus temporizadores describieron cómo debía cerrarse una carrera, pero nunca produjeron telemetría histórica capaz de demostrarlo.

El recibo final estaba fuera del temporizador

Una sesión mostraba conectividad de control. Una lista, una reivindicación de responsabilidad. La espera corta inclinaba la carrera. La segunda lectura evitaba parte del estado viejo. La sustitución protegía al cliente del duplicado. El Hold Time reservaba espacio para fallar y reasignar.

La continuidad útil requería todavía rutas actuales, selección correcta, instalación, resolución del siguiente salto y tráfico observado. La lección del RFC 1863 no es que la redundancia se automatiza con un temporizador, sino que un temporizador sólo vale cuando se conservan las demás superficies capaces de desmentirlo.

Fuentes