Resumen

  • RFC 3139 mostró que una intención de red como «servicio gold» necesitaba topología, estado y capacidades antes de transformarse en comandos específicos para cada plataforma.
  • Podían colaborar varios traductores, pero solo uno podía operar sobre un dispositivo en un instante. Política, candidato local, escritura, feedback y comportamiento requerían recibos distintos.

El router no entendía la promesa comercial

Un operador puede describir el resultado deseado con pocas palabras: estos clientes recibirán servicio gold. Esa abstracción permite coordinar la red sin enumerar cada cola y filtro. El equipo, sin embargo, necesita valores concretos.

La misma promesa puede requerir un clasificador en un proveedor, otro mecanismo en un segundo y una secuencia de comandos en un tercero. La ruta de respaldo puede necesitar un perfil diferente. Una modificación de topología puede mover el punto donde se aplica la política.

RFC 3139 utilizó este contraste para explicar la gestión de configuración. La política decía qué comportamiento se esperaba. No era todavía configuración local, confirmación de instalación ni medición del servicio.

El documento apareció en junio de 2001 como Informational. Surgió cuando varias áreas temían que COPS/PIB, SNMP/MIB y extensiones por tecnología produjeran soluciones fragmentadas. Una reunión en 1999 no resolvió todos los desacuerdos; el equipo de requisitos identificó propiedades comunes sin elegir ganador.

Por eso sus MUST son exigencias para una solución integrada, no prueba de que un protocolo o despliegue ya las cumpliera.

La traducción necesitaba tres representaciones

RFC 3139 separó política de alto nivel, configuración network-wide y configuración device-local. La primera modelaba comportamiento; la segunda representaba datos compartidos de los que podían derivarse varios equipos; la tercera era específica de una caja.

El configuration-data translator cruzaba las capas. Podía ser una persona, un servicio central, una función intermedia o código junto al dispositivo. La función era obligatoria; su ubicación no.

Traducir exigía conocer topología, capacidad, estado, rendimiento y monitorización. Un candidato puede ser sintácticamente correcto y estar basado en una ruta antigua. Un perfil de cola puede existir en el modelo y no en esa versión del equipo.

Si faltaba información necesaria para convertir sin error, el sistema debía detectarlo y actuar. RFC 3139 no fijó si debía parar, limitarse, esperar o pedir intervención. Sí rechazó la idea de que una entrada ausente pudiera pasar silenciosamente por certeza.

Muchos traductores en la red, uno en cada equipo

Varias etapas podían trabajar en tándem. Una convertía objetivo empresarial en configuración network-wide; otra elegía una técnica; otra renderizaba el candidato local.

En el punto de escritura, RFC 3139 fue tajante: solo un translator podía operar en un dispositivo en un instante. La red podía tener pipeline, pero la caja no debía recibir autorías concurrentes.

No era un algoritmo de lock. El RFC no definió elección, lease, fencing ni recuperación. Definió una invariante. Dos controladores con revisiones o snapshots diferentes pueden crear candidatos razonables por separado y un resultado imposible al intercalarse.

Uno puede reducir una cola mientras otro restaura un perfil anterior. El clasificador termina de una revisión, el scheduler de otra y la expiración desaparece. Dos respuestas exitosas prueban recepción de comandos, no coherencia final.

Por eso también se exigía eliminar misconfiguración por acceso compartido concurrente. El recibo necesita writer, revisión, inputs, conjunto de equipos e intervalo de exclusión. Last-write-wins ordena almacenamiento; no explica el objetivo.

El fallo podía existir entre estados locales correctos

Una transición de red suele depender de varias cajas. La solución debía añadir, modificar, borrar, volcar o restaurar configuración completa o parcial simultáneamente o de forma sincronizada cuando fuera necesario.

No todo partial es incorrecto. Un objeto inactivo puede instalarse antes. Pero una ruta antes del filtro puede abrir tráfico; un marcado nuevo puede entrar en un core que no lo reconoce; media migración puede crear loop o blackhole.

RFC 3139 pidió detección de errores específicos y recuperación, incluida la prevención de configuraciones parcialmente inapropiadas. No garantizó commit atómico distribuido, rollback universal ni una definición única de partial.

Hay que separar batch del orquestador, aceptación individual, estado almacenado, estado aplicado y tráfico. Cada actor posee su recibo; ninguno puede emitir los demás por adelantado.

El plan de respaldo debía prepararse antes

Otra exigencia era provisionar varias configuraciones locales para hacer switchover rápido sin descargar grandes cambios durante la avería. La rapidez futura dependía de preparación previa.

Preinstalar no es activar; activar no prueba vigencia. Topología, clientes y capacidades pueden cambiar. El candidato bueno ayer puede ser peligroso en el incidente real.

La redundancia de plataformas y elementos también era requisito. Eso introduce ownership: qué controlador escribe, qué snapshot heredó y cómo se impide que el antiguo regrese. Dos instancias vivas sin fencing pueden crear dos traductores.

El feedback cerraba el bucle local

Los dispositivos debían devolver confirmación, estado, monitorización y eventos. Sin feedback, la traducción es publicación unidireccional. Con él, el sistema puede reconciliar.

Pero «confirmado» necesita verbo. ¿Parseado, validado, guardado como candidate, committed, efectivo, persistente, aplicado al forwarding? El mismo success cambia de alcance.

RFC 3139 exigió interpretar configuración y estado locales dentro del contexto network-wide. Una cola puede estar instalada y contradecir la intención por un cambio de ruta. Una diferencia local puede ser la expresión correcta sobre hardware diferente.

La confirmación tampoco prueba servicio. El tráfico puede usar otro camino o no coincidir con el clasificador. «Gold instalado» y «gold recibido» son observaciones separadas.

El tiempo formaba parte de la autoridad

La configuración necesitaba effective time y expiration time. Algunos elementos debían caducar; otros podían no hacerlo. Un valor puede ser válido y futuro, almacenado e inactivo, o presente después de perder autoridad.

Relojes distintos agravan el riesgo. Un controlador cree terminada una excepción mientras una caja sigue aplicándola. Restaurar un snapshot puede revivir una regla cuya ventana terminó.

El recibo debe incluir autoría, entrada en vigor, expiración, base temporal, estado activo e intervalo observado. Presente no significa gobernando ahora.

La provisión dinámica por eventos necesita la misma disciplina: identidad del evento, revisión de policy, writer que reaccionó y duración del estado de recuperación. Sin ello, el feedback rápido puede producir oscilación.

Seguridad y trazabilidad eran parte de la semántica

RFC 3139 pidió control de acceso, autenticación, integridad, protección contra replay y privacidad cuando procediera. El host era granularidad mínima; usuarios y roles debían diferenciar privilegios. Los cambios debían poder atribuirse a host y usuario.

Una configuración bien formada escrita sin autoridad sigue siendo transición inválida. Una policy antigua firmada puede ser auténtica y estar caducada. Identidad, integridad, frescura y permiso responden preguntas diferentes.

Para investigar drift no basta el diff final. Hay que recuperar política, proyección, snapshot, translator propietario, candidato, respuestas, errores y feedback antes del siguiente writer.

Evolucionar sin ocultar pérdida de significado

El sistema debía aceptar evolución de modelos, mensajes y tipos sin romper interoperabilidad ni reemplazar grandes flotas. También debía aprovechar la experiencia de MIB y SMI.

Una extensión nueva puede ser desconocida para un traductor antiguo. El dispositivo puede conocerla con capacidad parcial. Omitirla produce una configuración válida y una intención incompleta.

La evolución segura requiere descubrir capacidades, tratar lo desconocido explícitamente y mostrar degradación. RFC 3139 no prometió que todo equipo antiguo ejecutaría toda policy futura.

El workshop IAB descrito en RFC 3535 y, después, NETCONF y NMDA hicieron concretas algunas fronteras: datastore, lock, validate, commit, configuración intended/applied y estado operational. Son continuidad histórica, no funciones que RFC 3139 ya hubiera implementado en 2001.

La enseñanza permanece. Una política puede ser clara y no ejecutable localmente. Un traductor puede compilar con hechos obsoletos. Una caja puede aceptar sin entregar. La palabra gold no era el último testigo.