ACK of register and purge packets

gardo@vnet.ibm.com Wed, 15 November 1995 17:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18494; 15 Nov 95 12:37 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18490; 15 Nov 95 12:37 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id MAA12442; Wed, 15 Nov 1995 12:11:08 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id MAA08549 for rolc-out; Wed, 15 Nov 1995 12:20:53 -0500
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 MAA08538; Wed, 15 Nov 1995 12:20:50 -0500
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 MAA12397; Wed, 15 Nov 1995 12:05:32 -0500
Message-Id: <199511151705.MAA12397@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4042; Wed, 15 Nov 95 12:13:48 EST
Date: Wed, 15 Nov 95 11:57:44 EST
To: luciani@nexen.com
cc: rolc@nexen.com, genecox@vnet.ibm.com
Subject: ACK of register and purge packets
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: Your note of Wed, 15 Nov 1995 11:50:25 -0500

Jim,

>> As proposed earlier, why not add an "acknowledgement request" flag in
>> the Purge packet.  There are environments and configurations where
>> acknowledgments are very useful, and I agree with you that there are
>> other environments/configurations where it is actually problematic.
>You are stating a case for exactly one of the scenarios for which
>the vendor private extension was created.  You categorically cannot add
>mandatory protocol mechanisms that cause, by your own admission, such
>"problematic" scenarios.

Ignoring the Purge is also a problem.
Let's move the purge protocol one way or the other, instead of
putting it halfway between required and not-required.  Move the purge
protocol to the extensions part of NHRP; otherwise, keep the ack
or add an "ack request" flag to the Purge request...

>> After the holding time expires, the server will stop sending Purges.
>> How many re-transmissions do you think a server will send before the
>> holding time expires?
>
>Based on your previous argument, "a long holding timer", the answer is
>quite a few just when extra traffic is highly undesirable!

Some implementations would use a constant maximum number of retries,
and IF WE HAD a purge mask the number of Purges would be reduced.
Is there a consensus on the purge mask?  I didn't see a response
from you to Andrew.

Have a nice day!
-- Russell