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.

For the sake of clarity, 'your own messages' relates to messages addressed to
you rather than messages sent by you - wher 'you' refers to the implementation
or peer in question.

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

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