Resumen

  • RFC 1222 propuso dos entidades lógicas en un equipo: una dentro del IGP del abonado y otra en el IGP del backbone, conectadas mediante EGP o BGP.
  • La organización NSFNET y el proveedor de la red conectada conservaban responsabilidades separadas por la integridad de sus datos y por sus configuraciones.
  • Una sesión local y dos procesos activos no demostraban tablas correctas en el kernel, aislamiento de fallos, reenvío ni llegada al destino.

La unidad aparente había propagado demasiadas cosas

RFC 1222 fue publicado por H-W. Braun y Y. Rekhter en mayo de 1991 para simplificar el acceso al backbone NSFNET. El RFC Editor lo cataloga como Informational y el IETF Datatracker lo conserva en el flujo Legacy. El propio texto niega que sea un estándar de Internet.

En la primera fase de NSFNET, los routers Fuzzball del backbone usaban Hello, las redes intermedias solían usar RIP y gated traducía entre ambos. El conjunto parecía un único sistema. Esa apariencia permitía que cambios de métrica viajaran por varias administraciones; con más conexiones y pocas herramientas de aislamiento, también facilitaba inestabilidad y bucles.

La fase T1 separó con fuerza el IGP del backbone de los IGP de los clientes. RFC 1093 documentó la interfaz; RFC 1092 añadió acuerdos, una base de políticas y controles sobre representaciones no autorizadas. EGP reducía la exportación de fluctuaciones internas y permitía ingeniería de rutas. No convertía cada anuncio en verdad ni probaba el trayecto de un paquete.

La separación correcta no exigía dos máquinas

El modelo imponía un costo: cada abonado mantenía un peer propio que participaba en su IGP y hablaba EGP o BGP con el nodo NSFNET. Al crecer hacia muchos sitios pequeños, esa caja y la experiencia necesaria podían encarecer innecesariamente una frontera útil.

RFC 1222 identificó la condición mínima: dos entidades lógicas. Una pertenecía al entorno de routing del abonado y otra al del backbone. Entre ellas debía continuar un mecanismo interdominio. Podían ejecutarse como dos daemons en el mismo nodo Unix y comunicarse por loopback o IPC.

El BGP de RFC 1163 intercambiaba alcanzabilidad entre sistemas autónomos. Usarlo dentro de una máquina no volvía internas las autoridades que representaba. La distancia física era cero; la distancia administrativa seguía existiendo.

El kernel común no era una frontera automática

El memo advirtió que había que impedir interacciones simultáneas indeseadas de los dos daemons con el kernel. Una sola tabla de reenvío, interfaces comunes o un reinicio podían unir los destinos operativos de procesos dibujados como separados.

Por eso cada afirmación necesita su registro. Proceso iniciado no equivale a sesión establecida. Sesión establecida no equivale a ruta aceptada. Ruta aceptada no equivale a instalación en el kernel. Tabla instalada no equivale a reenvío, y reenvío local no equivale a alcanzabilidad final.

La propuesta conservaba firewalls fuertes entre IGP y exigía etiquetar la información con contexto exterior al cruzar. Una etiqueta preservaba procedencia, pero no autenticaba por sí sola el anuncio ni garantizaba que la política posterior fuera correcta.

Cada configuración seguía hablando por su dueño

El control debía distribuirse. NSFNET y el proveedor conectado respondían cada uno por la integridad de su información. El cliente regional podía entregar la configuración del daemon que participaba en su IGP y así controlar lo que se introducía en su dominio.

La conexión Ethernet seguía siendo el punto de demarcación administrativo y operativo. Un chasis común no autorizaba al operador del backbone a certificar el estado interno del abonado, ni al abonado a inferir el forwarding del backbone. Asignar responsabilidad tampoco demostraba que se hubiera cumplido.

En la alternativa de largo plazo, el límite se movía hacia la nube C-NSS y dos administraciones compartían la gestión del medio hacia el E-NSS. PPP y mejores herramientas de líneas serie podían ayudar, pero la diversidad de equipos dificultaba localizar un fallo. La luz verde del enlace no identificaba a su responsable ni demostraba servicio.

RFC 1222 convirtió una reducción de hardware en una prueba de disciplina: consolidar lo físico sin comprimir las capas de evidencia que mantienen separadas procedencia, decisión, instalación, transferencia y resultado.

Fuentes