Re: Comments on NHRP spec.,, modes of deployment etc.

Grenville Armitage <gja@thumper.bellcore.com> Tue, 15 August 1995 15:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14531; 15 Aug 95 11:09 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14527; 15 Aug 95 11:09 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 KAA05342; Tue, 15 Aug 1995 10:52:12 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id KAA26924 for rolc-out; Tue, 15 Aug 1995 10:53:11 -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 KAA26907 for <rolc@nexen.com>; Tue, 15 Aug 1995 10:53:05 -0400
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id KAA05324 for <rolc@nexen.com>; Tue, 15 Aug 1995 10:51:17 -0400
Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id KAA21047; Tue, 15 Aug 1995 10:51:31 -0400
Message-Id: <199508151451.KAA21047@thumper.bellcore.com>
To: Bruce Cole <bcole@cisco.com>
cc: shur@arch4.ho.att.com, rolc@nexen.com, gja@thumper.bellcore.com
Subject: Re: Comments on NHRP spec.,, modes of deployment etc.
In-reply-to: Your message of Mon, 14 Aug 1995 17:17:19 -0700. <199508150017.RAA12695@greatdane.cisco.com>
Date: Tue, 15 Aug 1995 10:51:27 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Grenville Armitage <gja@thumper.bellcore.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/

Bruce,

	[..I think shur@arch4 wrote..]
>>> 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.

I understood the original question to request a clarification
of the fact that there can be two identifiable 'interfaces' involved
in NHRP (the host-NHS and the NHS-NHS), even though the same
packet format is used to propagate NHRP messages in each case.
So, in one sense there is indeed a server to server 'protocol',
it just happens to be the same as the client-server case.

The alternative interpretation is that every NHS is considered
a client of the NHS it forwards the query to, so ensuring
you only ever have a client-NHS case. Is this they way you
visualise it? (forgive me it says this in the spec - my memory
is not what it might be sometimes :)

The advantage of the former approach is that you'd then have
a conceptual framework for evolving the client-NHS and
NHS-NHS protocols in different ways if it seemed reasonable
in the future (e.g. to hide loop avoidance or black-hole detection
mechanisms from the clients?).

cheers,
gja