Resumen

  • RFC 9752 habilita el objeto Vendor Information en PCRpt, PCUpd y PCInitiate, y aclara que Enterprise Number procede del registro IANA de Private Enterprise Numbers.
  • El PEN separa espacios de numeración, pero no autentica al editor del contenido, su versión, el soporte del receptor, la autorización ni el efecto en red.
  • Una operación defendible conserva desde los bytes y el decodificador hasta la correlación stateful, la política del PCC, la aplicación en equipo, el forwarding, el tráfico, el rollback y la alternativa sin extensión.

Un equipo de operaciones puede ver una secuencia muy convincente: PCUpd enviado, sesión TLS activa, PEN reconocido, PCRpt recibido. El problema es que esas cuatro luces verdes miden cuatro instrumentos, no una sola verdad. Entre el objeto recibido y el servicio existen decisiones privadas que el formato PCEP no describe.

RFC 9752 se publicó en abril de 2025 como Proposed Standard del IETF. La ficha del RFC Editor y el Datatracker registran que actualiza RFC 7470. Su logro consiste en permitir información específica de proveedor en operaciones PCE con estado. No convierte esa información en semántica abierta.

De la respuesta de cálculo al estado del LSP

RFC 7470 creó el objeto VENDOR-INFORMATION —clase 34, tipo 1— y el TLV tipo 7. Tras un Enterprise Number de 32 bits aparece información cuyo formato e interpretación quedan en manos de la empresa identificada. Puede publicarse, incluso en documentación comercial, pero la publicación no forma parte del objeto.

RFC 9752 aproxima ese contenedor a tres hechos distintos. PCRpt comunica desde el PCC el estado actual de un LSP. PCUpd solicita desde el PCE un cambio de atributos. PCInitiate puede iniciar creación o eliminación; la gramática extendida incorpora la lista privada a la instanciación. El TLV ya cabía en SRP, LSP u otros objetos stateful que admitieran TLV.

La cercanía sintáctica no define causalidad. Un campo privado en un informe no prueba que haya originado el estado; uno en una actualización no prueba que el PCC lo usara. Además, un PCRpt puede contener varios objetos y PEN diferentes. No existe en RFC 9752 una jerarquía general para resolver una contradicción entre dos contenidos privados o entre uno privado y un objeto normalizado.

Registro administrativo y procedencia son cosas diferentes

RFC 9752 señala de forma correcta el registro Private Enterprise Numbers y RFC 9371. IANA asigna PEN mediante First Come First Served y verifica quién puede modificar una ficha. Eso protege la contabilidad del registro.

El mismo RFC 9371 advierte que nadie puede controlar el uso privado de un PEN ni impedir que un tercero utilice el número de otro en sus datos. Por tanto, la presencia del número no es una firma del paquete. Tampoco demuestra que la documentación descargada provenga del equipo actual del titular, que no haya sido sustituida o que corresponda a la versión implementada.

La custodia semántica exige otro recibo: identidad del editor, versión exacta, fecha, hash del documento, hash del decodificador, operaciones admitidas, revocación y soporte. Si una empresa se compra o divide, si el producto se abandona o aparece un fork, esa cadena debe seguir siendo verificable sin convertir el contacto del PEN en una autoridad universal.

“Soportado” necesita un sujeto y una versión

Cuando una implementación reconoce el objeto pero no el Enterprise Number, RFC 9752 ordena ignorarlo según la regla heredada. También dice que un hablante no debería enviarlo cuando cree que el receptor no lo admite. Sin embargo, RFC 7470 deja fuera de alcance el anuncio de Enterprise Numbers y reconoce que la interoperabilidad funcional con otros proveedores requiere cooperación.

De ahí salen cuatro preguntas: ¿se reconoce la envoltura?, ¿se conoce el PEN?, ¿se implementa esta versión semántica?, ¿la política la habilita para este peer, mensaje y LSP? Ignorar puede ser una conducta compatible con el protocolo y, al mismo tiempo, eliminar el efecto que el emisor daba por supuesto. Decodificar puede ser correcto y, aun así, carecer de permiso.

La prueba de capacidad debería nombrar a ambos extremos, la versión, el conjunto de operaciones, la caducidad, la regla de downgrade y el fallback. El ensayo decisivo ejecuta también el servicio sin los bytes privados y con otro proveedor. Si el significado de los objetos estándar cambia silenciosamente, no hay interoperabilidad: hay dependencia oculta.

El PCC conserva la decisión local

RFC 9752 recomienda PCEP autenticado y cifrado mediante RFC 8253. TLS protege la sesión; no publica el diccionario privado ni autoriza cada LSP.

RFC 8231 dice que el PCC actúa sobre una actualización solo si lo permite la política local del gestor. Si actúa, inicia el setup y devuelve un informe del estado resultante. La delegación puede revocarse. RFC 8281 requiere que ambos extremos anuncien capacidad de instanciación y define errores para parámetros inaceptables, fallos internos y fallos de señalización.

La evidencia debe mantener separadas sesión autenticada, delegación, decisión de política, parsing, validación semántica y estado reportado. SRP-ID y PLSP-ID correlacionan mensajes, pero un PCRpt sigue siendo el testimonio del PCC. No es lectura independiente de RIB/FIB, tabla de etiquetas ni paquetes.

Un libro mayor para la cadena completa

El registro comienza con bytes exactos, PEN, posición, tipo de mensaje, peer y época de sesión. Añade manifiesto y decodificador firmados, versión, disposición del parser, límites, dependencias, objetos estándar y regla de precedencia. Después vincula solicitud, respuesta o error mediante SRP-ID, PLSP-ID y estado de delegación.

La cadena continúa fuera de PCEP: transacción del equipo, configuración aplicada, estado programado, observación de tráfico, impacto de servicio y rollback. Un estado instalado solo vale para el instante observado. Un paquete de prueba solo demuestra el recorrido observado. La prudencia consiste en no pedir a un recibo que pruebe la etapa siguiente.

RFC 9752 no crea nuevos requisitos de liveness, verificación de operación ni otros protocolos. Un YANG estándar puede mostrar el uso del objeto y el PEN, no sus detalles. El texto también identifica un posible canal encubierto y pide que el operador conozca el mecanismo de decodificación e inspeccione el dato. Un contador de objetos no basta.

El registro PCEP de IANA confirma los códigos. Los RFC establecen el mecanismo; no prueban despliegue, fallo, explotación, mejora o resultado comercial alguno. Las ideas de Running-Code Primacy, Minimum Initial Specification y Reality Layers de Heng Lu se usan aquí como marco editorial declarado: el estándar coordina el contenedor y la realidad operativa se establece con implementación y observación. No son requisitos del IETF.