Re: Destination Address Mask in IP-specific part of Purge packet

Eric Gray <gray@ctron.com> Wed, 25 October 1995 13:01 UTC

Message-Id: <308D30C7.6C88@ctron.com>
Date: Tue, 24 Oct 1995 14:30:31 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Eric Gray <gray@ctron.com>
Mime-Version: 1.0
To: gardo@vnet.ibm.com
Cc: rolc@nexen.com, Jim Luciani <luciani@nexen.com>
Subject: Re: Destination Address Mask in IP-specific part of Purge packet
References: My note of Thu, 19 Oct 95 09:37:11 EDT <199510241744.NAA08590@guelah.nexen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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

Destination Address Mask in IP-specific part of P… gardo
Destination Address Mask in IP-specific part of P… gardo
Re: Destination Address Mask in IP-specific part … Eric Gray