Resumen

  • La revisión 14 de draft-ietf-mpls-mna-ioam, fechada el 11 de septiembre de 2026, incorpora una regla para nodos cuya técnica de balanceo MPLS no se conoce.
  • En un flujo señalado mediante Flow ID MNA, los 19 bits de Sequence Number MNA que comienzan en el bit 1 de la LSE deben permanecer inmutables si se usa la pila de etiquetas para balancear y, desde esta revisión, también si no se sabe qué técnica se usa.
  • Descubrir la técnica del nodo queda fuera del alcance del documento. La inmovilidad de esos bits limita una causa de variación, pero no certifica que los paquetes hayan seguido una misma ruta.
  • Una lectura operativa responsable necesita un comprobante local de la hipótesis de hash, la fuente que la respalda y el punto desde el que se observó el tráfico.

La incertidumbre ya tiene una regla

Hasta la revisión 13, el texto contemplaba dos ramas. Cuando se sabía que la información de la pila de etiquetas participaba en el reparto de flujos, una porción de 19 bits del Sequence Number MNA debía mantenerse fija para el flujo identificado por Flow ID MNA. Cuando se sabía que el equipo empleaba otra técnica, todos los bits del número de secuencia podían variar.

La diferencia oficial entre las revisiones 13 y 14 añade el supuesto que faltaba. Si la técnica que usa el nodo no es conocida, se aplica el tratamiento conservador: la porción de 19 bits que arranca en el bit 1 de la Label Stack Entry permanece inmutable para ese flujo. A continuación, el borrador aclara que los mecanismos para averiguar las técnicas de balanceo están fuera de su alcance.

La decisión es pequeña en extensión, pero importante como regla de gobierno técnico. La falta de información no se convierte en autorización para utilizar todo el espacio variable. Se reserva parte del campo hasta que exista evidencia suficiente para clasificar el comportamiento del nodo en la rama más permisiva.

Cuando medir puede cambiar lo medido

RFC 9326 define IOAM Direct Export y permite usar Flow ID para correlacionar exportaciones del mismo flujo. Su número de secuencia suele comenzar en cero y aumentar en uno por cada paquete de ese flujo que lleva DEX; el RFC no prescribe cómo se asigna el Flow ID.

La propuesta de draft-ietf-mpls-mna-ioam-14 lleva esos campos al entorno de MPLS Network Actions. Flow ID MNA y Sequence Number MNA son opcionales y cada uno ocupa una LSE completa de formato D, de 32 bits. Descontados el bit inicial obligatorio y el bit S de fondo de pila, cada valor dispone de 30 bits. Si un nodo incorpora datos de la pila a su hash, un contador que cambia en cada paquete puede convertirse en entrada de encaminamiento. La instrumentación deja entonces de ser puramente pasiva.

La revisión también hace explícita la relación entre presencia y estructura: cuando el indicador F o Q está desactivado, debe omitirse toda la LSE correspondiente, incluidos sus bits fijos. En el encabezado posterior a la pila, el Block-Number debe ser cero si no se usa marcado alternativo; en la versión 13 era una recomendación, no una obligación. Ciertas combinaciones imposibles entre acciones dentro y después de la pila son paquetes malformados y deben descartarse.

El marco no nace de cero. RFC 9197 sitúa IOAM en un dominio limitado y ya pide considerar su interacción con ECMP y balanceo. RFC 9789 establece la arquitectura de MPLS Network Actions y RFC 9994 su solución básica. El documento depende además del borrador de encabezado MNA posterior a la pila y reutiliza definiciones que también aparecen en el registro IOAM Trace-Type de IANA.

No es una prueba de estabilidad

Mantener 19 bits constantes responde a una pregunta concreta: ¿cómo evitar que esta parte del contador altere una selección que quizá examine la pila? No responde qué campos mira de verdad el chip, cuántas etiquetas alcanza, si la configuración difiere entre nodos ni qué ocurre después de una actualización. Tampoco demuestra que un paquete instrumentado y uno ordinario lleguen al mismo conjunto de decisiones.

Flow ID ayuda a unir registros, pero no normaliza por sí solo la definición de flujo en todos los equipos. Una secuencia sin huecos no descarta una bifurcación de ruta; un hueco tampoco prueba pérdida en el plano de datos, pues puede originarse en la exportación o recolección. El borrador no aporta implementación concreta, captura, prueba interoperable ni medición de coste con la que resolver esos casos.

También hay una frontera de confianza. El uso está previsto dentro de un único dominio administrativo confiable. Los nodos de borde deben filtrar antes de admitir paquetes con estas acciones procedentes de otro dominio o de una fuente no confiable. Los datos auxiliares pueden viajar en claro y ninguna función debe confiar en su integridad si no existe una protección adicional.

Según la ficha del Datatracker, sigue siendo un Internet-Draft activo del grupo MPLS destinado a Proposed Standard. El grupo lo ha enviado al IESG para publicación y el estado del IESG es “Publication Requested”; el historial registra el avance. Los códigos solicitados continúan como TBA. Nada de ello equivale a asignación, aprobación final, RFC o despliegue.

Fuentes