more flexible feature
gardo@vnet.ibm.com Wed, 25 October 1995 14:48 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11755;
25 Oct 95 10:48 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa11751;
25 Oct 95 10:48 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id KAA14282; Wed, 25 Oct 1995 10:15:59 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
KAA23128 for rolc-out; Wed, 25 Oct 1995 10:23:44 -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 KAA23119;
Wed, 25 Oct 1995 10:23:41 -0400
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 KAA14238; Wed, 25 Oct 1995 10:12:26 -0400
Message-Id: <199510251412.KAA14238@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8952;
Wed, 25 Oct 95 10:18:37 EDT
Date: Wed, 25 Oct 95 10:17:07 EDT
To: gray@ctron.com
cc: rolc@nexen.com, luciani@nexen.com, genecox@vnet.ibm.com
Subject: more flexible feature
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 Tue, 24 Oct 1995 14:30:31 -0400
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