The MPLS WG Archive

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

Vadlamani rao wrote:
>> 
>>Why?
>> 
>> This assumes that an entire switch (or interface) has failed, and has
>> been down long enough for its neighbors to detect the failure
>> (perhaps via routing table changes).
>>
>> Consider, however, a router that is heavily loaded and is running
>> low on memory.  Carrier on the link remains up.  Routing protocols
>> may continue updating each other.  Even RSVP Hello messages may
>> continue exchaning OK.  But the low-memory may result in some degree
>> of packet loss.  If an RSVP path message is received, and dropped due
>> to lack of memory, how is the previous-hop router going to detect
>> this and generate an error?
>>
>> The answer is that it won't.  But it shouldn't matter, because the
>> normal soft-state mechanism will refresh the state, hopefully
>> successfully on the next try.
> 
> David, I agree with your view. If there is a soft-state retry then it
> is fine.

There will be.  You can not turn off state refreshing.  Any
implementation that does not refresh RSVP state is broken.

> But, I do not think one can assume that it will "hopefully be
> successful" in the next retry.  I know you may say that it is
> implementation dependent (free to do whatever one likes to do). But, I
> prefer that it would be better for the draft to specify the recovery
> procedure in case of a failure after some N attempts.

I said nothing about failure recovery.

If a failure is detected, then the router detecting the failure will
generate appropriate tear/error messages and the ingress router will
attempt to re-connect (possibly involving a new ERO), or leave the LSP
down, awaiting administrative action.

I was describing the case when the ingress router does not quickly
receive a Resv message back after generating a Path message.  Because
message delivery is not acknowledged (assuming the RSVP group's refresh
reduction draft isn't implemented), there is no way to tell the
difference between a failure and a delay.

If there is a hard failure, the routing protocols will detect this and
propagate the state back to the ingress router.

If the ingress router chooses to abort the LSP setup before this
happens, it is free to do so.

There is no logical reason, however, why every implementation should be
forced to do this in the same way.  Such decisions are beyond the scope
of a signalling stack and may even be beyond the scope of an MPLS spec. 
Ideally, an operator should be able to adjust this behavior (give up
after some amount of time, or don't give up until the routing table
indicates that the Path can't possibly get through.)

-- David