Resumen

  • El 13 de septiembre de 2026 apareció draft-ietf-pce-flexible-grid-17; el documento seguía en evaluación del IESG como Proposed Standard y en la agenda de la teleconferencia del día 17.
  • La revisión 16 colocaba dos errores bajo el Error-Type 24 de PCEP y llamaba Routing Problem a ese tipo, aunque el registro de IANA ya asigna el 24 a LSP instantiation error.
  • Un DISCUSS señaló que PathErr y Error Code eran terminología RSVP-TE, no PCEP. La revisión 17 borró las dos reglas y la solicitud de registro, pero conservó un nuevo tipo separado para la incapacidad de calcular RSA.
  • Corregir el número evita una ambigüedad en el registro. También elimina dos respuestas observables, por lo que la compatibilidad debe medirse con versión, condición y paquete, no solo con un nombre de función.

La alarma 24 ya estaba cableada

En una sala de control, pulsar la alarma 24 no describe el problema por sí solo. El cableado, la tabla vigente y el procedimiento asociado le dan significado. Si un manual nuevo usa el mismo número para otra avería, el operador puede ejecutar una respuesta correcta para el manual equivocado.

La revisión 16 de PCEP Extension for Flexible Grid Networks contenía esa clase de cruce. El trabajo amplía PCEP para que un Path Computation Client solicite a un Path Computation Element tanto una ruta como una asignación de espectro en una red óptica de rejilla flexible. La petición puede expresar simetría y elegir un método de asignación, por ejemplo First-Fit o Random.

Si el PCE no admitía la simetría o el método solicitado, el texto ordenaba generar PathErr con Error Code 24, Routing Problem, y uno de dos subcódigos nuevos. La sección 9.9 pedía a IANA registrar esas dos entradas bajo el Error-Type 24 existente.

El registro PCEP de IANA ya define ese número como LSP instantiation error, con referencia a RFC 8281. Además, la especificación base RFC 5440 llama PCErr al mensaje de error PCEP y usa Error-Type y Error-value. PathErr, Error Code y Routing Problem son piezas del lenguaje de RSVP-TE. La colisión unía no solo dos etiquetas, sino dos mecanismos operativos.

El 9 de septiembre, el director del Área de Enrutamiento Gunter Van de Velde lo convirtió en un DISCUSS formal. El historial de Datatracker conserva la explicación: el tipo 24 no podía redefinirse y la sección de IANA chocaba con asignaciones existentes. El mismo examen preguntó por el formato y la ubicación del Spectrum Allocation TLV y por la reserva del valor cero. Mohamed Boucadair abrió otro DISCUSS sobre excepciones de política, longitud, análisis de identificadores de enlace, descubrimiento y reglas futuras de asignación.

Desaparecieron dos salidas, no solo dos filas

La revisión 17 eliminó el párrafo que prescribía las respuestas para atributos no admitidos. También eliminó la sección 9.9 completa y su tabla de dos valores. La diferencia oficial no muestra un número sustituto. Para esta versión, dejaron de formar parte del contrato definido.

No desaparece toda señal de fallo. Sigue solicitándose un Error-Type nuevo, aún TBD, llamado Flexi-Grid RSA Error; su valor 1 dice RSA computation not supported y ahora el valor 0 queda marcado Unassigned. Por otra vía, un bit de NO-PATH-VECTOR comunica que no existe un camino que cumpla todas las restricciones de espectro. Conviene mantener separadas tres preguntas: ¿puede el PCE calcular RSA?, ¿encontró un camino viable?, ¿acepta el atributo concreto pedido por el PCC?

El nuevo texto incorpora más correcciones verificables. La longitud del Frequency Slot Selection TLV pasa a ser exactamente cuatro. El índice n puede ser positivo, negativo o cero. El PCE debe devolver un Label Set salvo error de política o validación. Una Inclusive Range contiene exactamente dos registros de identificador de enlace. Una referencia adopta el nombre ERO Hop Attributes subobject de RFC 7570, y la sección de seguridad añade la actualización TLS de RFC 9916.

La existencia de esas respuestas no demuestra que todos los puntos estén resueltos. El DISCUSS solicitaba reglas sobre colocación, orden, asociación, modificación y límite de tamaño del TLV. Cambiar el nombre del contenedor cubre una parte, no certifica el conjunto. El hecho acotado es que la colisión del tipo 24 fue retirada y que Datatracker cambió la revisión de IANA de IANA OK - Actions Needed a Version Changed - Review Needed.

Una revisión no vota por sí misma

El registro del documento lo mantiene como trabajo del grupo PCE, enviado al IESG para Proposed Standard. La API de Datatracker fecha la revisión 17 a las 09:57:08 UTC del 13 de septiembre. Su estado seguía siendo IESG Evaluation y la teleconferencia estaba prevista para el 17. No hay aquí aprobación, asignación final ni predicción del voto.

IANA vuelve a revisar porque cambió la solicitud. Ese estado tampoco equivale a rechazo. RFC 8126 define categorías como IETF Review o First Come First Served, pero el proceso aún debe decidir la política aplicable a los espacios nuevos.

La capacidad de descubrimiento ofrece otra pista. La revisión 16 decía que el diseño evitaba anunciar una nueva capacidad en PCEP OPEN y prefería informar el error, mientras remitía a los mecanismos OSPF e IS-IS de RFC 5088 y RFC 5089. La revisión 17 borra aquella justificación y mantiene que el descubrimiento puede anunciar capacidad RSA Flexi-Grid. La edición elimina una incoherencia narrativa; no prueba qué hace una red real.

La Última Llamada enlazó además la declaración IPR 3053. Es una notificación del expediente, no evidencia aquí sobre validez, esencialidad, infracción, obligación o precio de licencia.

Registrar la mudanza y el hueco

Un recibo de cambio útil debería guardar el quíntuplo anterior —protocolo, mensaje, tipo, valor y condición—, la fila ocupada del registro, la objeción, y el nuevo quíntuplo o la eliminación expresa. También necesita hashes de ambos borradores, versión de la implementación, resultado de una prueba de paquete, estado de IANA, estado del ballot y fecha de activación del operador.

Es una propuesta editorial mía, no una obligación del IETF. El Policy Mirror de Heng Lu ayuda a verla: la autoridad práctica nace del texto vigente, la copia desplegada y la ruta de ejecución. Una especificación inicial mínima puede normalizar el recibo sin imponer una política única. Y la disciplina de realidad, no promoción obliga a no convertir la revisión documental en una supuesta incidencia de producción.

No se ha demostrado un fallo de interoperabilidad ni que algún producto emitiera los dos errores borrados. La noticia es un cambio de contrato antes de la publicación: la gobernanza detectó una colisión y devolvió el espacio de nombres a un estado coherente.

Fuentes