Resumen

  • El borrador de MPLS STAMP depende de parámetros y mecanismos configurados localmente en ambos extremos, mientras excluye de su alcance la señalización VCCV específica de STAMP.
  • Una respuesta válida demuestra un intercambio delimitado, pero no certifica que emisor y reflector compartieran toda la definición operativa de la medición.

El borrador draft-ietf-mpls-stamp-pw-21 dedica gran precisión a cómo un paquete de prueba entra y sale de un LSP o pseudowire. Sin embargo, la frase con mayor consecuencia de gobernanza está antes de esos formatos: el mecanismo que termina el paquete STAMP se configura localmente en ambos extremos. La señalización VCCV específica de STAMP en pseudowires queda fuera del documento. En un LSP, la configuración local es, por ahora, la única vía que el texto considera disponible.

La revisión 21, publicada el 10 de septiembre de 2026, también deja claro que el procedimiento está pensado para un único dominio administrativo. Eso limita el escenario, pero no elimina la pregunta. Una organización puede operar varios controladores, equipos y repositorios de cambio. Compartir dominio no significa compartir una transacción de configuración.

La identidad del paquete es una referencia

RFC 8762 sitúa la configuración y la administración de STAMP fuera del protocolo. Una CLI, un sistema OSS/BSS, SNMP o un controlador NETCONF/YANG puede preparar el emisor y el reflector. Después, el reflector actúa según su modo: puede mantener estado o no mantenerlo, y puede procesar paquetes autenticados o no autenticados.

RFC 8972 incorpora el identificador de sesión, el SSID. Antes de iniciar la prueba, el reflector debe disponer de todos los elementos necesarios para reconocerla; si el paquete no coincide, debe descartarlo. La norma no determina cómo llegan esos datos al equipo. El borrador MPLS exige un SSID distinto de cero y lo transporta en ambos sentidos.

En Format-1, la identificación combina dirección, puerto UDP, SSID y parámetros locales. En Format-2 desaparecen IP y UDP; el equipo une el SSID con el contexto de LSP o pseudowire —incluido el sentido— y con su estado configurado. Así, el dato del paquete funciona como una referencia a un registro local. No es una copia de ese registro.

Una referencia que resuelve correctamente no demuestra que los registros referenciados sean semánticamente iguales. El emisor puede vincular la sesión a una ruta de servicio y el reflector a una vista de mantenimiento. Pueden coincidir en formato y SSID y diferir en modo de estado, protección, TLV, fuente de reloj, tasa o umbral. No hay evidencia de que esas divergencias se produzcan en una implementación concreta. Hay, en cambio, una frontera verificable: el paquete no las puede descartar por sí solo.

Qué acuerda VCCV

Los pseudowires no parten de cero. RFC 5085 permite anunciar capacidades de canal de control y de verificación de conectividad. Los extremos intercambian combinaciones compatibles, seleccionan un tipo y lo mantienen hasta volver a señalizar el pseudowire. RFC 7708 incorpora el canal de tipo 4 mediante GAL y reglas de preferencia.

El borrador de MPLS STAMP utiliza esos mecanismos para exceptuar el paquete: sacarlo del reenvío normal y entregarlo al plano de control. Para cada sesión debe operar exactamente un mecanismo. Luego aparece otra función, la identificación. El tipo G-ACh indica si detrás viene STAMP con IP/UDP o sin esos encabezados. Excepción e identificación son piezas relacionadas, no equivalentes.

El acuerdo VCCV prueba que los extremos pueden compartir un canal compatible. No prueba que hayan negociado el SSID, el formato, el contexto concreto, las direcciones, los modos STAMP, los TLV, el tamaño, la cadencia, la fuente temporal o el objetivo de negocio. Precisamente esos elementos siguen dependiendo de configuración local o de mecanismos de gestión que el documento no prescribe.

La descripción justa no es «no existe acuerdo». Existen acuerdos de distinto alcance. El error aparece cuando una selección VCCV, una respuesta STAMP y una etiqueta de servicio se tratan como una sola prueba indivisible.

Una respuesta tiene un alcance legítimo

Si vuelve un paquete bien formado con el SSID esperado, el operador sabe algo valioso. El emisor lo transmitió; el contexto de reenvío fue utilizable; el extremo remoto lo exceptuó e identificó; y el retorno encontró suficiente compatibilidad para ser procesado. Según el modo y las validaciones, puede alimentar cálculos de retraso, variación y pérdida.

Ese éxito no identifica a quienes aprobaron el par de configuraciones. No fija sus generaciones ni demuestra que ambos extremos asignaran la sesión al mismo servicio. No certifica el estado de los relojes, el presupuesto de tráfico de prueba, el margen de MTU, el umbral de alerta o la decisión que podía basarse en la métrica. Una respuesta tampoco indica si uno de esos elementos cambió después de aprobarse la sesión.

El valor de la medición no desaparece por esa razón. Simplemente necesita una etiqueta de evidencia precisa. El intercambio es prueba del intercambio. Las afirmaciones sobre configuración, tiempo, servicio y autoridad requieren registros de esas superficies.

Un recibo bilateral de configuración

El complemento adecuado no tiene por qué agrandar el protocolo. Un recibo bilateral de configuración de medición puede existir en la capa operativa. Debe enlazar las identidades del emisor y reflector, el dominio administrativo, el LSP o pseudowire, la dirección, el mecanismo de excepción, el formato STAMP, el tipo G-ACh y el SSID. Format-1 añade direcciones y puertos; Format-2 añade los contextos de camino usados en ambos sentidos.

Después vincula los parámetros que dan significado al resultado: reflector stateful o stateless, modo autenticado o no, conjunto de TLV, reloj y prueba de sincronización, tamaño y MTU, tasa de envío, capacidad prevista del retorno, servicio observado, objetivo y categoría de decisión permitida. No todos estos datos merecen ir en el paquete; sí merecen una identidad común.

Cada configuración local aporta un hash o referencia de versión inmutable. El recibo nombra el controlador u operador responsable de cada lado, el revisor de la pareja, las pruebas de aceptación, la vigencia y la autoridad para revertirla. Si cambia uno de los extremos, nace una versión nueva. La aprobación anterior no debe heredarse por el simple hecho de que el SSID siga respondiendo.

También conviene separar estados de prueba. Capacidad VCCV común, parámetros STAMP compatibles, respuesta recibida, relojes conformes, métrica calculada y objetivo de servicio satisfecho son seis afirmaciones distintas. Un consumidor puede aceptar una de ellas sin convertirla en las demás.

Este recibo es una propuesta editorial de Daniel Kade. No es un campo nuevo, una norma del IETF ni una crítica a la interoperabilidad que ofrece el borrador.

El desacuerdo parcial es difícil de ver

Cuando todo falla, el diagnóstico suele ser visible: el reflector no reconoce la sesión y descarta. Cuando casi todo coincide, el sistema puede seguir funcionando y, a la vez, perder el significado original.

Un reflector que pasa de stateful a stateless sigue contestando, pero cambia la inferencia de pérdida. Una modificación del modo de autenticación altera la confianza que merece el resultado. Un cambio de camino puede conservar el SSID mientras el panel mantiene el nombre antiguo. Una fuente de tiempo degradada puede generar cifras ordenadas cuya incertidumbre ya no satisface el uso previsto.

Son hipótesis de diseño, no hechos sobre un proveedor. Las fuentes no aportan una incidencia ni un censo de implantación. Sirven para demostrar por qué el éxito del paquete no funciona como compromiso criptográfico de toda la configuración.

Fuentes

  1. Borrador MPLS STAMP, historial y registro API
  2. Revisión 21 HTML, texto, XML y comparación 20–21
  3. Votación del IESG, informe del shepherd y grupo MPLS
  4. RFC 8762 y RFC 8972
  5. RFC 5085, RFC 7708 y RFC 5586
  6. RFC 7799, Minimum Initial Specification y The Policy Mirror