Resumen

  • La perspectiva de los proveedores en RFC 7149 hizo visibles la conectividad del controlador, el arranque y la continuidad como responsabilidades operativas, no como ventajas automáticas de separar control y reenvío.
  • En una red sin IGP ni BGP puede hacer falta un protocolo o una red de arranque independientes. El documento pide comparar ese coste con integrar el controlador en el enrutamiento existente y dice que la red subyacente debería seguir operativa si se pierde la conexión con el punto de decisión de políticas (PDP).
  • RFC 7149 es informativo: presenta una perspectiva de diseño y condiciones concretas; no es un estándar de Internet, un censo de despliegues ni el informe de una avería real.

La separación no explicaba toda la historia

El SDN solía resumirse como una división limpia: el plano de control decide y el de reenvío ejecuta. Publicado en marzo de 2014, RFC 7149 advertía que ese dibujo podía exagerar la novedad. Desde hacía tiempo los routers combinaban decisiones de enrutamiento por software con reenvío por hardware. El cambio más importante era trasladar la lógica de decisión a una entidad lógicamente central que pudiera programar los elementos de red.

Ese traslado crea una dependencia práctica. El controlador debe descubrir dispositivos y capacidades, intercambiar información de políticas y servicios, asignar recursos, aplicar decisiones y recibir información sobre el cumplimiento. RFC 7149 reúne estas tareas en cuatro ámbitos: descubrimiento de topología y capacidades; exposición del servicio y negociación de parámetros; asignación dinámica y aplicación de políticas; y retroalimentación para cumplimiento y aseguramiento.

Así, el memorando conecta arquitectura con la promesa hecha al cliente. En su definición provisional, un servicio no es solo una ruta calculada por software: es un resultado determinista cuyos parámetros pueden negociarse con el cliente. Es una lente útil, no una definición de SDN aceptada universalmente. Cambia la pregunta de «¿hay un controlador?» a «¿puede el proveedor ofrecer, entregar y verificar el servicio acordado?»

El controlador necesita una vía de entrada a su propio dominio

El arranque vuelve concreta esa dependencia. En una red sin IGP ni BGP, el controlador puede necesitar un protocolo o una red aparte para descubrir y configurar dispositivos. Ese canal tiene costes: hay que construirlo, protegerlo, operarlo y mantenerlo accesible. Integrar el punto de decisión en el sistema de enrutamiento ya existente puede evitar una infraestructura paralela, pero vincula el diseño al comportamiento y los límites de ese sistema. RFC 7149 pide comparar opciones, no suponer que una aplicación de control aparece sobre una red aún sin configurar.

El escenario de fallo revela lo mismo. Para el entorno sin IGP/BGP tratado, el memorando indica que la red subyacente debería seguir operativa si pierde la conexión con el PDP. No afirma que cualquier caída del controlador detenga el tráfico ni describe una caída observada. Es un requisito condicional de continuidad: si se separa el punto de decisión, hay que especificar qué autonomía queda cuando se corta la comunicación.

El descubrimiento no demuestra que el servicio esté listo. El controlador puede inventariar un equipo sin haber negociado parámetros del cliente, instalado políticas, confirmado recursos o recibido información de aseguramiento. Distinguir estas etapas evita confundir el estado «conectado» de un panel con un servicio en funcionamiento.

De la promesa arquitectónica a la evidencia operativa

RFC 7149 también rechaza que exista un protocolo SDN obligatorio o una fecha única para migrar. OpenFlow es una herramienta, no un sinónimo de SDN; el memorando contempla una integración gradual con redes existentes y sistemas específicos de cada proveedor. La entidad central no debería convertirse en un punto único de fallo ni perjudicar el reenvío. Son cautelas de diseño, no pruebas sobre un sistema concreto.

La diferencia importa para la historia. Un RFC informativo puede ordenar un debate y señalar las preguntas que debería responder un operador. No establece cuántos proveedores adoptaron la arquitectura, qué resultados obtuvieron ni si sucedió una avería. Para sostenerlo harían falta registros de despliegue, mediciones, informes de operación y resultados para los clientes.

La contribución duradera no es tanto un nuevo mecanismo de reenvío como un cambio en dónde recae la carga de la prueba. La programabilidad no elimina la necesidad de conectividad, observabilidad y mecanismos de reserva; convierte el propio canal de control en parte del diseño del servicio. Antes de preguntar qué puede ordenar un controlador, el proveedor debe mostrar cómo llega, qué puede verificar y qué hace la red cuando se pierde el camino de vuelta al punto de decisión.

Fuentes