Destination Address Mask in IP-specific part of Purge packet

gardo@vnet.ibm.com Tue, 24 October 1995 18:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17711; 24 Oct 95 14:12 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa17706; 24 Oct 95 14:12 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA08598; Tue, 24 Oct 1995 13:44:44 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA13754 for rolc-out; Tue, 24 Oct 1995 13:55:12 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id NAA13745; Tue, 24 Oct 1995 13:55:09 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: gardo@vnet.ibm.com
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id NAA08590; Tue, 24 Oct 1995 13:44:03 -0400
Message-Id: <199510241744.NAA08590@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4040; Tue, 24 Oct 95 13:50:05 EDT
Date: Tue, 24 Oct 95 12:44:11 EDT
To: rolc@nexen.com, luciani@nexen.com
cc: genecox@vnet.ibm.com
Subject: Destination Address Mask in IP-specific part of Purge packet
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
Ref: My note of Thu, 19 Oct 95 09:37:11 EDT

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