Summary

  • The ingress requests lock by sending Path with ADMIN_STATUS A and Reflect set. The egress attempts to remove the LSP from client service; it confirms success in Resv with A set or returns OAM Problem / Lock Failure.
  • Once lock is confirmed, the ingress may target the egress or an intermediate node through RFC 7570 ERO Hop Attributes. The target validates A and an explicit entity identity before attempting loopback.
  • Loopback is Attribute Flags bit 13 in Path and RRO Attributes, not the A-bit lock state. A successful target may report the Loopback flag in RRO Hop Attributes while retaining A. Exit clears Loopback but retains A; only verified exit permits unlock.

RFC 6435 supplies the functional basis: lock takes a transport path out of client service while permitting OAM and possibly test traffic, and loopback returns test data so the originator can assess path integrity. RFC 7571 supplies the concrete RSVP-TE sequence. RFC 7570 supplies the hop-scoped addressing and conditional reporting carrier; it does not itself authorize the transition.

The authority is deliberately divided. Ingress has request power: it initiates lock, names a test target, requests loopback, requests exit, and later requests unlock. It cannot unilaterally establish those states. The egress authorizes service withdrawal and restoration by confirming or rejecting lock and unlock. The target separately verifies that A is set and that the desired loopback entity is explicitly identified by the ERO subobject immediately before ERO Hop Attributes. Without that identity, it ignores the request and should generate Bad EXPLICIT_ROUTE.

A target may therefore be the egress or an intermediate node, but addressing is not authorization.

For IPv4 and IPv6 prefix identifiers, the validation fixture is exact: the prefix must have host length 32 or 128. When the preceding item is a label subobject, its U bit selects the loopback direction. These are protocol validation rules, not claims that every deployment uses every identifier form.

The operational beneficiary is the OAM operator who can isolate path integrity to a named node while client traffic is withheld and test traffic is deliberately returned. The costs are equally concrete: an out-of-service interval, ordered state transitions, distinct failure outcomes, coordination among ingress, egress and target, and possible disclosure of node information through RRO reporting. RFC 7571 notes boundary-policy considerations; the sources do not establish that every domain exposes unmodified loopback state.

The evidence must be correlated. Resv A proves reported lock or unlock state; RRO Hop Attributes may report target loopback state; OAM Problem errors identify failures such as Lock Failure, Unlock Failure, Loopback Failure or Exit Loopback Failure. The Loopback bit is bit 13 and is not A. Neither RRO state nor a bit alone substitutes for the complete transition chain. RFC 5420 explains attribute processing across an LSP, RFC 3473 supplies the ADMIN_STATUS baseline, and RFC 7260 supplies the OAM Problem framework used by RFC 7571.

The counterfactuals are strict. With no confirmed lock, the target ignores loopback. With an ambiguous target, it ignores the request or returns Bad EXPLICIT_ROUTE. A failed loopback leaves the sequence incomplete and produces Loopback Failure. A failed exit produces Exit Loopback Failure and leaves A set. An unlock requested while loopback remains active must not proceed; the egress ignores it. The safe order is lock, confirmed loopback, exit, verified exit, then unlock.

No allegation is made here about vendors, operators, adoption, incidents, timing, performance, commercial value or customer outcomes. The RFC set gives no deployment prevalence, outage duration, failure-rate, latency or acceptance threshold. It also does not select a maintenance window or restoration decision. Those are operator decisions, not protocol facts.

Sources