Resumen

  • RFC 9753 negocia el uso de los bits P e I del encabezado de objeto en PCEP con estado; un objeto desconocido con P desactivado puede ignorarse mientras continúa el mensaje.
  • La continuidad del intercambio, el bit I y un informe PCRpt son recibos limitados. No prueban equivalencia semántica, programación del reenvío ni tránsito seguro de los paquetes.

El cambio más difícil de auditar puede ser el que no produce error. Un PCC comunica un LSP con varios atributos previstos. Uno de los objetos representa una restricción que el otro par no conoce. La política local ha puesto P a cero. El receptor descarta ese objeto, procesa el resto y mantiene la sesión. No falta ningún objeto obligatorio y el protocolo se ha comportado como permite la relajación. Lo perdido no es el mensaje, sino una parte de lo que debía significar.

RFC 9753, publicado en abril de 2025 como estándar del IETF, actualiza RFC 8231. El registro del RFC Editor y el Datatracker fijan su identidad. Su propósito es permitir que algunos objetos de PCRpt, PCUpd y PCInitiate sean opcionales, evitando que una diferencia de capacidades convierta siempre el intercambio completo en un fallo.

RELAX acuerda una sintaxis, no una interpretación

El PCEP base de RFC 5440 define P como regla de procesamiento e I como indicación de que un objeto opcional fue ignorado. RFC 8231 había ordenado enviar esos bits a cero e ignorarlos en objetos con estado. RFC 9753 añade R, RELAX, al STATEFUL-PCE-CAPABILITY TLV. El registro PCEP de IANA asigna a RELAX el bit 17.

Los dos pares deben anunciar R. Si uno no lo anuncia, debe ignorar P e I según la regla anterior. R mutuo prueba voluntad de utilizar esta gramática en esa sesión. No prueba que ambos pares tengan la misma lista de objetos relajables, la misma versión de política o la misma valoración de una restricción.

La norma recomienda P=1 por defecto. P solo se limpia cuando la configuración o política local permite ignorar la restricción, o cuando el objeto es informativo y puede omitirse con seguridad. Por tanto, el protocolo no descubre que la pérdida sea inocua. La decisión tiene dueño local.

P e I cubren el objeto completo

Los bits no seleccionan un TLV desconocido dentro de un objeto; abarcan el objeto PCEP entero. Por eso el registro operativo debe nombrar clase, tipo, mensaje, dirección, SRP o petición, revisión de política y LSP. Sin ese detalle, una organización puede creer que perdió un dato accesorio cuando en realidad retiró de la decisión todo el contenedor de una condición.

Los objetos obligatorios conservan esa condición. En PCRpt, RFC 9753 señala LSP y el ERO previsto; en PCUpd y RFC 8281 PCInitiate, SRP, LSP y ERO. Si P está indebidamente a cero, el receptor debe emitir PCErr tipo 10, valor 1. Para un objeto no obligatorio, P=1 y desconocimiento obligan a rechazar todo el mensaje con Unknown Object o Not supported object. Con P=0, el receptor puede ignorarlo y continuar.

Así, una métrica de «mensajes aceptados» mezcla dos hechos distintos: comprensión completa y pérdida permitida. La ausencia de PCErr no resuelve cuál ocurrió.

La delegación cambia la autoridad sobre el bit

En PCRpt, P indica al PCE qué debe contar durante mantenimiento, cálculo o reoptimización. En PCUpd y PCInitiate, indica al PCC qué debe contar al establecer la ruta. RFC 8051 describe la aplicabilidad; RFC 8231 mantiene la propiedad del estado del LSP en el PCC y somete los atributos del PCE a política local.

No obstante, durante la delegación RFC 9753 permite al PCE cambiar el tratamiento: puede marcar un objeto como ignorado aunque el PCC hubiera fijado P, o exigirlo aunque el PCC lo hubiera limpiado. El PCC debe reconocer esa expectativa en PCRpt o seguir la vía de actualización inaceptable. Una instantánea final no revela la historia. Hacen falta propietario de la delegación, generación de sesión, identidad de petición, objeto, valores anterior y posterior, política y respuesta.

I dice «procesado», no «cumplido»

El PCE puede incluir en PCUpd un objeto opcional ignorado y poner I. El PCC puede hacer lo mismo en un PCRpt que responda a PCUpd o PCInitiate. I a cero indica que el par declara haber procesado el objeto. Pero I carece de sentido en PCRpt sin el SRP que correlaciona la respuesta y debe estar a cero en PCInitiate.

Incluso en su contexto correcto, procesar no equivale a satisfacer. El analizador puede reconocer el objeto y la política puede leerlo, mientras otra condición determina el camino. El estado comunicado por el PCC tampoco es una inspección independiente del hardware.

El ejemplo de RFC 9753 muestra el coste semántico. PCRpt puede incluir listas de atributos previstos y reales. Un objeto METRIC puede imponer un límite de variación de retardo conforme a RFC 8233. Marcarlo opcional puede ser razonable si no existe un camino que cumpla. Si se ignora, el intercambio puede acabar bien, pero el límite no se ha conservado. El recibo debe guardar valor y unidad, decisión, recálculo, atributos reales y medición del tráfico.

El informe no ve por sí solo el plano de reenvío

RFC 8231 define la sincronización inicial como réplica en un instante del estado del PCC. PCRpt puede comunicar camino, ancho de banda y estado operativo o administrativo. Entre ese informe y el paquete quedan política local, señalización, admisión de recursos, elección en RIB o tabla de etiquetas, resolución del siguiente salto y programación del equipo.

Esta separación también evita duplicar el análisis de RFC 9757, que trata instrucciones Native IP BPI/EPR/PPA, y el de RFC 9826, que define una proyección YANG de PCEP. Una base de control o gestión completa sigue sin ser un testigo externo del reenvío.

RFC 9753 recomienda activar la función en sesiones autenticadas y cifradas bajo una misma autoridad administrativa, con PCEPS de RFC 8253 y la guía TLS de RFC 9325. Esa protección autentica el canal y reduce exposición; no certifica que la política que limpia P sea correcta.

También pide que RELAX y las restricciones opcionales sean configurables y visibles. No introduce requisitos nuevos de verificación operativa. Eso delimita el estándar, pero no convierte la comprobación externa en innecesaria.

Las capas de realidad de Heng Lu sirven como lente editorial declarada: un símbolo acordado, una operación aceptada, un estado representado, una programación aplicada y un resultado observado son hechos diferentes. El libro mayor fiable une once recibos: identidad y sesión, R mutuo, mensaje y objeto, política del emisor, análisis, decisión de ignorar o fallar, significado perdido, recálculo, reconciliación PCE/PCC, estado del dispositivo, tráfico y reversión.

Registro de fuentes

El expediente incluye RFC 9753, su ficha RFC Editor, el Datatracker, IANA PCEP, RFC 5440, RFC 8231, RFC 8281, RFC 8051, RFC 8233, RFC 8253, RFC 9325, el adyacente RFC 9757 y el adyacente RFC 9826. No se afirma ningún proveedor, despliegue, incidente, prueba de interoperabilidad ni nivel de adopción.