Resumen

  • La revisión 07 plantea dos módulos YANG para definir pruebas unitarias OAM y secuencias ordenadas con periodos, recurrencias, estados y modelos de dispositivo montados en el esquema.
  • Que una secuencia figure como success no demuestra por sí solo qué versión se ejecutó, si todas las etapas fueron completas y comparables, si la causa es única, si el cambio estaba autorizado o si el servicio mejoró.

Coordinar la investigación sin fabricar un veredicto

Diagnosticar una red exige ordenar observaciones que suelen vivir en herramientas distintas. Primero se comprueba continuidad; después se localiza un tramo, se mide rendimiento, se cambia el punto de observación y se repite durante la ventana relevante. draft-ietf-opsawg-scheduling-oam-tests-07 intenta dar forma común a ese trabajo. Un módulo describe la prueba unitaria y los elementos de red implicados; otro reúne referencias a pruebas en un orden controlado por el usuario y añade calendario y repetición.

El riesgo aparece cuando la estructura administrativa se interpreta como una descripción completa de la realidad. Una fila existe, el servidor aceptó la configuración, el contador avanzó y el estado cambió a éxito. Ninguno de esos hechos contiene automáticamente los paquetes enviados, el comportamiento del tráfico afectado, el razonamiento causal ni el resultado para el cliente.

El Datatracker muestra que la revisión 07 sigue siendo un Internet-Draft activo de OPSAWG, destinado a Standards Track, sin número RFC y sin procesamiento iniciado por el IESG. Su historial registra dos revisiones tempranas con resultado Has Issues; la de YANG Doctors permanece incompleta. La especificación todavía está en desarrollo y no acredita implementaciones ni despliegues.

Recibo 1: la identidad exacta del plan

El borrador reutiliza de RFC 9922 el estado del calendario, la versión, la hora local, las ocurrencias anterior y próxima y los contadores. También referencia modelos OAM de dispositivo bajo un punto de montaje.

Un nombre legible y un entero de versión no bastan. El recibo debe fijar el digest del plan, orden de pruebas, nodos, parámetros, regla temporal, zona horaria, revisiones de módulos montados y responsable de aprobación. RFC 9922 permite que la entidad consumidora mantenga la versión e incluso que no la use. Por eso cada ocurrencia debe enlazarse con el contenido preciso que se revisó, no con el nombre mutable de una lista.

Recibo 2: del estado deseado al aplicado

La revisión 07 usa planned, configured, ready, on-going, stop, error y success; la secuencia añade failure. Son estados útiles, pero los produce una implementación concreta. Una escritura aceptada por NETCONF o RESTCONF confirma recepción y validación local, no la instalación completa en todos los nodos.

RFC 8342 separa configuración running, intended, aplicada y estado operational. Puede haber contenido deseado que no esté activo. El recibo de aplicación debe comparar esas vistas por nodo, registrar capacidades y esquemas, y declarar cualquier fallo parcial.

Además, la revisión OPSDIR observa que el borrador habla de diagnóstico bajo demanda pero no define RPC ni action normativa. La publicación no debe inventar esa interfaz ausente.

Recibo 3: la ocurrencia que realmente corrió

Una recurrencia expresa cuándo debería suceder algo. No identifica una ejecución concreta después de retrasos, reinicios, reintentos, solapamientos o failover del controlador. last-occurrence ayuda a orientarse, pero no sustituye una identidad de ejecución.

Cada instancia necesita el instante previsto y los tiempos reales, versión del plan, identidad del orquestador, fuente y tolerancia de reloj, linaje de reintentos y conjunto de nodos alcanzados. Si la prueba acabó fuera de la ventana del incidente, su éxito no reconstruye las condiciones que se querían observar.

Recibo 4: la integridad de pasos y dependencias

La lista se ordena por el usuario. El borrador permite continuar después de que una o varias pruebas fallen. Esa decisión conserva datos valiosos, pero vuelve ambiguo un estado terminal si el consumidor no sabe qué faltó.

La revisión PERFMETRDIR pregunta por qué stop desemboca en éxito para una prueba unitaria y en fallo para una secuencia. OPSDIR pide semántica de error más clara, notificaciones, correlación, atomicidad y rollback multinodo. Un recibo completo enumera cada paso, dependencia, nodo, resultado, omisión y decisión de continuar, y explica qué hipótesis dejan de poder descartarse.

Recibo 5: la semántica de la medición

El borrador no define los resultados detallados. Los delega a modelos OAM existentes, como el modelo TWAMP de RFC 8913, montados mediante el mecanismo de RFC 8528. Schema mount organiza un árbol de modelos, pero no presupone de dónde procede cada dato ni cómo se instanció el punto de montaje.

Por eso el recibo debe identificar tipo y revisión de prueba, entradas, destino, dirección, población de paquetes, clase, tamaño, tasa, intervalo, unidad, reloj, dispositivo, resultado bruto o digest y custodia. Un puntero a una hoja montada y el valor aislado que contiene no son una conclusión operacional.

RFC 7799 distingue medición activa, pasiva e híbrida. El dato debe conservar esa procedencia: lo que experimentó un paquete creado para probar no equivale sin más a lo que experimentó el tráfico de producción.

Recibo 6: comparabilidad con el servicio afectado

RFC 10014 separa congruencia de camino y tratamiento de reenvío igual. Una sonda puede cruzar los mismos enlaces y nodos y, aun así, utilizar otra cola, QoS, rama ECMP, policer o régimen de carga.

El recibo de comparabilidad debe declarar topología, encapsulación, clase, hash, dominio de mantenimiento, ventana, carga y modo de fallo compartidos. Si solo coincide la topología, la conclusión solo puede referirse a la topología. La programación no concede fate sharing por configuración.

Recibo 7: hipótesis causal y autoridad

El caso de uso del borrador habla prudentemente de localizar causas candidatas. RFC 9940 separa evento, falla, problema, síntoma, causa, alerta, alarma e incidente. RFC 8632 trata las posibles raíces como pistas que la aplicación cliente debe interpretar.

El recibo de diagnóstico debe conservar observaciones, alternativas, hipótesis excluidas, confianza, alcance y condición de refutación. Después, otro recibo debe demostrar quién autorizó el cambio, bajo qué política, con qué alcance, ventana y rollback. El permiso para crear diagnósticos no equivale al permiso para cambiar routing, QoS o servicio; RFC 8341 sitúa el control de acceso en su propia capa.

Recibo 8: el efecto después de intervenir

Un cambio puede instalarse y la sonda original puede ponerse verde sin resolver el problema del cliente. Quizá el tráfico pasó a otra ruta, el síntoma quedó oculto o surgió una degradación distinta.

El resultado debe observarse en la superficie que soporta la promesa: población de servicio, condición SLA, ventana posterior, señales independientes, alarmas residuales y estabilidad. Repetir exactamente la misma sonda aporta evidencia, pero no es independiente cuando su equivalencia con el servicio era la cuestión disputada.

OAM programado es valioso porque permite coordinar. Su credibilidad depende de no absorber autoridad adicional. Los registros pueden unirse desde el plan hasta el resultado; cada salto conserva su propio significado.