La red necesita saber cómo volver.

Imaginemos varias oficinas conectadas mediante equipos de red. Entre algunos puntos se instalaron enlaces alternativos para evitar que la rotura de un cable dejara sin comunicación a todos los usuarios. La decisión parece razonable hasta que, en determinadas redes Ethernet, esa redundancia permite que ciertas tramas vuelvan a pasar por lugares que ya recorrieron.

Los bucles pueden multiplicar el tráfico y provocar saturación. También vuelven inestables las tablas con las que los dispositivos aprenden dónde están las direcciones de la red. Una precaución destinada a mejorar el funcionamiento termina exponiendo a toda la infraestructura a una falla grave.

En los años ochenta, con la expansión de las redes locales, hacía falta organizar esos vínculos sin revisar manualmente cada cambio. Perlman diseñó un algoritmo que permite a los puentes —bridges— intercambiar información y construir un árbol de expansión: una topología activa sin ciclos que conserva la conectividad y mantiene otros enlaces disponibles como respaldo.

Su elegancia está en la distribución del trabajo. Los componentes ejecutan reglas locales, comparten cierta información y convergen hacia una organización común. No necesitan un administrador que conozca y reordene cada conexión en cada momento.

Me quedo con esa incomodidad que también aparece en el software: agregamos una alternativa para volver más robusto un sistema y descubrimos que esa alternativa también debe ser gobernada. Tener muchos caminos posibles sirve de poco cuando sus interacciones pueden bloquear el conjunto. La redundancia necesita una política; esa es la lección que me llevo.

En 1985, Perlman publicó «An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN». El título describe con rigor la tarea: construir de manera distribuida una topología sin ciclos en una red local extendida cuyas conexiones pueden cambiar.

El procedimiento establece una referencia común, organiza relaciones entre dispositivos y determina qué enlaces integran la topología activa. Frente a una modificación, los componentes intercambian información otra vez y el sistema puede converger hacia una configuración útil.

Hay una pregunta de fondo en ese resultado. ¿Cómo puede un conjunto producir una organización coherente si cada parte conoce sólo una porción de lo que ocurre? Perlman ha contado que le interesaba imaginar múltiples unidades ejecutando partes de un programa y observar cómo emergía un comportamiento global. Esa preocupación atravesó sus trabajos posteriores en enrutamiento y seguridad.

El árbol de expansión clásico resolvía el problema de los bucles mediante una renuncia concreta: algunos vínculos físicamente disponibles quedaban inactivos. La red ganaba estabilidad a costa de desaprovechar una parte de sus caminos. Con el crecimiento de las instalaciones, esa limitación adquiriría mayor importancia y estimularía otras soluciones.

Pienso en ese costo cada vez que una solución elegante deja algo afuera. A veces la alternativa óptima para un enlace produce problemas para la red entera. El trabajo interesante empieza cuando hago visibles esos costos y elijo qué propiedad merece protegerse.

Las redes locales planteaban una dificultad importante. Las redes de gran escala debían resolver además cómo trasladar paquetes entre destinos lejanos y adaptarse cuando cambiaban los vínculos disponibles. El enrutamiento requiere información sobre los caminos y mecanismos para mantenerla actualizada.

Perlman hizo aportes decisivos al enrutamiento por estado de enlace. En esta familia de protocolos, los dispositivos difunden información sobre conexiones y costos, reconstruyen una representación de la topología y calculan las rutas adecuadas. Cuando un enlace cambia, esa representación debe modificarse de manera consistente. Una información desactualizada puede producir decisiones equivocadas aunque el equipamiento físico siga funcionando.

A menudo hablamos de «redes» para describir cualquier forma de relación social. La analogía puede ser fértil, aunque prefiero usarla con cuidado. Los dispositivos necesitan protocolos específicos para construir y actualizar confianza en una información distribuida. Esa precisión técnica ayuda a ver cuánto trabajo hay detrás de expresiones que usamos con aparente facilidad, como «compartir» o «estar conectados».

En Digital Equipment Corporation, Perlman trabajó sobre DECnet y desarrolló mecanismos que influyeron en el estándar IS-IS (Intermediate System to Intermediate System). Ese protocolo llegó a utilizarse en infraestructuras de comunicación de gran escala y mantiene una trayectoria operativa extensa. Sus aportes ayudaron a mejorar la estabilidad y la posibilidad de administrar redes complejas.

Ella misma ha señalado en entrevistas que considera este trabajo tan importante como spanning tree. La observación impide encerrar su carrera en un solo invento. La red tiene que recordar qué sabe sobre sí misma, cuándo aprendió ese dato y cómo corregirlo si cambian las condiciones. Cuando administro una red, recuerdo que también depende de una memoria que alguien debe mantener.

Un equipo puede fallar por accidente. También puede comunicar datos incorrectos a propósito: anunciar una ruta inexistente, alterar información de otros dispositivos o intentar desorganizar el conjunto. Quienes reciben esos mensajes deben decidir qué considerar confiable mientras continúan operando.

Perlman estudió este problema en su investigación doctoral del MIT, terminada en 1988, donde exploró algoritmos de enrutamiento resistentes a componentes que funcionan incorrectamente o intentan sabotear el sistema. La estabilidad ya aparecía allí vinculada a una cuestión de seguridad.

La conversación pública suele identificar la seguridad informática con contraseñas, cifrado y controles de acceso. En una red distribuida también importa qué ocurre cuando un participante autorizado transmite falsedades o cuando la confianza entre componentes se rompe. Un diseño robusto necesita reducir daños, identificar situaciones problemáticas y recuperar funcionamiento.

Este punto me toca de cerca. En proyectos informáticos he aprendido que diseñar para el funcionamiento normal es apenas una parte del trabajo. Lo más difícil suele aparecer cuando las suposiciones dejan de cumplirse. La seguridad y la recuperación introducen preguntas que también tienen resonancia institucional: quién tiene autoridad para intervenir, cómo se registra un cambio, qué información merece seguir siendo confiable después de un incidente.

Su trabajo posterior abordó modelos de confianza, infraestructura de clave pública, información que debe expirar y algoritmos preparados para actuar bajo condiciones adversas. Junto con Charlie Kaufman escribió Network Security, un libro de referencia para estudiantes y profesionales. Me interesa esa clase de diseño que empieza por imaginar el fallo, no por celebrar el funcionamiento normal.

En 1992, Perlman publicó Interconnections, un libro que ayudó a ordenar el campo de las redes a través de principios de diseño, protocolos y problemas concretos. Su valor excedió el de una recopilación de instrucciones técnicas. Permitió comparar enfoques y entender las razones por las que ciertas arquitecturas funcionan bajo determinadas condiciones.

Aprender redes puede reducirse a memorizar comandos y repetir configuraciones. Perlman ha insistido en la importancia de comprender los fundamentos, anticipar fallos y reconocer los supuestos que hay detrás de cada protocolo. Saber qué hace una herramienta permite administrarla con criterio y darse cuenta de cuándo deja de ser apropiada.

Su perfil en el Internet Hall of Fame recoge una preferencia por sistemas simples, con escasa necesidad de configuración manual. Es una exigencia que se vuelve más importante a medida que aumentan las dimensiones de la infraestructura. Los operadores trabajan a veces con información incompleta y bajo presión; una configuración difícil de interpretar puede transformar una modificación menor en una interrupción extensa.

Quisiera que esa manera de pensar tuviera más presencia en el diseño cotidiano de software. Una herramienta debería ofrecer indicios suficientes para entender lo que ocurre y corregirlo sin depender de una persona que conoce secretos imposibles de documentar. La simplicidad suele ser una conquista laboriosa: alguien estudió los errores posibles y decidió cuáles podía evitarles a los demás.

También se enseña mediante una arquitectura. El modo en que un sistema informa un fallo o permite recuperarse forma parte de la relación entre su diseño y quienes tendrán que sostenerlo durante años. Me gustaría que esa forma de enseñar tuviera más presencia en el software que usamos.

El spanning tree permitió construir redes Ethernet extendidas sin bucles activos. Con infraestructuras mayores se hizo cada vez más visible el costo de mantener enlaces fuera de uso. El ancho de banda disponible podía quedar desaprovechado y algunos recorridos resultaban más largos de lo necesario.

Perlman participó después en TRILL (Transparent Interconnection of Lots of Links), una arquitectura que incorpora conceptos de enrutamiento para aprovechar múltiples caminos dentro de redes locales amplias, conservando características útiles para las aplicaciones que esperaban un servicio semejante al de Ethernet.

Me incomoda un poco la historia de la informática contada como una larga fila de tecnologías vencedoras que reemplazan a las derrotadas. La ingeniería suele avanzar por acumulación, revisando decisiones que cumplieron bien su función y que ahora necesitan otra respuesta. En spanning tree y TRILL veo esa continuidad: primero hubo que dominar el riesgo de los caminos redundantes; más tarde pudimos preguntar cómo utilizarlos mejor. El segundo problema existió con toda su fuerza porque el primero había encontrado una solución.

La secuencia es interesante por su relación con el tiempo. Una solución eficaz permite que un sistema crezca. Ese crecimiento cambia el entorno para el que había sido diseñada y vuelve visibles sus limitaciones. Los problemas nuevos pueden nacer precisamente del éxito de la respuesta anterior. Pienso en esa secuencia cuando una solución exitosa empieza a mostrar sus límites.

A Radia Perlman se la llama a menudo «la madre de Internet». Ella ha objetado ese título. Internet fue resultado de numerosas contribuciones, y su trabajo abarcó especialmente puentes, redes locales, enrutamiento y seguridad. La precisión importa: spanning tree interviene en la historia de Ethernet, mientras los protocolos de enrutamiento participan de otras capas de las comunicaciones.

Las etiquetas heroicas sirven para llamar la atención sobre una persona cuyo trabajo permaneció lejos de la cultura popular. También simplifican una historia colectiva y pueden atribuirle a alguien un invento entero que pertenece a procesos institucionales y técnicos mucho más amplios.

Me gusta la insistencia de Perlman en delimitar su aporte. La modestia biográfica, cuando viene acompañada de precisión técnica, permite reconocer a otros y preguntar de manera más clara por las consecuencias de cada decisión. Un invento importante ya tiene suficiente valor sin necesitar el título de maternidad de toda la red.

En una entrevista publicada por Folha de S.Paulo en agosto de 2026, Perlman volvió a cuestionar esa denominación y expresó preocupación por ciertos usos actuales de las redes: la desinformación, la dificultad para encontrar conocimiento confiable y la amplificación de organizaciones violentas. Su inquietud tiene un peso especial en alguien que contribuyó a estabilizar infraestructuras de comunicación.

Los protocolos transportan información y ayudan a que una red se mantenga operativa. Sobre ellos funcionan empresas, gobiernos, servicios y comunidades que deciden cómo distribuir contenidos, ejercer vigilancia o administrar atención. Esas decisiones se toman en otras capas del sistema, ligadas a la arquitectura aunque con responsabilidades propias. Prefiero quedarme con la precisión antes que con la etiqueta.

Spanning tree, los aportes al enrutamiento y las investigaciones de seguridad de Perlman ayudaron a construir comunicaciones estables y capaces de crecer. Esa estabilidad terminó sosteniendo actividades económicas, relaciones personales y servicios esenciales, junto con usos cuyos efectos sociales no podían resolverse desde los protocolos.

Una red robusta transporta información valiosa y puede transportar vigilancia, fraude o desinformación con la misma eficiencia. La ingeniería de comunicaciones tiene efectos sobre las posibilidades de acceso y control, pero los incentivos empresariales, las decisiones políticas y las prácticas sociales requieren formas propias de responsabilidad. Pedirle al protocolo una solución moral completa sólo volvería más difícil identificar dónde se toman esas decisiones.

Hay una segunda tensión: cuando un sistema funciona, buena parte del trabajo que lo hace posible se vuelve invisible. Los administradores recuerdan las reglas de recuperación durante una caída; quienes usan el servicio pueden desconocer por completo que esas reglas existen. Las soluciones de Perlman crecieron además dentro de empresas tecnológicas, entre ellas Digital y otras firmas del sector. La investigación industrial puso recursos y problemas reales a disposición de la ingeniería, mientras estándares e intereses comerciales influyeron sobre la difusión de las soluciones.

La fricción que me sigue interesando está entre resiliencia y autoridad. Una red necesita recuperarse, y sus usuarios necesitan saber quién puede intervenir cuando un fallo se vuelve crítico. Restaurar un servicio implica decisiones acerca de prioridades, controles y responsabilidades. Cuanto más imprescindible se vuelve una infraestructura, más difícil resulta dejar esas decisiones fuera de toda discusión pública. Esa tensión entre resiliencia y autoridad es la que me queda dando vueltas.

Radia Perlman dedicó su carrera a problemas que aparecen cuando las redes crecen y ningún administrador puede seguir personalmente cada cambio. Desarrolló reglas para prevenir bucles, contribuyó a distribuir información de rutas y trabajó sobre cómo resistir fallos y participantes maliciosos. Más tarde participó en diseños que permitieron aprovechar mejor los caminos disponibles.

La conectividad necesita cables y señales; su fiabilidad depende también de acuerdos entre dispositivos, información actualizada y procedimientos de recuperación. Una infraestructura puede disponer de muchos enlaces y seguir siendo frágil si carece de criterios para usarlos.

Hoy dependemos de redes para tareas ordinarias y servicios críticos. La estabilidad es una condición tan incorporada a nuestras expectativas que solemos recordarla recién cuando falta. Perlman contribuyó a esa confianza cotidiana, aunque su preocupación por la desinformación muestra que una comunicación técnicamente confiable puede sostener intercambios cuyo contenido resulta profundamente problemático.

La red necesita saber cómo volver.

Después de una falla, volver significa encontrar otra vez un camino operativo. En la vida pública también nos preguntamos cómo recuperar confianza en aquello que circula por esos caminos. Las herramientas para cada tarea son diferentes. La obra de Perlman me ayuda a reconocer ambas dificultades y a resistir la tentación de pedirle a la técnica respuestas que corresponden a nuestras instituciones. Vuelvo a esa distinción cada vez que una red funciona y nadie recuerda el trabajo que la sostiene.