Resumen

  • draft-ietf-cats-oam-fw-01 es un Internet-Draft activo del WG CATS; no es un RFC, una prueba de despliegue ni una orden operativa.
  • Sus capas de enlace, ruta, instancia y servicio distinguen conectividad, salud de instancia y evidencia extremo a extremo.
  • La verificación de política compara el reenvío observado con una selección previa del C-PS; los administradores definen los pesos de la política que produjo esa selección.
  • Un recibo de telemetría a remedio debe mantener separados fuente, frescura, política, conflicto, acción, ejecución y resultado.

Una capa de observación no recibe un mandato operativo

La carta de CATS estudia cómo el borde de una red puede dirigir tráfico entre clientes y sitios con varias instancias de un servicio. Reconoce que la experiencia depende de métricas de red y de cómputo. Busca un marco para distribuir esas métricas y usarlas en una función de selección. Sin embargo, supone modelos de dominio único y sitúa esa función en la red del proveedor, lógicamente separada de la operación del servicio.

La separación limita correctamente lo que puede afirmar el componente de encaminamiento. Puede aplicar una política local sobre señales que recibe. No se convierte por ello en propietario del servicio, titular de un compromiso contractual ni autoridad para escoger una recuperación. Un marco puede hacer comprobable la interfaz entre esos papeles; no puede fusionarlos.

El estado del documento exige el mismo cuidado. Datatracker lo muestra como documento activo del WG, con estado IESG I-D Exists, condición prevista Informational y vencimiento en enero de 2027. Eso prueba una etapa de proceso. No prueba que un operador concreto lo use, que una aplicación haya mejorado ni que exista una regla vinculante para un cliente. Un Internet-Draft es trabajo en curso y puede cambiar o ser sustituido.

Cuatro capas mejoran la pregunta

Link OAM observa un enlace o interfaz inmediata. Path OAM observa un trayecto entre Forwarders. Instance OAM observa recursos de cómputo y salud de una instancia. Service OAM mide o detecta condiciones extremo a extremo hasta la instancia objetivo. Esta estructura evita que una interfaz IP viva se presente como prueba de disponibilidad del servicio: la aplicación puede haber caído, quedar bloqueada o quedarse sin recursos.

Pero cada capa responde a un objeto diferente. Carga de CPU no equivale a una transacción; latencia medida no equivale a la interpretación contractual de un SLA; aislar un dominio probable no identifica automáticamente causa, culpa o pérdida. El texto deja fuera de alcance los protocolos específicos de Instance y Service OAM. Arquitectura, protocolo y procedimiento de operación siguen siendo decisiones separadas.

Verificar una política es comparar con una elección ya hecha

Para el borrador, la verificación de política comprueba que el camino real desde un CATS-Router de ingreso hasta la instancia elegida coincide con la decisión del CATS Path Selector, C-PS. Responde si la ejecución siguió una decisión anterior. No responde qué decisión era correcta.

Una coincidencia no valida los pesos de red y cómputo que generaron la selección. Una discrepancia no elige un peso nuevo, una conmutación, una pausa, una escalación humana o una no-acción. Las exigencias administrativas asignan a los administradores la definición de políticas CATS, incluidos los factores de ponderación. La telemetría llega al C-SMA; el C-PS la usa conforme a la política; la autoridad local conserva la responsabilidad por la política y sus cambios.

Esta distinción evita que una consola se convierta en autor de una decisión. Sin ella, una investigación posterior no puede saber si el problema fue una medida vieja, una regla defectuosa, una excepción autorizada, un error de ejecución o un límite de seguridad que justificó no mover tráfico.

Detectar un conflicto no dicta cómo resolverlo

Instance OAM admite modos push y pull. El sistema debe detectar si los valores obtenidos por ambos son inconsistentes. El borrador no ordena una estrategia única de resolución porque la elección óptima depende del despliegue. No es un hueco que deba rellenarse con una conclusión automática. Deja en manos responsables preguntas como qué fuente prevalece, cuánto retraso es aceptable, cuándo un valor anómalo merece acción, quién puede suspender automatización y qué mantenimiento justifica una excepción.

Los requisitos también contemplan marcas de tiempo, umbrales de frescura configurables y reportes periódicos o activados por umbral. Tales parámetros convierten observación distribuida en regla de acción: pueden reducir demora, pero también provocar oscilación, movimientos inútiles de tráfico o una degradación que se detecta tarde. Un servicio público, una carga industrial y un trabajo interno no tienen por qué aceptar la misma combinación.

El resultado responsable no es fingir una receta universal. Un operador puede mantener un valor, drenar una instancia, pedir aprobación, hacer una conmutación verificada o no actuar. El borrador aporta evidencia para esas decisiones; no las toma.

Un recibo de telemetría a remedio

Ante un cambio de encaminamiento material, conviene conservar una constancia compacta: fuente, hora de recogida, objeto y regla de frescura; resultado de integridad; versión y titular autorizado de la política; discrepancia y disposición; quien eligió la acción; evidencia de ejecución; y condición de reversión o revisión. No exige publicar topología, capacidad, datos de clientes ni detalles útiles para atacar el sistema.

El resultado debe seguir siendo otra fila. Un reenvío que coincide con el C-PS demuestra alineación de ejecución. No demuestra recuperación del servicio, éxito del cliente o cumplimiento de SLA. El recibo es una propuesta editorial de Daniel Kade, no un requisito IETF ni una afirmación sobre despliegues actuales de CATS.

Fuentes

  1. draft-ietf-cats-oam-fw-01
  2. Carta del WG CATS
  3. RFC 7282
  4. Heng Lu, The Multi-Stakeholder Mirage