[net2-wg] Re: Link table management

[Rodrigo Fonseca]

Two proposals:

A. there is a 'pinned' bit in each entry in the LinkEstimator table.
Users may set this bit (which would end up being a reference counter),
and if it is not 0 the LinkEstimator would not be able to evict a
neighbor. Of course this is problematic if the link really ceased to
exist: what sense is there in keeping it there? The interface is
{insert, pin, unpin, event evicted)

B. The other is just the insert/evicted approach that SP takes: if not
already there, a client can request that a neighbor be inserted. If
the neighbor is evicted the client is notified, and can insert it
again. The problem with this approach is that conflicting policies may
cause thrashing. The interface is {insert, event evicted}.

I tend to think the latter is better, for it is simpler, and measures
could be taken to avoid churn, like setting a minimum time between
insertion and eviction.

Thoughts?
Thanks,
Rodrigo

On 5/16/06, Omprakash Gnawali <gnawali at usc.edu> wrote:
>
> > On Tue, 2006-05-16 at 10:54 -0700, Omprakash Gnawali wrote:
> > > > One option is to use the same approach as SP, by adding:
> > > > 1.  command result_t insert(am_addr_t neighbor, message_t* msg)
> > > > or
> > > > 2. command result_t insert(am_addr_t neighbor)
> > > >
> > >
> > >
> > > Should we also provide a functionality that makes this special entry
> > > not special if unsetRoot() is called on the root node?
> >
> > Let's not confuse the general abstraction of whether a protocol can
> > insert an important entry and the requirements of a particular routing
> > protocol.
> >
> > Phil
>
>
> My point is we might need the general ability to make an entry not
> special. I cited one example that makes this ability necessary.
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg
>