ACK of purge packets
gardo@vnet.ibm.com Mon, 06 November 1995 12:45 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08796;
6 Nov 95 7:45 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa08792;
6 Nov 95 7:45 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 HAA18197;
Mon, 6 Nov 1995 07:19:13 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
HAA21222 for rolc-out; Mon, 6 Nov 1995 07:19:34 -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 HAA21213 for
<rolc@nexen.com>; Mon, 6 Nov 1995 07:19:28 -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 HAA18189 for <rolc@nexen.com>;
Mon, 6 Nov 1995 07:05:57 -0500
Message-Id: <199511061205.HAA18189@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9774;
Mon, 06 Nov 95 07:13:25 EST
Date: Mon, 6 Nov 95 07:13:26 EST
To: shur@arch4.ho.att.com, gray@ctron.com
cc: rolc@nexen.com, genecox@vnet.ibm.com
Subject: ACK of 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 Sun, 5 Nov 95 12:44:16 EST
David/Eric, Maybe the best thing to do is add a "request acknowledgement" flag in the Purge request packet since an acknowledgement is not always beneficial? >Jim,Bruce: > >>> Contrast this with a Purge request. "There is no real need for an >>> acknowledgement here since we already have to deal with the scenario >>> in which the purge is never sent because the station that should have >>> sent the purge crashed." [...] >It seems to me that the purge can/will be used to remove cache entries >that could cause routing loops (in router-router case), or an invalid >path (in the host-router case), when routing outside the cloud >changes. A reliable purge is very important for these cases. >Therefore I recommend keeping the Purge ack. -- Russell
- ACK of purge packets gardo
- ACK of purge packets gardo
- ACK of purge packets gardo
- Re: ACK of purge packets Eric Gray
- Re: ACK of purge packets Andrew Smith