Resumen

  • El borrador individual del 28 de octubre plantea cinco elementos de información MPLS genéricos que pueden repetirse en una plantilla IPFIX ordenada. Si no se dispone de dirección IPv4, dirección IPv6 o longitud de prefijo en la posición K, el exportador no debe emitir ese atributo ni para K ni para posiciones más profundas. Saltarse el hueco convertiría la posición K+1 en una falsa K.
  • La propuesta conserva los campos posicionales del registro vigente de IANA, depende de un borrador aparte sobre exportación ordenada y advierte que un colector antiguo puede perder todo el nuevo conjunto sin anunciarlo. Los cinco identificadores nuevos todavía figuran como TBD.

No falta una etiqueta; falta lo que se sabe de ella

Una pila MPLS tiene tres etiquetas. El proceso de medición puede observar las tres y conocer la dirección de siguiente salto de la primera y de la tercera, pero no de la segunda. Si el exportador entrega solo dos direcciones, un colector que interprete cada aparición por orden pondrá la segunda dirección recibida en la segunda posición. El valor que pertenecía a la tercera etiqueta quedará unido a otra. Todos los bytes pueden ser auténticos y, aun así, la reconstrucción será falsa.

La sección 4.7 del nuevo texto cierra esa salida. Para mplsLabelIPv4Address, mplsLabelIPv6Address o mplsLabelPrefixLength, la ausencia de un valor en K impide emitir ese elemento en K y en cualquier profundidad mayor. Las apariciones deben ser consecutivas desde la posición uno. La pila física puede seguir teniendo tres entradas, y otros atributos pueden describirlas; ese atributo concreto ya no puede prometer alineación después del hueco. El borrador deja fuera los subconjuntos dispersos.

El tipo de etiqueta recibe otro tratamiento. Cuando mplsLabelType se desconoce en K, el exportador envía 0, Unknown. La posición se conserva con una declaración expresa de ignorancia. Para una dirección o longitud de prefijo el borrador no crea el mismo marcador; la serie termina. Un sistema que iguale ambas situaciones borraría una diferencia esencial entre «posición conocida, tipo desconocido» y «no puedo enumerar más posiciones de esta clase de dato».

La propuesta responde a una limitación del vocabulario actual. IANA registra diez elementos para secciones de pila MPLS, IE 70 a IE 79. Cada nombre lleva incorporada una posición, desde la etiqueta superior hasta la décima. El borrador propone repetir un solo mplsLabelStackEntry para varias profundidades y añade cuatro atributos genéricos. No retira los elementos posicionales: los colectores sin capacidad para entender el orden nuevo todavía los necesitan.

Hay un coste de tamaño. RFC 3032 define la entrada completa de pila en cuatro octetos: valor de etiqueta, clase de tráfico, bit de fondo y TTL. Los campos posicionales existentes exportan tres y dejan fuera TTL. El nuevo elemento lleva los cuatro, por lo que permite ver TTL más abajo en la pila, pero añade un octeto por etiqueta cuando esa información no hace falta. Un informe más rico puede ocupar más capacidad de exportación.

Ordenar no es mover columnas en una pantalla

RFC 7011 permite repetir un elemento de información en una plantilla IPFIX. La plantilla ordinaria no garantiza al colector que el orden de las repeticiones coincida con el orden de observación. El borrador complementario propone conjuntos de plantillas ordenados: el proceso de medición registra la secuencia real, el exportador la conserva y la señala, y el colector lee la enésima aparición como la enésima observación. Hay tres actores en esa promesa. Si uno altera la secuencia para que el resultado parezca limpio, el sello de orden pierde sentido.

Cada elemento tiene garantía de orden por separado. La segunda aparición de mplsLabelStackEntry y la segunda de mplsLabelType describen la misma profundidad porque la definición de ambos fija «segunda» como posición dos. El mecanismo no promete un orden relativo entre elementos diferentes dentro del mensaje. Esa relación nace de las definiciones, no de que dos campos queden juntos en el cable.

El cambio también puede dejar ciego a un receptor. El apartado 7 recomienda activar la exportación ordenada solo hacia colectores que ya sepan interpretar los nuevos conjuntos. Los demás podrían desecharlos enteros en silencio. Los elementos viejos y los nuevos tendrán que coexistir durante la transición. Actualizar al emisor sin comprobar al receptor puede reducir, no aumentar, lo que el operador ve.

El Datatracker identifica la propuesta como Internet-Draft individual activo. Sus cinco entradas nuevas siguen sin número definitivo en la sección IANA. Una prueba con un atributo central deliberadamente ausente, que muestre el registro emitido y las posiciones reconstruidas por el colector, permitiría comprobar si el software respeta la profundidad que el documento exige.

Fuentes