Summary

  • The 28 September revision of an OPSAWG Internet-Draft adds an explicit collector-side warning: a PSID value cannot be correlated safely without knowing the scope in which it is distinguishable.
  • The draft still does not define how that scope reaches a collector. It is working-group text with IESG state I-D Exists, not an RFC or evidence of an operational fault.

Consider a central telemetry store receiving the same path-segment identifier from two networks. A query that joins records on the identifier alone could make their traffic appear to share a Segment Routing path. The mistake is not in the equality test; it is in treating an identifier whose uniqueness was promised only within one context as a global key.

That receiver-side boundary is the news in draft-ietf-opsawg-ipfix-path-segment-07. The 28 September version retains the proposal to export an MPLS PSID through psidMplsLabelStackSection and an SRv6 PSID through srhPsidIPv6. Those proposed IPFIX elements, controller mappings, and the warning that PSID reuse outside its intended scope is undefined were already present in revision 06. The two element numbers remain placeholders. Revision 07 does not introduce a new deployed telemetry service or an approved standard.

The material addition sits in Section 4.1.3. A collector or intermediate processor needs to know the scope within which an exported PSID is distinguishable; otherwise it can correlate flow records ambiguously or incorrectly. The authors expressly leave the mechanism for learning and respecting that scope to deployments. This is a narrower, more consequential point than saying merely that PSIDs should be unique: the party that assigns a marker and the party that joins observations may be different parties with different views of the namespace.

A PSID can represent one segment list, several lists, candidate paths or an SR Policy at different granularities. Section 4.1.1 therefore requires the analysis node to know the current mapping between the exported value and its path context, potentially through a controller or BGP-LS. That mapping is not inherent in the raw bytes. Its acquisition and maintenance are also left outside the draft's procedure. An equal value from another intended scope cannot be silently added to the same path history.

Nor does a stable identifier prove a stable service. The draft distinguishes path identity from path quality: degradation need not change a PSID, and local fast reroute may leave the identifier unchanged. A PSID can assist correlation with loss or delay measurements, but it is not itself those measurements. For SRv6, the existing G-Flag conditions still govern whether the last routing-header entry can be interpreted as a PSID; that is not the new 07 rule.

The published record is a draft proposal, not a report that any named operator made a bad join. Its security section also notes that exporting PSIDs can disclose path topology and traffic distribution beyond ordinary five-tuple flows. Better correlation thus has an access-control cost as well as a data-model requirement.

Sources