The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

David,

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

You wrote:

> Eric Gray wrote:
> >
> > Interesting.  Are you perhaps referring to 'reading you own
> > messages' as snooping?  If you are, then the rest of what you say
> > makes perfect sense.
>
> Yes.  I'm talking about using incoming Path/Resv messages for a purpose
> additional to simply creating Path/Resv state.
>
> When you receive a Path or a Resv from a neighbor, and the TTL indicates
> that there were no non-RSVP routers between you and the neighbor, you
> can assume that the address in the HOP object is a directly-attached
> RSVP-capable router.  It is therefore an address you may want to start
> exchanging Hellos with.
>
> Once the last amount of state goes away, however, you can no longer make
> that assumption.
>
> If you continue sending Hellos, you can still detect a failure, if you
> stop getting acknowledgements, or if the neighbor's instance ID
> changes.  If the ID changes, you can even continue sending Hellos, since
> you know that the box is still there.  If the acknowledgements stop,
> however, you don't know if the box is administratively down, rebooting,
> crashed, or turned off.
>
> And it serves no purpose (other than perhaps in a debugging effort) to
> detect a neighbor failure when there is no established state, since
> there's nothing to tear down.
>
> -- David

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray