The MPLS WG Archive

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

"Arvind, K" wrote:
>>> 
>>> Why is it necessary to stop sending the Hello in this case?
>>
>> It's not necessary.  But you don't want to waste CPU time and
>> bandwidth sending Hellos to a non-existant peer.
> 
> If the peer were non-existent, wouldn't the Hello protocol detect
> that and stop sending Hellos automatically?

It's not required to.

> According to
> draft-ietf-mpls-rsvp-lsp-tunnel:
> "If no Instance values are received, via either REQUEST or ACK
> objects, from a neighbor within a configured number of
> hello_intervals, then a node MUST presume that it cannot communicate
> with the neighbor." At this point a node has the option of either
> reinitiating or suspending the HELLO protocol ("When communication
> is lost or presumed to be lost as above, a node MAY reinitiate
> HELLOs."). If conserving  CPU time and bandwidth is an important
> requirement, an implementation can choose not to reinitiate HELLOs
> at this point.

Please read more than just the part you want to see.

A router does not have to stop sending hellos after detecting a neighbor
failure.  It is allowed to automatically reinstate hellos, and it is
allowed stop sending them.

It is wrong to assume that everybody is going to stop sending hellos
after a failure, just as it is wrong to assume that everybody is going
to continue sending them after that same failure.

If a neighbor address is configured (and therefore does not have to be
discovered), it makes sense to resume hellos immediately.  This allows
us to detect our neighbor's hello instance ID as soon as it starts
responding to hellos again (instead of waiting for some external trigger
to restart hellos), which may be advantagious to some implementations.

>>> IMO, the way the Hello state machine works is independant of the
>>> means to discover the neighbour. Even if the neighbour's RSVP
>>> states are gone, the neighbour should still respond to the Hello
>>> messages.
>> 
>> If all the state is gone, how can you be sure the switch's is still
>> running?
>> 
>> Suppose the state goes away due to a link failure (lost carrier on
>> the fiber).  When the link comes back up, there may be a different
>> switch at the other end of the fiber.  If so, that switch may not
>> be running RSVP, or it may not support Hello, or it may simply have
>> a different IP address.
> 
> Wouldn't the HELLO protocol automatically detect that the neighbor
> is down in this case as before?

A neighbor's failure to respond to Hello does not indicate failure
unless that neighbor was previously responding and later stopped.  A
neighbor that never responds may be perfectly operational, but doesn't
support Hello (or has Hello disabled).

Hello-detected neighbor failure is an edge-triggered event.  You can
detect an instant of failure.  You can not use it to detect the duration
of that failure.

-- David