I think only the originating node should do the rerouting with RSVP-TE .At
the same time, all the nodes will converge their IGP routing data base.
Rick
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of David Charlap
Sent: Thursday, September 29, 2005 2:37 AM
To: IETF MPLS List; IETF CCAMP List
Subject: Graceful restart - inter-protocol dependencies
Is there any point to implementing RSVP-TE's graceful restart without also
implementing graceful restart for routing protocols?
On the one hand, RSVP doesn't require routing to recover LSPs. It knows the
next-hop interface, because of the preserved data-plane connection.
Whatever other information it may need, the switch can either preserve
this information or recover it from a neighbor using the RecoveryPath object
(draft-ietf-ccamp-rsvo-restart-ext-03).
On the other hand, nodes more than one hop upstream of the failure will
detect the loss of routing-connectivity to the failed node if IGP graceful
restart is not also implemented. They may reroute the LSP away from the
failed node, or tear it down altogether, even though the data plane is still
active and RSVP graceful restart is recovering the control-plane state.
An originating node may consider the destination unreachable, as a result of
losing the routes even though the data-plane for the LSP is still up (which
can be confirmed via OAM.)
A transit node, when processing an loose ERO-hop, may choose to reroute or
fail the LSP if its local topology information says that the failed (and
restarting) node is not available. It might even choose to do this for an
established LSP, as a result of Path refresh processing.
My questions are:
1: Does this mean it's pointless to use RSVP graceful restart without
also using IGP graceful restart (for whatever IGP is active).
2: Is IGP graceful restart sufficient to prevent this problem? For
instance, OSPF's restart procedure requires all preserved state to
be thrown away if a topology change is detected.
3: An originating node can use OAM to validate the data plane of an
LSP, and choose to ignore what routing tells it about the
destination's reachability. But what about transit nodes? As far
as I know, MPLS doesn't support segment-OAM, and it would be
prohibitive for every transit node to run its own OAM streams
to detect self-to-end connectivity.
4: Are there other solutions to this problem?
One possible solution might be route-pinning, but RSVP doesn't have a
built-in mechanism for this. The usual workaround (signal the LSP,
requesting route-recording, then turn the RRO into an ERO for subsequent
refreshes) can work, but are there situations where even this would be
insufficient to prevent a transit node from rerouting/tearing the connection
in this particular situation (where RSVP is doing a graceful restart but the
IGP is not)?
-- David