The MPLS WG Archive

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

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