The MPLS WG Archive

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

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
> 
> 
> 


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