Re: Comments on NHRP spec.,, modes of deployment etc.
Bruce Cole <bcole@cisco.com> Tue, 15 August 1995 00:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23745;
14 Aug 95 20:49 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa23741;
14 Aug 95 20:49 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id UAA02528;
Mon, 14 Aug 1995 20:33:49 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
UAA13765 for rolc-out; Mon, 14 Aug 1995 20:19:31 -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 UAA13756;
Mon, 14 Aug 1995 20:19:26 -0400
Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id UAA02474;
Mon, 14 Aug 1995 20:17:42 -0400
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by
greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id RAA12695;
Mon, 14 Aug 1995 17:17:19 -0700
Message-Id: <199508150017.RAA12695@greatdane.cisco.com>
To: shur@arch4.ho.att.com
Cc: dkatz@cisco.com, bcole@cisco.com, dave@corecom.com, rolc@nexen.com,
malis@nexen.com
Subject: Re: Comments on NHRP spec.,, modes of deployment etc.
In-Reply-To: Your message of "Fri, 11 Aug 1995 17:00:51 EDT."
<9508112100.AA00841@dahlia.ho.att.com>
Date: Mon, 14 Aug 1995 17:17:19 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruce Cole <bcole@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/
> NHRP spec authors: > > I am confused by the way the current version of the spec. is worded > in that it appears that modes of deployment are described as different ways > in which servers may interact. The current plan is to remove server mode from the spec, as server mode (as it is currently described) falls apart when the IP network layer encapsulation is replaced by an LLC/SNAP encapsulation. Removal of server mode should eliminate the confusion, no? Note that there are several side effects of this encapsulation change which have not been discussed/emphasized on the list. Some which come to mind are: - No more requirement for a router-alert option, or the equivalent. Each hop within the NBMA now either supports NHRP, or (should!) fail to route the NHRP traffic. - Partial deployment of NHRP more problematic An intermediate hop which does not support NHRP causes NHRP address resolution to now fail. It should still be possible for a subset of the cloud to make use of NHRP... > I would like the spec to define and differentiate between the NHRP > client-server interface I see no difference from a protocol point of view. Any station within the NBMA can potentially send both request and response packets. > and the NHRP server-server interface, and keep > these separate from any discussion of modes of deployment. There is no server to server protocol.
- Comments on NHRP spec.,, modes of deployment etc. shur
- Re: Comments on NHRP spec.,, modes of deployment … Bruce Cole
- Re: Comments on NHRP spec.,, modes of deployment … Grenville Armitage
- Re: Comments on NHRP spec.,, modes of deployment … shur
- Re: Comments on NHRP spec.,, modes of deployment … Bruce Cole
- Re: Comments on NHRP spec.,, modes of deployment … shur
- Re: Comments on NHRP spec.,, modes of deployment … Andrew Smith
- Re: Comments on NHRP spec.,, modes of deployment … Bruce Cole