The MPLS WG Archive

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

David,

    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.

You wrote:

> Eric Gray wrote:
> > David Charlap wrote:
> >>
> >> If you discover a peer by snooping RSVP setup messages, then it
> >> makes sense to "un-discover" it by snooping RSVP tear messages.
> >
> > Sorry, I don't buy this.  Entirely aside from whether or not this
> > is what was being proposed, it doesn't make sense to conclude that
> > a peer has gone away because it has torn down all current signaling
> > state.  Not that I will necessarily agree that it makes sense to
> > 'discover' RSVP peers using setup messages, either...
>
> OK then.
>
> How do you propose that a router determines what addresses to send
> hellos to?  Do you want to mandate that this be configured?  If not, how
> would you propose learning about neighbors?  Inspecting the routing
> table for peers may result in a lot of non-RSVP neighbors, which you
> will be flooding with Hellos for no good reason.  The only way to ensure
> that the neighbor is using RSVP is to note any RSVP messages that may
> come from that neighbor.
>
> Once you use this mechanism, how would you propose removing a neighbor
> from your list of neighbors to send hellos to?  Surely you don't want to
> keep sending them forever, simply because you received one message a
> long time ago.  When do you stop if you don't stop when the last Path
> adjacency goes away?
>
> Finally, keep in mind that the purpose of Hello is to summarily tear
> down state without waiting for a soft-state timeout.  If you have no
> established state, what do you gain be sending them?
>
> -- David

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