Summary

  • RFC 9160 adds five mplsTopLabelType(46) values so an IPFIX record can express specified MPLS Segment Routing allocation contexts rather than leaving an observer to infer origin from a label number.
  • A typed export can support a bounded investigation. It is not proof that a particular network migrated, that a route is live, that a policy caused forwarding, or that a service succeeded.

The temptation begins with a short field. A top-of-stack MPLS label is a number. A record may contain it. A dashboard can group it. From there, it is easy to tell a larger story: this must be an IS-IS Segment Routing label, this must be a BGP policy, this must show a migration, this must explain a customer’s path. RFC 9160 exists because the first step in that story is not safe.

Published in December 2021, the IETF Informational RFC has Thomas Graf of Swisscom as its sole author. It introduces five new values for the pre-existing IPFIX Information Element mplsTopLabelType(46): Path Computation Element, OSPFv2 Segment Routing, OSPFv3 Segment Routing, IS-IS Segment Routing, and BGP Segment Routing Prefix-SID. Their purpose is precise. They let an export identify traffic by the MPLS SR control-plane protocol context specified by that label type.

That extra type matters because labels are not self-describing. RFC 9160 says IGP adjacency SIDs, LDP and dynamic BGP labels can share an allocation range. The same visible value can therefore fit more than one allocation story. Reading the number as if it carried its own provenance confuses an encoding with an explanation.

The document makes its operational use case deliberately narrower than a victory announcement. An operator can monitor a control-plane migration from LDP to IS-IS or OSPF Segment Routing, or from dynamic BGP labels to BGP Prefix-SIDs. With the label type joined to other stated IPFIX fields — including top-label addresses, stack section and forwarding status — the record can support inferences about how many packets were forwarded or dropped, possible drop reasons, and the provider-edge loopback address and label protocol. That is a useful evidence design: add an explicit discriminant before asking a record to answer a discriminating question.

It is not a deployment certificate. An RFC allocation cannot show that a named exporter is enabled, that a collector received a complete data set, that a record is authentic, or that the observation covered the relevant path. A typed record does not establish when a migration began or ended, why an operator chose it, whether a policy was installed, whether a packet reached its intended destination, or whether a customer experienced the consequence someone wants to narrate. It cannot make a label-type field into a live network map.

The BGP distinction in RFC 9160 makes the point unusually concrete. Existing BGP code point 4 concerns the label value in the MP_REACH_NLRI path attribute. The new BGP Segment Routing Prefix-SID code point 10 concerns a Label-Index TLV value. Both are called BGP in ordinary conversation; the RFC preserves the different technical objects rather than allowing the shared label to erase them. The registry value is not decorative metadata. It names which question an export is allowed to answer.

This is where Sofia Ren’s reading of Lu Heng’s Running-Code Primacy is practical rather than ceremonial. A coordination artifact can make a claim more legible; it cannot declare unobserved operation into existence. Minimum Initial Specification asks for the smallest deterministic proposition that a mechanism supports. Here, that proposition is not “the network migrated.” It is closer to: an exporter represented a specified top-label allocation type in an IPFIX record, under a known observation and collection arrangement. Everything stronger needs its own evidence owner.

For an investigation, preserve the joins. Keep the raw export, its exporter identity, observation point, collection interval, template version, integrity boundary and the particular fields used in an inference. Compare it with a control-plane record if the question is about control-plane state; compare it with forwarding evidence if the question is about traffic; compare it with service telemetry if the question is about a user-visible result. A label value is not a substitute for those records. Nor is a label-type value.

Graf’s contribution is therefore modest in the best technical sense. It gives an observer a way not to pretend that a bare label number contains a provenance it does not carry. The gain is not a grander dashboard claim. It is a cleaner boundary between a tagged packet-accounting fact and the operational story that still has to be demonstrated.

Sources