The MPLS WG Archive

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

Eric Gray wrote:
> 
> As I said, this makes perfect sense - though I would be inclined to
> look at at least two aspects of this behavior in a different way.
> For one, I do not think of this as 'peer discovery' so much as I
> realize that the purpose of the 'Hello' messages is to prolong the
> validity of state information (in this sense, calling them 'Hello'
> messages, rather than 'Keep Alive' messages is misleading).

No.  The purpose is exactly opposite.  The purpose of RSVP Hello is to
terminate connections earlier than they would otherwise be terminated
(via soft-state timeouts.)

The only way to keep a connection alive is to refresh it (using the
features of RFC 2961, if available.)

> Clearly, there is no point in preservation of an empty set of state
> information.  For the other, I am inclined to think of snooping as
> listening to messages not intended to the 'snooping' implementation.
> I guess you could think of this as snooping, if - in a specific
> implementation - there is an intermediate (software) entity that
> redirects RSVP setup and teardown messages sending them to a
> separate (software) entity.  But that reflects a particular
> implementation's view of the world.

Maybe it was a bad choice of words.

I've always pictures RSVP Hello as something that can run independantly
of the rest of RSVP, issuing "tear all state of this interface" commands
to RSVP when Hello detects a neighbor failure.

In this sense, if non-Hello packets have an affect of Hello processing
it can be thought of as snooping.  But you're right that this sense is
not necessarily applicable, depending on how you visualize the protocol
and/or implement it.

-- David