The MPLS WG Archive

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

"Feng, Mark" wrote:
> David Charlap wrote:
>>
>> If you do this (discovering neighbors for Hellos by snooping other
>> RSVP packets), then you may want to stop sending Hellos when the
>> all of the neighbor's RSVP state is torn, since you won't be able
>> to tell whether the neighbor went offline, changed address, or
>> simply doesn't have state.
> 
> 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 you discover a peer by snooping RSVP setup messages, then it makes
sense to "un-discover" it by snooping RSVP tear messages.

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

> This should be applicable in the case when the neighbour is
> configured.

When you explicitly configure a neighbor's address, then it makes sense
to assume that the configuration is correct.

> By stopping the Hello exchange, the neighbour might incorrectly
> think that there is a problem communicating with the current node.

So what?  If all state is gone, then what is the neighbor going to do? 
There's nothing left to tear down or signal an error for anyway.

-- David