Re: NHRP question

Joel Halpern <jhalpern@newbridge.com> Thu, 19 October 1995 13:31 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10315; 19 Oct 95 9:31 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa10311; 19 Oct 95 9:31 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA13564; Thu, 19 Oct 1995 09:05:29 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id JAA21080 for rolc-out; Thu, 19 Oct 1995 09:12:27 -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 JAA21070 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:12:24 -0400
Received: from ns.newbridge.com (ns.Newbridge.Com [192.75.23.67]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA13550 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:02:16 -0400
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA09948 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:08:44 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma009939; Thu Oct 19 09:08:19 1995
Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA01422 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:08:18 -0400
Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA29868; Thu, 19 Oct 95 09:03:38 EDT
Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA10910; Thu, 19 Oct 1995 09:07:23 +0500
Date: Thu, 19 Oct 1995 09:07:23 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@newbridge.com>
Message-Id: <9510191307.AA10910@lobster.Newbridge.COM>
To: rolc@nexen.com
Subject: Re: NHRP question
X-Sun-Charset: US-ASCII
Content-Length: 1330
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/

Folowing up on the question of redundancy among the Q, S, and B bits,
I would agree that there is some redundacy.  I actually consider it
desirable.

With regard to the S and B bit redundancy, I would be willing to see
the S bit dropped if others agree with Yakov that we can not see
enough use to indicating the distinction.  (The most obvious use,
differences in time constants, should be done with other fields.)

With regard to the Q and B bits, I would like to keep them separate.
My reasoning is that I would like to be able to tell, when a reply
is making its way back to the requestor, whether the overall interaction
is "safe".  To do this, I need both the requestors safety bit and the
responders.  (One could say that the bit in the response is the inclusive
OR of the bit in the request and the status of the responder, but I would
expect that the requestor would like to know what the responder status was.)

The only change I would make to the Q bit is to generalize it closer to
the B bit.  It should indicate if the source may be considered safe.  It
would be set by a host when it makes a request.  When a router makes a
request it may set the Q bit only if it will restrict the use of the
received response to sources that are "stable".

Yours,
Joel M. Halpern				jhalpern@newbridge.com
Newbridge Networks Inc.