Resumen

  • RFC 9504 separa anuncio de capacidades, sincronización de estado, actualización e iniciación; cada mensaje conserva un alcance propio.
  • La delegación permite actualizar atributos definidos de un LSP, pero el PCC sigue siendo dueño del estado, conserva su política local y puede retirar la delegación.

Una consola puede exhibir una palabra que parece resolver todo: delegado. El peligro empieza cuando esa etiqueta se convierte en relato. Un equipo observa que un PCE recibió estado de LSP, que existe una delegación o que se emitió un PCInitiate, y deduce que la red ya está bajo mando del PCE. No lo está, al menos no por esos hechos solos.

RFC 9504 habilita el uso de PCEP con estado en redes GMPLS. El PCE y el PCC pueden negociar capacidades, intercambiar estado, solicitar cambios de atributos e iniciar solicitudes de establecimiento. El valor del protocolo está en que permite describir y coordinar acciones. Su límite es igual de importante: describir o solicitar no equivale a ejecutar, aceptar recursos ni producir un resultado para el cliente.

La capacidad es el primer filtro. Las funciones GMPLS pertinentes deben estar anunciadas y permitidas tanto por el PCC como por el PCE. Esta simetría evita atribuir a un extremo una función que el otro no admite. Aun así, una capacidad compartida sólo dice que la conversación puede existir. No prueba una reserva, un permiso operativo, una modificación de equipo o la existencia de una ruta de reenvío.

El segundo filtro es la custodia del estado. RFC 8231 exige que un PCE con estado aprenda el estado de LSP del PCC antes de computar o actualizar. Un State Report comunica un cambio; un Update Request pide modificar atributos. La delegación concede al PCE el derecho de actualizarlos para LSP concretos, y sólo durante esa delegación. El PCC conserva la propiedad del estado, somete los atributos a política local y puede recuperar la delegación. La diferencia entre poder enviar una solicitud y decidir si el cambio pertenece a la red local permanece intacta.

Por eso, un LSP delegado no prueba que haya cambiado de manos la autoridad de operación. Tampoco prueba que se aceptó una ventana, que se resolvió un conflicto de recursos, que se programó un cross-connect o que el plano de reenvío quedó instalado. RFC 8281 denomina LSP iniciado por PCE al que se instancia como resultado de una petición del PCE. El término identifica el origen de la petición; no sustituye la evidencia de aceptación del nodo final ni la verificación posterior.

La distinción entre camino previsto y camino real en los informes de RFC 9504 refuerza la cautela. Incluso un informe de camino real pertenece al ámbito del protocolo y del PCC que lo emite. Para afirmar que un servicio transportó tráfico, resistió una protección o cumplió un compromiso hace falta una observación adicional, con su propio momento, método y alcance.

Una operación madura mantiene la cadena visible: capacidad admitida, estado conocido, delegación específica, solicitud, decisión de política, acción de recurso, estado instalado y resultado observado. Ningún eslabón sobra. Los registros de PCEP son excelentes para sus propios hechos; se vuelven frágiles cuando se les exige demostrar decisiones comerciales o resultados que no midieron.

La idea de Heng Lu sobre especificación inicial mínima ayuda a leer esa cadena. El acuerdo común debe hacer interoperable el hecho mínimo, mientras que la adopción y la decisión que soporta riesgo permanecen locales. El código en funcionamiento es una evidencia importante de capacidad, pero no borra las fronteras entre una solicitud, una autorización y un efecto.

Fuentes