Summary

  • A compatible node-protecting merge point retains its LSP state after a Conditional PathTear. Another receiver may have to delete the state and forward an ordinary teardown.
  • Remote PathTear lets a repair point clear state at a merge point before backup signalling is complete, including after repair failure or a change that removes a former merge point from the path.
  • These decisions depend on per-path roles and directional capability agreement. Incorrect support advertising can produce either lingering state or premature destruction.

The correct response is to keep it

A router has received a message whose name says that a path is being torn down. Its upstream neighbour has already deleted the corresponding state. Yet the receiving router must keep its own reservation alive. Forwarding the same instruction as an unconditional deletion would defeat the protection that the network had prepared.

This is a specified case in RFC 9705, published on the Standards Track in March 2025. It is not an account of an observed outage. The document updates RSVP-TE facility protection by making the meaning of teardown depend on a receiver's established role. A message name alone cannot tell an operator whether retention was correct.

The distinction solves a particular race. Under the older facility-backup procedures in RFC 4090, a downstream router could eventually clear abandoned state when refreshes stopped. But backup signalling might arrive after an ordinary teardown had already deleted state needed at the merge point. Extending refresh periods creates the opposite problem: abandoned state can linger for much longer. A timer cannot reliably choose between state that is obsolete and state that must survive a failure.

A role has to exist before the failure

An RSVP label-switched path, or LSP, has path state and reservation state, commonly represented by a PSB and an RSB. A point of local repair, the PLR, can divert the protected path through a bypass. Its merge point joins that protection arrangement to the continuing LSP.

Those descriptions are not permanent job titles for routers. The same machine can have different roles for different LSPs. A link-protecting merge point, LP-MP, protects the connection from the previous hop. A node-protecting merge point, NP-MP, corresponds to the previous-previous hop's protection around the intervening router. One router may hold both roles.

RFC 9705 requires more than a diagram suggesting that a router could be a merge point. Matching B-SFRR-Ready information must identify it as the bypass destination; a Node-ID signalling adjacency must be operational with the identified PLR; and the PLR must advertise the required RI-RSVP capability. The association mechanism comes from RFC 8796. Supporting that document's summary signalling alone does not establish support for the newer cleanup procedures.

This prior agreement gives a later negative message its meaning. A receiver does not acquire permission to retain a reservation merely by calling itself protected after the failure.

One conditional message, different obligations

Consider the RFC's A–B–C–D path. A can bypass B through another router and rejoin at C. C is therefore A's node-protecting merge point. If A–B fails and B is not itself a merge point for this LSP, B deletes its local path and reservation state. With node protection requested and no upstream PathTear received, B sends a Conditional PathTear downstream.

C must retain the LSP state because it is the compatible NP-MP. A receiver that is not an NP-MP instead deletes its PSB and RSB, removes the optional CONDITIONS object and sends an ordinary PathTear onwards. The condition is deliberately not passed blindly through the network.

There is a further boundary. If the sending neighbour has not advertised support for the new procedures, the receiver treats its Conditional PathTear as ordinary teardown and deletes the LSP state. The optional object is not an independent authority that overrides the capability agreement.

The CONDITIONS object uses class 135 and C-Type 1. Its merge-point flag selects conditional processing; without that flag, processing is ordinary. The detailed rule concerns the NP-MP, not every router that might broadly be called a merge point. That small distinction is exactly what a generic “MP retained state” event can conceal.

Keep the reservation; withdraw the obsolete protector

Retention does not mean freezing every associated fact. In the same A–B failure example, suppose B had previously advertised node protection that would merge at D. C retains the protected LSP on behalf of A, but B has deleted its own state and can no longer support that old protection arrangement.

C removes B's B-SFRR-Ready association and triggers a Path message to D. D then drops the remote path state that described B as its PLR. Where removal of that association is the only change, D does not propagate the Path further. One router has correctly preserved the LSP while helping another withdraw an obsolete protection relationship.

The remote path state is a specific signalling handle. Its RSVP_HOP identifies the PLR's Node-ID address so an explicit remote cleanup can be matched later. It is not a second customer reservation. Losing that handle must not automatically be reported as loss of the protected PSB and RSB.

Retention also has an end. An LP-MP can keep state after failure of its previous-hop link while the PLR remains reachable through the signalling adjacency; failure of that previous-hop router requires normal teardown. An NP-MP can retain across failure of the intervening link or router while its more distant PLR survives. Normal or Remote PathTear, reservation teardown and the specified adjacency failures end the relevant retention. A router holding both protection roles has additional conditions: after the previous-hop link fails, losing only one of the two adjacencies does not necessarily exhaust its reason to retain.

Graceful-restart grace periods also matter before an adjacency is declared failed.

Cleanup need not wait for the bypass

The other half of RFC 9705 deals with a PLR that must stop retaining state elsewhere. Suppose the ingress orders an LSP removed while local repair is starting, before the PLR has completed backup signalling. Deleting only the PLR's local state would leave the merge point waiting for work that will never arrive.

Remote PathTear addresses the merge point directly using its Node-ID address and the signalling-adjacency identity. It does not require a working bypass or completed backup signalling. The PLR sends the message and deletes its state; the merge point can then delete the corresponding path and reservation state. If local repair itself fails, the merge point propagates teardown toward the egress after processing the remote instruction.

A changed route record creates another explicit obligation. When a Resv RRO shows that a former NP-MP has left the LSP's path, the PLR sends Remote PathTear to that former merge point. In the RFC's example, B has already established backup signalling to D. A then clears former merge point C; C forwards an ordinary teardown toward D, but D retains the state supported by the completed backup signalling from B. “Remote teardown” therefore does not mean that every state at every downstream router must disappear.

Preemption can close the retention window in a different order. If a merge point loses its reservation after the previous-hop link has failed but before backup signalling arrives, it sends normal teardown and removes the state. The RFC describes a later backup Path being rejected because the required state has gone. That is a defined sequence to test, not evidence of a present product defect.

A capability claim can fail in opposite directions

RFC 8370 reduces reliance on short refreshes by combining reliable signalling, acknowledgements and adjacency failure detection. RFC 2961 supplies the reliable-delivery foundation. RFC 9705 fills the facility-protection lifecycle gap. An implementation using facility backup must not advertise the RI-RSVP capability unless it supports the complete newer procedures.

The reason is more serious than an untidy feature matrix. A router that falsely advertises support may never send the Conditional or Remote PathTear on which its neighbours rely, leaving obsolete state alive. A different falsely advertising router may receive the conditional object, fail to understand it and apply normal teardown, destroying state that should have survived. Similar capability errors produce opposite symptoms.

Correct partial deployment falls back deliberately. Missing support downstream shortens the Path refresh period and prevents the new Conditional or Remote PathTear behaviour on that segment. Missing support upstream changes the relevant refresh values and disables the new merge-point retention procedures. Node protection needs agreement across the intervening router as well as the PLR and MP. Upstream and downstream behaviour can therefore differ on the same device.

The source set establishes those rules, not vendor adoption, measured cleanup latency or traffic performance. The practical gain is a more explicit reason for each state transition. It remains the operator's task to establish that the implementation executed the reason correctly.

Sources