Re: Comments on NHRP spec.,, modes of deployment etc.
shur@arch4.ho.att.com Wed, 16 August 1995 23:21 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22794;
16 Aug 95 19:21 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa22790;
16 Aug 95 19:21 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 TAA17531;
Wed, 16 Aug 1995 19:02:20 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
TAA00577 for rolc-out; Wed, 16 Aug 1995 19:01:38 -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 TAA00568 for
<rolc@nexen.com>; Wed, 16 Aug 1995 19:01:34 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: shur@arch4.ho.att.com
Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by guelah.nexen.com
(8.6.12/8.6.12) with SMTP id SAA17515 for <rolc@nexen.com>;
Wed, 16 Aug 1995 18:59:37 -0400
Received: from arch4.ho.att.com by ig1.att.att.com id AA27052;
Wed, 16 Aug 95 18:10:11 EDT
Received: from dahlia.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS)
id AA00108; Wed, 16 Aug 95 18:10:40 EDT
Received: by dahlia.ho.att.com (4.1/EMS-1.1 SunOS)
id AA03226; Wed, 16 Aug 95 18:10:56 EDT
Date: Wed, 16 Aug 95 18:10:56 EDT
Message-Id: <9508162210.AA03226@dahlia.ho.att.com>
To: bcole@cisco.com, gja@thumper.bellcore.com
Subject: Re: Comments on NHRP spec.,, modes of deployment etc.
Cc: rolc@nexen.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/
Grenville, Bruce: > > 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?). I agree. It would be nice if the NHRP client was a relatively simple beast. If servers needed to get complicated to deal with loop avoidance etc., it would also be nice not to burden the client. > > 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