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