[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graceful restart - inter-protocol dependencies

When processing a loose hop, or even a strict hop with an address that is not an interface-neighbor address, RSVP relies on the route table to determine the next-hop interface (and possibly also the next-hop address.)
How is it right to ignore route changes after this? If the route table changes such that the selected next-hop interface is no longer the best (or is no longer valid), should RSVP ignore this? It seems to me like this could end up blackholing traffic in a way that will not be detectable without OAM.
The last I heard, network operators were not required to run OAM on every LSP. Has this changed? 

-- David


Alia Atlas wrote:

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 <mailto: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>
    [mailto: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