The Routing Over Large Clouds Mailing List Archive by date

[Eric Gray <gray@ctron.com>]

Russell,

	Correct me if I am wrong, but I hadn't heard that any client could ignore purge
messages.  In saying that purge protocol is an optimization, it was my
understanding that the use of purge messages would be useful in reducing the
effect of bad information retained by NHRP components but could not be relied on.
I believe that the issuer of a purge message can reasonably expect it to be used
by any component that receives it.  I guess that such a component could simply
pretend not to have received any such message but, if clients are allowed
generally to ignore purge messages, this would make purge protocol somewhat less
than an optimization.


						Eric Gray



gardo@vnet.ibm.com wrote:
> 
> NHRP authors,
> 
> Apparently there is no strong opposition for this proposal; please
> add this to the version-5 draft.  Thanks!
> 
> I propose that a destination address mask field be added to the
> IP-specific part of the Purge packet.  With this feature, a much
> more efficient purge can be performed; a single Purge packet can purge
> a large number of cache entries, instead of sending a
> large number of Purge packets...
> I have not heard a strong technical reason against this proposal.
> If there is one, please tell me; otherwise, let's add it.
> 
> >From a NHRP protocol standpoint, this Purge mask field should be
> independent from the destination prefix extension found in
> Request/Reply packets.
> 
> Here are the only arguments I've heard against this proposal, but I
> do not think they are strong enough to stop this proposal:
>  1) If a client uses the destination to purge his cache, a mask does not
>     complicate things.  An additional bit-wise AND operation does not
>     complicate a client.
>  2) If the purge feature is only an optimization (an option that is not
>     really required), then this should not add additional overhead in
>     a minimal client implementation because these implementations
>     can ignore Purge packets (only an optimization).
> 
> -- Russell