Summary

  • Revision 09 of the SPRING working group's SR-MPLS STAMP draft replaces a broad reverse-path description with separate rules for an SR-MPLS path, an L3 service and an L2 service.
  • Without a specified return Segment List, a reflector can fall back to IP forwarding if it cannot select a reverse SR-MPLS path; a missing corresponding reverse L3 or L2 service instead requires it to drop the test and send no reply.

A Session-Sender receives a valid-looking STAMP reply. Did the probe complete the engineered SR-MPLS circuit under examination? Not necessarily. The newly revised Internet-Draft permits one kind of reply to arrive through IP forwarding after SR-MPLS return-path selection fails. In a service context, the same absence of a matching reverse service has a different result: silence. The distinction matters before anyone converts a timing sample, or a missing sample, into a claim about the forward path.

The change is visible in the document's own revision history. Version 08 said broadly that the Session-Reflector transmits replies over the same SR-MPLS path in the reverse direction. Version 09, posted on 28 September, replaces that compact account with sections 6.3.1 through 6.3.3. It describes the reply decision separately for ordinary SR-MPLS paths, L3 services and L2 services. This is a change in proposed text, not evidence that a network has already changed its behavior.

For an ordinary SR-MPLS path, an explicit Segment List sub-TLV in the Return Path TLV tells the reflector which reverse SR-MPLS path and label stack to use. If that sub-TLV is absent, the reflector selects a local reverse SR-MPLS path. If none can be selected, section 6.3.1 says it sends the reply format shown in Figure 10 by IP forwarding. That is a carefully bounded fallback. It does not license treating an explicitly requested but unusable path as an unmarked IP substitute; RFC 9503 has its own handling for return-path requests a reflector cannot use.

The service cases draw a harder boundary. For an L3 service, the reflector must find the reverse-direction service label stack associated with the L3VPN label on the forward test, and the sender's source address must be reachable in the corresponding L3VPN lookup context. Without the matching reverse L3 service, it must drop the test packet and transmit no reply. For an L2 service, it likewise needs the corresponding reverse L2 service label stack; if that service cannot be found, it must drop and not reply. An IP return from the generic path case is therefore not a proof of L2 or L3 service continuity.

There is a second asymmetry in interpretation. A received fallback reply is not the same as a measurement of a reverse SR-MPLS service path. Conversely, no reply can result from the reflector lacking reverse service context even if the forward probe reached it. The draft is about packet treatment, not a guarantee that an operator can distinguish every cause from the sender's bare result. One-way measurement has no reflector reply at all; section 7 explicitly excludes these section 6.3 return rules from that mode.

Datatracker lists the text as a SPRING working-group Internet-Draft with I-D Exists state and intended Informational status. It is neither an RFC nor a deployment finding. The immediate governance question is narrower: what evidence accompanies a number that may have traveled home through a different forwarding context than the one the number is meant to describe?

Sources