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 ********************************************************************************
- NHRP client == NHS? Andrew Smith