Resumen

  • ietf-detnet, definido por la RFC 9633 y compatible con NMDA, modela flujos de aplicación, perfiles de tráfico, subcapas de servicio y reenvío, y parte del estado operativo.
  • Una transacción correcta y app-flow-status=ready prueban hechos de gestión delimitados. No demuestran que una población de paquetes haya respetado la latencia, variación, pérdida o secuencia configuradas.
  • La constancia completa enlaza versión y alcance de configuración, estado de cada nodo, época de contadores, selector de flujo, medición con relojes conocidos y aceptación de la aplicación.

El cambio terminó sin error. NETCONF devolvió éxito, el árbol operativo mostraba los enlaces esperados y la entrada estaba ready. El siguiente paquete llegó tarde.

No hace falta suponer que el servidor mintió. Basta con reconocer que una transacción de gestión y un plazo de aplicación son hechos distintos.

La RFC 9633 proporciona un modelo YANG común para configurar servicios de red determinista y leer su estado. El módulo organiza el flujo desde la aplicación hasta las subcapas que prestan servicio y reenvío. También separa datos configurables de hojas operativas de solo lectura.

Esa estructura reduce ambigüedad. El error comienza cuando la organización trata el árbol como si fuese una captura temporal del comportamiento extremo a extremo.

El perfil define la prueba que falta

Un traffic-profile puede expresar ancho de banda mínimo y máximos de latencia, variación, pérdida, pérdidas consecutivas y desorden. Son requisitos del servicio. Su presencia indica qué compromiso se pretende verificar, no que ya se haya verificado.

La traffic-spec describe cómo promete o solicita transmitir la fuente: intervalo, cantidad de paquetes y tamaños de carga. El equipo de red usa esa declaración para asignar recursos. Si la fuente excede lo declarado, la interpretación de un fallo cambia; aun así, el dato configurado no prueba qué tráfico ofreció realmente.

Esta separación evita una contabilidad circular. La latencia máxima no puede convertirse en la latencia observada. El porcentaje de pérdida permitido no es el numerador ni el denominador de un intervalo real. La tolerancia de pérdida consecutiva exige conocer la secuencia; el agregado de bytes no la reconstruye.

El modelo vuelve legible el contrato técnico. La medición debe aportar el cumplimiento.

ready no lleva cronómetro

La RFC define estados none, ready, failed, out-of-service y partial-failed. Las hojas de estado del flujo son operativas, no configurables. Una configuración incompleta produce none; una aplicación puede informar que está lista en ingreso o egreso.

Eso es más informativo que inferir disponibilidad a partir de la mera existencia de una rama. Pero ready no incluye paquetes correlacionados, intervalo, reloj remoto ni confirmación de la aplicación receptora. En un flujo con varios egresos, partial-failed puede coexistir con uso posible si el ingreso está listo. La palabra única no autoriza a borrar esa distribución.

Por tanto, cada lectura necesita contexto: dispositivo, aplicación, dirección, subcapas vinculadas, datastore, instante y generación. Sin estos campos, dos lecturas idénticas pueden pertenecer a servicios o épocas diferentes.

Configurar sin señalización no significa configurar de una vez

El modelo permite aprovisionar dispositivos del camino sin depender de un protocolo de señalización. La frase describe una capacidad de administración. No promete una confirmación atómica de todos los nodos.

Un dispositivo puede aceptar primero y otro rechazar después. Uno puede exponer la nueva referencia de servicio mientras otro conserva la anterior. Un colector que lee durante la transición puede construir una vista que nunca existió simultáneamente.

La advertencia de seguridad de la RFC es decisiva: cambios no coordinados a lo largo del camino pueden provocar denegación de servicio. La evidencia debe reflejar ese riesgo. Hace falta registrar qué conjunto de nodos constituía el camino, qué revisión recibió cada uno, qué respuesta emitió y cuándo se consideró activa la generación completa.

NMDA disciplina la relación entre configuración pretendida y estado operativo. No sustituye la coordinación distribuida ni conserva automáticamente una fotografía histórica coherente.

Autorización y verdad no son sinónimos

NETCONF sobre SSH, RESTCONF sobre HTTPS y NACM permiten proteger el plano de gestión. Definen quién puede leer o modificar ramas sensibles y reducen el riesgo de escrituras arbitrarias capaces de romper flujos o desviar tráfico.

Una respuesta autenticada atribuye la declaración. No demuestra que el firmware interpretó correctamente el perfil, que el dato no está obsoleto o que el dispositivo formó parte del trayecto del paquete observado. La autoridad para escribir una configuración tampoco es la autoridad para certificar el resultado comercial o operativo.

Conservar ambas cosas mejora el análisis: identidad del administrador y recibo de transacción por un lado; observación independiente por otro.

Sin época, el contador no tiene historia

Los ejemplos combinan estado DetNet con estadísticas de interfaz y su discontinuity-time. Un contador leído después de un reinicio no cubre necesariamente la ventana que sugiere el incidente. Comparar nodos con épocas distintas crea pérdidas o éxitos imaginarios.

La latencia unidireccional necesita relojes con una relación conocida y puntos que delimiten el servicio. La pérdida necesita el mismo universo de paquetes. El desorden necesita identificadores de secuencia. La replicación exige decidir cómo tratar copias, duplicados eliminados y llegadas tardías.

La prueba puede ser activa, pasiva o híbrida, pero ese diseño OAM es independiente de la RFC 9633. Su selector debe coincidir con el flujo modelado: dirección, interfaces, prefijos, puertos, DSCP, etiquetas y caminos miembros. Una sonda bien medida en otra cola no verifica la promesa correcta.

Cinco recibos en vez de una pantalla verde

Primero se conserva la definición: nombre, selector, perfil, requisitos, capas y revisión. Segundo, la actuación administrativa: autoridad, transacción, respuestas y hora efectiva por nodo. Tercero, el estado operativo distribuido, sin convertir partial-failed en éxito total.

Cuarto, la observación de paquetes: intervalo, relojes, población, muestreo, discontinuidades y reglas para pérdida, repetición y orden. Quinto, la decisión de la aplicación o del propietario del servicio: aceptar, rechazar, exceptuar o revertir.

La tesis de Heng Lu sobre capas de realidad resulta práctica aquí. El registro de coordinación es necesario, pero no adquiere el monopolio sobre lo que ocurrió en el sistema. El código en ejecución y el resultado observable conservan su propia autoridad.

Fuentes