Summary

  • The 28 October individual Internet-Draft proposes five generic MPLS Information Elements to be repeated inside an ordered IPFIX template. For a next-hop IPv4 address, IPv6 address or prefix length unavailable at stack position K, the exporter must omit that attribute at K and every deeper position. It cannot export a sparse subset and let the collector mistake position K+1 for K.
  • The proposal keeps the existing positional Information Elements, depends on a separate Ordered Export draft, and warns that a collector without Ordered Export support can silently discard an entire ordered set. Its five proposed IANA IDs remain TBD.

A missing address is not a shorter stack

Imagine a three-label MPLS stack. The metering process observes three label entries, but has a next-hop address for the first and third labels only. A careless exporter could send two address values. The collector, told to read the first occurrence as the first stack position and the second as the second, would assign the third label's address to the second label. Nothing in the tidy result would announce the substitution. A dashboard would display more data than the exporter actually knew about that middle position.

Section 4.7 of the new draft forbids that move. If mplsLabelIPv4Address, mplsLabelIPv6Address or mplsLabelPrefixLength is unavailable at position K, the exporting process must not send an occurrence of that Information Element for K or any deeper stack position. The occurrences of each attribute remain consecutive from position one. A missing value does not make the stack shorter; it limits the claims that one particular exported attribute can safely make about depth. The draft says sparse subsets are outside its scope.

It treats label type differently. When mplsLabelType at position K is unknown, the exporter supplies value 0, Unknown, for that position. This keeps the position visible without inventing a control-protocol type. An address or prefix has no equivalent placeholder rule in this draft. Those attributes stop at the gap. The distinction matters: one field can honestly say “unknown here” while another can only stop making claims past the point where alignment would break.

The demand grows out of a defect in today's export vocabulary. The IANA IPFIX registry contains ten positional label-stack fields, IE 70 through IE 79. Each name bakes its position into the field itself: top label, second label, and so on through the tenth. The new draft proposes a single mplsLabelStackEntry repeated for as many positions as the ordered record describes, plus four generic per-label attributes. It does not deprecate the old fields. Old collectors will still need them.

The generic stack entry is also a different size. Under RFC 3032, a complete MPLS label-stack entry is four octets, including the TTL byte. Existing positional stack fields export three octets and leave TTL out; the draft's generic entry carries all four. That can expose TTL at deeper positions, but it costs an extra byte per label where TTL is unnecessary. The bargain is neither free nor automatic.

An ordered template is a promise between three processes

RFC 7011 permits repeated Information Elements in IPFIX templates, but the ordinary template does not guarantee that their listed order represents observation order. The companion Ordered Export draft would add Ordered Template and Ordered Options Template Sets. The metering process records values in observation order; the exporter preserves and signals that order; the collector reads the nth occurrence as the nth observation at the observation point. The promise fails if any participant in that chain treats position as decorative formatting.

In the MPLS draft, the ordering guarantee applies independently to each Information Element. The second mplsLabelStackEntry and the second mplsLabelType refer to the same stack depth because both definitions tie their second occurrence to depth two. The mechanism does not promise a meaningful relative order between different Information Elements as they appear on the wire. A collector that infers that extra relationship would manufacture structure the proposal has not supplied.

The migration has another trap. Section 7 says an operator should enable Ordered Export only toward collectors known to support its new sets. A collector that does not know them may silently lose the entire set. The old positional fields and new generic fields must coexist during that transition. A network report can become worse on the day its exporter becomes more sophisticated if the receiver was never taught the new grammar.

The Datatracker lists this as an active individual Internet-Draft. The five proposed Information Element IDs are still TBD in its IANA section. The missing evidence is an exporter-to-collector trace with a deliberately unavailable middle attribute, showing the actual ordered record and the collector's resulting stack positions. Such a trace would establish whether the proposed honesty survives software rather than merely appearing in text.

Sources