Re: more flexible feature
Eric Gray <gray@ctron.com> Thu, 26 October 1995 21:53 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25503;
26 Oct 95 17:53 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa25499;
26 Oct 95 17:53 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id RAA28920; Thu, 26 Oct 1995 17:27:45 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
RAA15230 for rolc-out; Thu, 26 Oct 1995 17:39:06 -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 RAA15221;
Thu, 26 Oct 1995 17:39:04 -0400
Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id RAA28911;
Thu, 26 Oct 1995 17:27:34 -0400
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id
NAA24623; Wed, 25 Oct 1995 13:45:31 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap
(V1.3mjr) id sma024579; Wed Oct 25 13:45:21 1995
Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1)
id AA10928; Wed, 25 Oct 95 13:48:14 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by
express.ctron.com (8.6.9/8.6.9) with SMTP id NAA04758;
Wed, 25 Oct 1995 13:45:13 -0400
Message-Id: <308E78CB.2FA8@ctron.com>
Date: Wed, 25 Oct 1995 13:50:03 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Eric Gray <gray@ctron.com>
X-Mailer: Mozilla 2.0b1J (X11; I; IRIX 5.2 IP12)
Mime-Version: 1.0
To: gardo@vnet.ibm.com
Cc: rolc@nexen.com, luciani@nexen.com, genecox@vnet.ibm.com
Subject: Re: more flexible feature
References: Your note of Tue, 24 Oct 1995 14:30:31 -0400
<199510251412.KAA14238@guelah.nexen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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/
Russell, As near as I can tell, your proposal does not impact on the storage/handling requirements of intermediate systems. It seems to have the greatest cost (associated with implementation) to the purge originator that wants to send it and offers potential traffic savings to all other system components. The biggest problem I see with it is it is one more thing that would need to be changed in NHRP to decouple it from IP. If we assume that it can be changed (by adding a mask-length field and, possibly, mask application rules?) in a way that allows it to be decoupled from IP-specific addressing, then it shouldn't be a problem to add a mask to the purge message. This may be an "if" of unknown size, however... Eric Gray Russell Gardo <gardo@vnet.ibm.com> wrote: > > Eric, > Do you (or anyone) see any real bugs in this change (add a mask)? > To summarize the change: Add a mask field alongside the IP destination > field in the Purge packet. No one has pointed out any real bugs > with this change... This change adds *flexibility* to the purge feature. > > I believe the comments you made about optimization are correct. > > > Correct me if I am wrong, but I hadn't heard that any client could > > ignore purge messages. In saying that purge protocol is an > > optimization, it was my understanding that the use of purge messages > > would be useful in reducing the effect of bad information retained by > > NHRP components but could not be relied on. I believe that the issuer > > of a purge message can reasonably expect it to be used by any > > component that receives it. > > -- Russell
- more flexible feature gardo
- Re: more flexible feature Eric Gray