Re: ACK of purge packets

Andrew Smith <asmith@baynetworks.com> Thu, 16 November 1995 19:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18754; 16 Nov 95 14:39 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18750; 16 Nov 95 14:38 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 OAA20919; Thu, 16 Nov 1995 14:10:37 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA28407 for rolc-out; Thu, 16 Nov 1995 14:23:56 -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 OAA28398 for <rolc@nexen.com>; Thu, 16 Nov 1995 14:23:53 -0500
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id OAA20866 for <rolc@nexen.com>; Thu, 16 Nov 1995 14:08:26 -0500
Received: from pobox.synoptics.com ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA06510; Thu, 16 Nov 95 11:16:48 PST
Received: from milliways-le0.engwest (milliways-le0.synoptics.com) by pobox.synoptics.com (4.1/SMI-4.1) id AA21796; Thu, 16 Nov 95 11:18:12 PST
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA01520; Thu, 16 Nov 95 11:18:10 PST
Date: Thu, 16 Nov 95 11:18:10 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
Message-Id: <9511161918.AA01520@milliways-le0.engwest>
To: gardo@vnet.ibm.com
Subject: Re: ACK of purge packets
Cc: rolc@nexen.com
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/

> From owner-rolc@nexen.com Thu Nov 16 10:42:25 1995
> From: gardo@vnet.ibm.com
> Date: Thu, 16 Nov 95 13:03:35 EST
> To: gray@ctron.com
> Cc: rolc@nexen.com, genecox@vnet.ibm.com
> Subject: ACK of purge packets

Russell,

> I suspect some clients would rather not receive a purge.
> A server must keep state associated with each
> server in order to perform a purge.  If a client informed the server
> that it does not want to receive a Purge, then the server could drop
> any state information that he would normally keep for that client for
> the purge protocol.  A server may set different holding times in Replies
> to clients that do not support the Purge versus those that do support
> the Purge.
> 
> What do you think?

Options are bad. Just implement it and the rest of the network will
thank you for it.

> -- Russell
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************