Resumen

  • RFC 9968 recoge una conversación de NEMOPS sobre herramientas, modelos de servicio, verificación y automatización. Es un informe informativo del IAB, no una norma de operaciones ni una delegación de poder a un controlador.
  • La configuración deseada, el estado aplicado y el estado observado responden preguntas diferentes. Confundirlos permite que una pantalla convincente o una traducción de modelo parezca una decisión ya aprobada.
  • La automatización sostenible necesita conservar por separado una promesa de servicio, la evidencia con sus límites, una propuesta concreta y una autorización local revocable. La cadena sólo es explicable si cada registro mantiene su función.

El valor de NEMOPS está en lo que no promete

RFC 9968 documenta el taller IAB sobre la próxima era de operaciones de gestión de red. El informe vuelve sobre el taller de 2002 de RFC 3535 y describe un ecosistema que no cabe en un eslogan de sustitución tecnológica. Siguen existiendo SNMP y CLI; los modelos NETCONF y YANG no ofrecen cobertura plena en muchos equipos; las redes con varios proveedores deben convivir con modelos y herramientas distintos; faltan guías, implementaciones abiertas y trayectorias de transición fáciles de usar.

No es una conclusión pesimista. Es una conclusión operativa. Un protocolo puede ser correcto y aun así no resolver cómo se representa un servicio completo, cómo se reconcilia una función específica de un proveedor, o cómo se comprueba que la modificación aceptada por un equipo no perjudicó al cliente que dependía de ella. El informe pide verificar configuraciones, dar más atención al nivel de servicio y mejorar la observabilidad. Son mejoras de evidencia y de disciplina de ejecución.

También hay que respetar el alcance que declara el propio documento. RFC 9968 es Informational, no Standards Track. Dice que recoge presentaciones y notas de las discusiones sin interpretación ni validación, que no necesariamente captura consenso y que las posiciones de quienes participaron no tienen por qué ser posiciones del IAB. Por eso sirve como evidencia de necesidades, fricciones y propuestas; no sirve como mandato para imponer una modificación sobre un operador, un cliente o una red ajena.

El problema aparece cuando esa honestidad desaparece al llegar a la herramienta. Un grafo puede reunir inventario, alarmas, políticas y dependencias. Una plataforma puede recomendar una corrección. Una cola puede enviar cientos de solicitudes coherentes. Nada de eso responde quién está facultado para aceptar la degradación posible, qué compromiso comercial limita la acción, o quién debe responder si la predicción era incompleta. La claridad de la representación no crea legitimidad sobre el resultado.

RFC 3535 ya establecía una pauta especialmente relevante: diferenciar datos de configuración, estado operativo y estadísticas; minimizar efectos al pasar de una configuración A a otra B; usar privilegio mínimo; y separar la distribución de una configuración de su activación. Distribuir una intención no es activarla. Tener una ruta API tampoco decide si es correcto activarla ahora, sobre este conjunto de usuarios, bajo estas condiciones de retorno.

Cuatro pruebas, no una única “fuente de verdad”

La primera prueba es la intención de servicio. Define qué se debe conservar: conectividad, latencia, una entrega de cliente, una clase de tráfico, una ventana de mantenimiento o un objetivo de recuperación. Debe tener un propietario del compromiso. No puede reducirse a una colección de hojas de configuración.

La segunda es la evidencia observada: contadores, sondas, registros, vistas de rutas, notificaciones y verificación humana. Cada pieza debe llevar origen, tiempo de captura, alcance, pérdida y lo que queda fuera del modelo. Un flujo perfectamente formado puede ser parcial; el silencio puede significar normalidad, pero también una suscripción rota, una retención o una condición no modelada.

La tercera es la propuesta. Muestra el delta, sus equipos, servicios, dependencias, clientes alcanzados, efecto esperado y marcha atrás. Si un adaptador convierte un modelo de servicio en configuración específica de fabricante, se deben retener el modelo de entrada, la salida y la versión del adaptador. De lo contrario, una investigación posterior no puede separar una intención equivocada de una conversión equivocada.

La cuarta es la autorización. Establece quién decide, para qué alcance, con qué evidencia, durante cuánto tiempo y quién puede detener o revertir. No requiere una aprobación ritual para cada paquete. Exige que una regla automática tenga dueño, límites y retirada. Una política sin fecha, alcance o responsable se convierte con facilidad en soberanía de la herramienta.

RFC 8342 ayuda a mantener estas preguntas separadas porque NMDA distingue estado de configuración previsto, aplicado y operativo. Es una arquitectura técnica, no un régimen de responsabilidad. No determina quién acepta el riesgo comercial de un cambio. Pero impide una confusión habitual: asumir que un estado almacenado, aunque sea válido, equivale al estado de servicio que el usuario experimenta.

RFC 6241 ofrece operaciones NETCONF, incluidas superficies para configuración candidata, ejecución y confirmed commit; RFC 8040 define RESTCONF. Ambos pueden hacer una operación estructurada, autenticada y recuperable dentro de su ámbito. Ninguno conoce por sí solo el contrato de tránsito, la prioridad de una llamada de emergencia o la autoridad de quien soportará la interrupción. Capacidad de escribir no es derecho de decidir.

La notificación no demuestra el mundo entero

NEMOPS acertadamente busca telemetría más útil. RFC 8639 establece el marco de suscripciones YANG; RFC 8641 trata cambios de datastore; RFC 9196 describe capacidades y notificaciones asociadas. En conjunto permiten describir señales acordadas. No garantizan que estén descritas todas las variables relevantes, que un mapeo entre modelos no pierda semántica, que el canal permanezca íntegro ni que una correlación explique causalidad.

La inferencia peligrosa tiene tres pasos: “el modelo lo permite; por tanto el modelo gobierna; por tanto el cambio está permitido”. El primer paso puede demostrarse en un laboratorio o un canario. El segundo requiere una fuente externa: delegación local, contrato, deber regulatorio cuando corresponda y la persona que asumirá el impacto. Una estructura de datos no puede producir esos elementos.

La primacía del código en ejecución, la especificación inicial mínima y decisión localizada y las capas de realidad de Heng Lu ofrecen un filtro editorial: una superficie común debe facilitar adopción voluntaria, no apropiarse de futuras elecciones; una afirmación debe confrontarse con el servicio que realmente corre; y una capa simbólica no puede ocupar el lugar del efecto operativo.

Ensayar la frontera

La prueba adecuada no termina cuando un dispositivo devuelve éxito. Debe conservar intención de servicio, versiones de modelo, inventario, capacidades, edad de las observaciones, pérdidas de notificación, delta propuesto, decisiones y resultado medido por una sonda independiente. Después debe fallar a propósito: retrasar una notificación, retirar un alimentador, rechazar una hoja, encontrar una función no soportada, introducir una modificación CLI externa, reiniciar el controlador entre distribución y activación, o ampliar el alcance después de la aprobación.

Cada ensayo identifica un lugar distinto donde la evidencia ya no basta para actuar sin revisión.

Sources