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.