The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDE84A488@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> 
> Both are IP paths, but the ICMP response path is hop-by-hop IP, while
> the RESV path is based on ERO (of the forward LSP). So LSP Ping requires
> a non hop-by-hop path, and that is why it is using the RESV message. 
> 
> > > -Shahram
> > 
> > Nice try. 
> 
> Let's try again:)
> 
> -Shahram


Although Ping is not clear as to why the LSP Ping is needed, I would
hope the reason is not for badly designed or throughly broken networks
that have partitioned IP routing within the core and clueless
providers that either think that's OK or aren't able to detect that.

I have been going on the assumption that the LSP Ping triggers an
immediate RESV which might otherwise be suppressed by refresh
reduction and would either verify the signaling of the LSP, or
possibly refresh it somewhere where it got dropped.

Here is what the ingress procedure says.

   When the ingress LSR suspects that the LSP may have failed and the
   RSVP control plane shows the LSP as operational, the ingress LSR MUST
   send LSP-ping messages to the egress over the LSP, periodically.  The
   value of the time interval should be configurable.

   The ingress LSR selects a unique Source_Identifer value for this
   particular test and places it in the LSP_ECHO object.  The ingress
   LSR includes the LSP_ECHO object along with the SESSION and
   SENDER_TEMPLATE objects of the LSP under test.

   If the ingress LSR does not receive an Resv message from the egress
   LSR that consists of an LSP_ECHO object within a period of time, it
   declares the LSP as "down".  At this point, the ingress LSR should
   apply the necessary procedures to fix the LSP.  This may include
   generating a message to network management, tearing-down and re-
   building the LSP, and/or rerouting user traffic to a backup LSP.

I appears that the intent is that one of two things will happen:

  1.  A RESV is forced.  The presence of a LSP_ECHO object provides a
      hint that shecking or somehow refreshing the forwarding state
      might be a good idea.

  2.  A RESV never comes back indicating that the signaling somewhere
      got broken and its time to set up an new LSP.

Maybe the motivation section should have a small paragraph added.

Curtis