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
- Re: ACK of register and purge packets shur
- Re: ACK of register and purge packets Eric Gray
- ACK of register and purge packets gardo
- Re: ACK of register and purge packets shur
- Re: ACK of register and purge packets Eric Gray
- Re: ACK of register and purge packets James Luciani
- ACK of register and purge packets gardo
- Re: ACK of register and purge packets James Luciani
- ACK of register and purge packets gardo
- Re: ACK of register and purge packets shur