El acuerdo que debe aprender a caducar

Resumen

• Los tipos de error experimentales de PCEP permiten acuerdos controlados entre participantes, no una asignación exclusiva para proveedores.
• RFC 9756 facilita que un ensayo use el mecanismo ordinario de errores, pero sus valores provisionales deben obtener asignaciones IANA al avanzar hacia la normalización.
• Retirar la convención implica revisar también quién interpreta los registros antiguos y qué significado recupera una versión de emergencia.

El acuerdo funciona. Esa puede ser, precisamente, la razón por la que resulta difícil terminarlo.

En un ensayo de red, dos equipos eligen cómo nombrar una nueva condición de error. Sus implementaciones coinciden, las pruebas son útiles y el operador incorpora el diagnóstico a su procedimiento de soporte. Ninguno de esos pasos es necesariamente imprudente. El problema aparece si la familiaridad convierte el número elegido para probar en una condición permanente de interoperabilidad.

RFC 3692 advierte contra esa transformación. Los valores experimentales son espacio compartido para pruebas, no identificadores exclusivos que un consorcio pueda convertir en una asignación mundial mediante acuerdo privado. Tampoco están destinados al despliegue general o al reconocimiento activado por defecto en productos. El usuario debe habilitar y configurar expresamente el uso experimental, con mecanismos de reprogramación explícita cuando corresponda.

La distinción importa al incorporar un tercer participante. Puede que el acuerdo inicial siga siendo correcto entre quienes lo diseñaron y, sin embargo, no describa lo que entiende una nueva implementación. La experiencia local demuestra que esos participantes se coordinan; no demuestra que el entorno futuro no tenga otra interpretación del mismo valor.

La unidad de significado tiene dos campos

RFC 5440, base de PCEP, define un objeto de error con Error-Type y Error-value. Uno clasifica el problema; el otro añade detalle. Para interpretarlo hace falta el par. PCEP lleva intercambios relacionados con el cálculo de caminos, de modo que una lectura equivocada puede desorientar la gestión de esas operaciones aunque el mensaje esté bien formado.

Publicado en marzo de 2025, RFC 9756 reserva los tipos 252–255, con sus valores 0–255, para uso experimental. El registro vigente de IANA recoge esa división. Los tipos 0–251 y sus valores quedan bajo IETF Review.

Dentro del ámbito experimental, las partes acuerdan qué pares utilizan y qué significan. Si varios experimentos usan las mismas implementaciones simultáneamente, deben mantener separados sus pares. No existe una categoría de valores experimentales dentro de los tipos ordinarios: encontrar una casilla sin asignar bajo un tipo conocido no autoriza a usarla como extensión privada de prueba.

Esto convierte el inventario de participantes en algo más que una lista administrativa. La entrada de una versión, un proveedor o un segundo ensayo puede cambiar la validez del acuerdo. El control necesario no consiste en prohibir cambios, sino en identificar quién comprueba que las nuevas combinaciones conservan un significado inequívoco.

Una salida técnica más corta

PCEP ya disponía de espacios experimentales para mensajes, objetos y TLV gracias a RFC 8356. Su planteamiento permitía alojar una función nueva en un objeto o TLV experimental si otro subregistro no ofrecía valores de prueba.

Para los errores, RFC 9756 considera innecesaria esa divergencia. Un objeto especial que transportara errores experimentales arbitrarios obligaría a apartarse del mecanismo habitual. Reservar tipos de error dentro de ese mecanismo reduce el trabajo especial y facilita la evolución de ensayos exitosos.

La facilidad tiene un alcance concreto. Cuando el trabajo avanza hacia una publicación en la vía de estándares, cada par necesita una asignación IANA. A veces serán valores nuevos bajo un tipo existente; otras veces habrá que asignar un tipo y sus valores. Los números del ensayo no adquieren permanencia por haber aparecido muchas veces en las pruebas.

El RFC describe el cambio de implementación como una sustitución numérica. No define un protocolo universal para negociar diccionarios antiguos y nuevos, ni un orden de actualización válido para cualquier red. Tampoco promete que dos versiones distintas coexistan sin preparación. Una transición controlada puede requerir aislamiento o una ventana coordinada si la implementación no permite la coexistencia necesaria.

El registro antiguo también tiene una versión

Un ejemplo hipotético muestra el trabajo que queda fuera de esa sustitución. La red cambia a las asignaciones nuevas y el sistema de observación actualiza sus etiquetas. Semanas después, una revisión vuelve a abrir un registro del ensayo. Si la herramienta aplica el diccionario actual a los números antiguos, puede presentar una explicación que nunca correspondió al evento original.

No se ha identificado aquí un producto que haga eso. Es una hipótesis de aceptación derivada de la dependencia entre valor y contexto. La prueba útil sería conservar un evento conocido del ensayo y verificar su interpretación después de actualizar el entorno.

Conviene separar el nombre público del detalle diagnóstico. RFC 9756 aconseja no publicar los pares numéricos experimentales y permite nombres textuales o simbólicos para explicar las condiciones. Así se evita que un número provisional se convierta, por repetición documental, en una promesa de compatibilidad.

El registro operativo tiene otra función. Puede necesitar el par original, la hora, el interlocutor y la revisión del experimento o del decodificador. Son recomendaciones de observabilidad, no un esquema obligatorio impuesto por el RFC. Deben adaptarse a lo que la implementación permite capturar con fiabilidad y a los controles de acceso de la organización.

Conservar ese contexto tampoco exige mantener indefinidamente habilitado el comportamiento experimental. Se puede conservar la capacidad de interpretar un archivo autorizado y, a la vez, retirar la emisión y aceptación de los valores antiguos en la red. Confundir ambas decisiones convierte la memoria del ensayo en una excusa para prolongarlo.

Más tipos de documento, no menos coordinación

RFC 9756 cambia además la política de los registros PCEP que enumera: de Standards Action a IETF Review. Según RFC 8126, IETF Review permite asignaciones mediante distintos tipos de RFC del flujo IETF, sometidos a su revisión por consenso; no queda limitado a Standards Track y Best Current Practice.

No equivale a atender al primero que llega ni a aceptar cualquier RFC de cualquier flujo. El grupo de trabajo consideró mantener una regla más estrecha en campos con pocos bits, pero confió en el proceso de revisión para tratar usos frívolos. Ese razonamiento documenta una decisión institucional; no prueba abuso o escasez efectiva.

Para compras y operaciones, la diferencia evita mezclar dos expedientes. Uno acredita el acuerdo local que permite un ensayo. Otro acredita la asignación obtenida por la vía aplicable. La coordinación entre socios no sustituye al segundo, y el segundo no certifica que el parque del operador haya completado su transición.

Un error desconocido no identifica por sí solo la causa

RFC 9756 contempla varios motivos para recibir un valor desconocido dentro de un tipo experimental reconocido: una implementación defectuosa, valores desincronizados entre participantes o experimentos simultáneos. El dato aislado no permite seleccionar una explicación.

El texto habla de registrar el error y de la posible terminación de la sesión. No impone que todo error PCEP cierre obligatoriamente la conexión. RFC 5440 contiene consecuencias diferentes, entre ellas cancelar solicitudes y preservar la sesión existente en determinadas circunstancias. Por tanto, ni una sesión abierta demuestra entendimiento correcto ni una cerrada demuestra colisión de códigos.

La disciplina editorial procede también de la propuesta de Lu Heng de describir la realidad sin convertirla en campaña. Aquí las fuentes establecen mecanismos y límites, no un incidente, una tasa de adopción o un coste medido. Su utilidad consiste en hacer visible una responsabilidad que el éxito del piloto puede dejar sin dueño.