Re: NHRP question

Yakov Rekhter <yakov@cisco.com> Thu, 19 October 1995 14:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11161; 19 Oct 95 10:19 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa11157; 19 Oct 95 10:19 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA13949; Thu, 19 Oct 1995 09:51:07 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id JAA21613 for rolc-out; Thu, 19 Oct 1995 09:58:51 -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 JAA21604 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:58:49 -0400
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA13945 for <rolc@nexen.com>; Thu, 19 Oct 1995 09:48:43 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id GAA02421; Thu, 19 Oct 1995 06:55:05 -0700
Message-Id: <199510191355.GAA02421@hubbub.cisco.com>
To: Joel Halpern <jhalpern@newbridge.com>
cc: rolc@nexen.com
Subject: Re: NHRP question
In-reply-to: Your message of "Thu, 19 Oct 95 09:07:23 +0400." <9510191307.AA10910@lobster.Newbridge.COM>
Date: Thu, 19 Oct 95 06:55:05 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.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/

Joel,

> 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.)

Ok. So, let's agree to drop S bit.

> 
> 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.)

Two points:

1. The requestor knows whether it is safe by purely local (to the
requestor) means. So, to assert whether the overall interaction is
safe, the only thing the requestor should know is whether the
information carried in the response is safe. And for this one bit
is sufficient. 

2. Assume that the requestor would be able to tell whether "the overall
interaction is "safe"". How would the requestor use this ?
  
> 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".

This suggests that a router, when it originates an NHRP Request, may
include in the Request not only its own IP address, but a set of
prefixes that are "stable" wrt to the router. That is a fine idea,
and I certainly would like to include it in the router-router NHRP.
Should this also be included in the current NHRP ?