The MPLS WG Archive

[Alia Atlas <akatlas@gmail.com>]

David,


In ref to RSVP-TE, a part of the question is who notices the routing change and does

the reroute.  In general, the idea of make-before-break and control by the ingress apply.


For a midpoint, a change to an LSP would be triggered by either the RSVP PATH 

message changing or by the selected next-hop interface no longer being available.  

Theoretically, a midpoint LSR could register for route changes to the specified next-hop, 

but to what purpose?? Once the midpoint LSR has determined the next-hop interface, I'd 

expect that to be treated as a strict hop, inside the LSR at least.

Alia

On 9/29/05, David Charlap <David.Charlap@marconi.com> wrote:

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