Resumen

  • RFC 3084 trataba cada mensaje DEC de COPS-PR como una transacción completa: todas sus decisiones se instalaban o todas fallaban, y el PEP volvía al último estado bueno.
  • Un RPT exitoso cerraba esa operación, no toda la historia. Durante una desconexión el dispositivo podía seguir usando políticas en caché; al volver el enlace había que resincronizar los Request-States o confiar en que ambos extremos aún coincidían.

La política enviada acababa en otra máquina

Un servidor decide retirar un filtro e instalar otro dentro del mismo DEC. TCP entrega el mensaje. El equipo responde Success. El PDP ya no tiene sólo prueba de envío: el PEP afirma haber ejecutado la transacción.

El alcance del recibo termina ahí. El dispositivo debe convertir las instancias de una PIB en colas, clasificadores y acciones propias de su plataforma. El informe no muestra qué tratamiento recibió un paquete ni si la aplicación obtuvo el servicio prometido. Es una evidencia útil y localizada, no una conclusión universal.

Publicada en marzo de 2001, RFC 3084 definió COPS-PR, el uso de COPS para aprovisionar políticas entre un Policy Decision Point y un Policy Enforcement Point. Una Policy Information Base daba nombre a clases e instancias; una PRI era una instancia y un PRID la identificaba. El mecanismo podía transportar políticas de QoS, seguridad u otras áreas sin fijar un único modelo de datos.

Esta pregunta no repite la del artículo sobre RFC 3060. PCIM separaba una estructura común de información del algoritmo local que la interpretaba. COPS-PR se situaba después: incluso si las partes entendían el objeto, tenían que demostrar qué transacción aceptaron, qué estado conservaron y cómo recuperaron la coincidencia tras una interrupción.

Una transacción tenía un punto claro de retorno

Un DEC podía incluir varias decisiones. Las eliminaciones aparecían antes que las instalaciones para resolver precedencia, no para prometer dos fases temporales independientes. El mensaje entero debía tener un solo resultado. Si cualquier elemento fallaba, el PEP enviaba Failure y deshacía la operación hasta la última transacción correcta.

Así se evitaba borrar una política antigua sin poder instalar su sustituta. Todo DEC exigía un RPT solicitado, incluso uno vacío. El diseño distinguía con precisión la intención del PDP de la acción declarada por el PEP.

También reconocía el límite del rollback. Un fallo solicitado e inmediato aún tenía un estado bueno identificable. En cambio, una configuración instalada con éxito podía averiarse más tarde y originar un Failure no solicitado. RFC 3084 advertía que entonces no siempre era posible volver atrás, porque los cambios asíncronos hacían ambiguo cuál debía ser el estado correcto. Haber poseído un punto de control no significaba conservarlo para siempre.

La compatibilidad dependía de la dirección

Las PIB podían incorporar nuevas clases. Si un PDP moderno enviaba una PRC desconocida a un PEP antiguo, el equipo tenía que informar del error y restaurar el estado previo. Si el PEP era moderno y el PDP antiguo, la nueva clase simplemente no recibía instancias. Las clases obsoletas seguían reglas de omisión distintas.

Estas respuestas permitían que versiones desiguales fallaran de manera limitada, pero no las volvían equivalentes. Un intercambio exitoso sólo hablaba de los objetos procesados. No demostraba que ambos lados conocieran las mismas extensiones, compartieran capacidades ni produjeran idénticas acciones locales.

COPS-PR reducía otro tipo de divergencia al designar un único escritor por área de política y Client-Type. Mientras el PEP mantenía la conexión, la configuración quedaba efectivamente bloqueada incluso frente a la consola local. El control exclusivo evitaba carreras; a la vez, convertía la identidad del PDP, la sesión TCP y el repositorio compartido de estado en piezas de autoridad.

El caché gobernaba durante el silencio

Cuando se perdía la comunicación, el PEP intentaba recuperar al último PDP y después a un secundario configurado. Mientras tanto seguía usando el Request-State activo. Al reconectar, LastPDPAddr indicaba de quién procedían las decisiones aún almacenadas. El PDP podía pedir una sincronización mediante SSQ.

La sincronización obligaba al PEP a repetir las REQ de todos sus Request-States. El PDP enviaba después las eliminaciones de PRID o prefijos necesarias para alcanzar un estado conocido. Si el servidor no pedía sincronización, el cliente podía suponer que era reconocido y que su estado era correcto. Era una optimización definida por el protocolo, no una comprobación externa.

Los cambios ocurridos durante la desconexión debían notificarse al regresar. Si el vínculo no volvía dentro del plazo administrativo, el PEP eliminaba los Request-States instalados y el PDP hacía expirar sus propios registros. Dos temporizadores buscaban limitar una autoridad huérfana; no probaban que ambos extremos borraran exactamente al mismo tiempo.

SPPI y varias PIB posteriores ampliaron el conjunto, incluso con modelos de QoS y realimentación de uso. En 2016, el IETF trasladó RFC 3084 y documentos relacionados a Historic. El expediente citó despliegue limitado y el giro del trabajo de configuración hacia NETCONF y YANG. Esa decisión describe la trayectoria de los estándares; no demuestra que jamás hubiera equipos COPS-PR ni que todos desaparecieran de forma simultánea.

La lección duradera es conservar separados los hechos de la cadena. La política pretendida por el PDP, el DEC atómico, el RPT, el caché, la resincronización, la configuración local y el resultado del tráfico se apoyan entre sí, pero no son intercambiables. Entregar una regla con fiabilidad no basta para saber qué regla sigue viva en el equipo.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/