NHRP client == NHS?

Andrew Smith <asmith@baynetworks.com> Thu, 17 August 1995 21:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14309; 17 Aug 95 17:37 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14305; 17 Aug 95 17:37 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 RAA23885; Thu, 17 Aug 1995 17:22:31 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id RAA15818 for rolc-out; Thu, 17 Aug 1995 17:23:53 -0400
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id RAA15809 for <rolc@nexen.com>; Thu, 17 Aug 1995 17:23:51 -0400
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by nexen.nexen.com (8.6.12/8.6.12) with SMTP id RAA13270 for <rolc@nexen.com>; Thu, 17 Aug 1995 17:23:49 -0400
Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA08220; Thu, 17 Aug 95 14:21:56 PDT
Received: from milliways-le0 (milliways-le0.synoptics.com) by BayNetworks.COM (4.1/SMI-4.1) id AA10616; Thu, 17 Aug 95 14:22:54 PDT
Received: by milliways-le0 (4.1/2.0N) id AA20220; Thu, 17 Aug 95 14:24:22 PDT
Message-Id: <9508172124.AA20220@milliways-le0>
Date: Thu, 17 Aug 95 14:24:22 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
To: rolc@nexen.com
Subject: NHRP client == NHS?
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/

Regarding the report in the Stockholm minutes about Rob Coltun's idea
that NHRP clients be allowed to get to see all NHRP requests for them so that
they can do load balancing. I look forward to Rob's promised draft but 
thought to anticipate it anyway (forgive me if this discussion was had
in Stockholm but it didn't get reported in the minutes if it was!).

My question is: what is the difference between Rob's proposed scenario
and just saying that a "client" that wants to see NHRP queries just
implements a NHS colocated with the client?

The issue here is whether implementation of a NHS implies a co-located
entity which is running a full routing protocol or not. The draft is
currently vague on how NHSs get hold of their forwarding information
(this is probably a good thing - this is a routing issue, not an address
resolution thing). What Rob seems to be proposing is that a device (NHRP 
client) is allowed to influence routing (i.e. choice of ATM interface)
without having to run a routing protocol. I would suggest that the
address resolution protocol (NHRP is *not* a routing protocol according
to several people on this list) is not an appropriate place to do
this type of routing. 

I say: make the "client" run a routing protocol if it wants to do load 
balancing and do not open another can of worms with fixes and patches to 
the NHRP protocol which will affect every implementation.


Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************