RSVP-TE Scalability - Remote PathTear Message

RSVP Traffic Engineering (TE) protocol extensions to support Refresh-interval Independent RSVP (RI-RSVP) defined RFC 8370 for fast reroute (FRR) facility protection allows for greater scalability of label-switched paths (LSPs), faster convergence times, and decreased RSVP signaling message overhead from periodic refreshes. On Juniper devices, RSVP-TE runs in enhanced FRR mode, also known as RI-RSVP mode, by default, which includes protocol extensions to support RI-RSVP for FRR facility bypass originally specified in RFC 4090. Specifically, this feature introduces remote state teardown through Remote PathTear messages. As the refresh timeout of LSP state may be high, it is essential that LSP state be cleaned up properly even after local repair. If the ingress intends to tear down the LSP or if the LSP is preempted on any node upstream to the failure, it would not be desirable to wait till backup LSP signaling to perform state cleanup. To enable LSP state cleanup when the LSP is being locally repaired, nodes send the Remote PathTear message instructing the receiving node to delete LSP state. Remote PathTear messages allow clearing of the LSP state not only with the direct RSVP node, but also with RSVP nodes further away. For example, for an RSVP LSP going through the A-B-C-D path, if ingress A intends to tear down the LSP, then the following describes the mechanism to clean up LSP state on all nodes along the path of the LSP. 1. Ingress A sends normal PathTear to B. 2. To enable LSP state cleanup, B should send the Remote PathTear message with destination IP address set to that of D, and HOP object containing the local address used in the remote Hello session with D. 3. On D there would be a remote adjacency with B and so D should accept the remote PathTear and delete LSP state.