The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

But RSVP doesn't work this way.  It is a soft-state protocol.

If the route table changes such that the next-hop interface changes, 
RSVP is supposed to reroute the connection accordingly.

This probably won't happen if the next-hop is a strict-hop in an ERO, 
but it can easily happen if the next-hop is loose or if the LSP is 
signaled without an ERO (meaning routing is consulted to determine the 
next-hop to the egress node.)

If there is a paragraph in an RFC that says RSVP-TE should ignore all 
route-table changes once an LSP comes up, I missed it.

-- David

Jing Ruiquan wrote:
> 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


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls