Re: ARP and NHRP question

["Eric W. Gray" <[e-mail]>]

Tim Salo wrote:
> 
> > From: James Watt <[e-mail]>
> > Subject: Re: ARP and NHRP question
> > To: [e-mail], [e-mail]
> > Date: Wed, 22 Nov 1995 14:54:14 -0500 (EST)
> >
> > Mark Laubach writes:
> > +--------
> > |> I would agree with what you seem to be implying. Native NHRP clients should
> > |> be permitted to exist and should be allowed to coexist with ATMARP clients
> > |> in a LIS.....
> > |
> > |Andy and I were already planning to issue a joint statement in the ipatm
> > |and rolc meetings regarding this very topic.  We'll be mostly replaying
> > |what has been discussed prior at the Danvers and the Stockholm meetings.
> > |It will be good to see some contributions and such on the topic.
> > +---------
> > My observation would be that I would prefer the complexity to be in the
> > server, not all of the clients.
> 
> I strongly agree.
> 
> > I would suggest that if the client speaks NHRP, it should always do so.  If
> > the NHRP server doesn't provide an answer (doesn't have one, doesn't want
> > to, etc.) then the client should ATMARP.
>

Here's where I get confused; if you really want the server to be the complex one and
the client to always use one protocol, then don't you want the NHRP server to do the
ATMARP (on behalf of the client) so that it can return an answer using NHRP?

> 
> I would like to see the client implement a single protocol for
> address/next hop resolution both within a LIS and across LIS boundries.
> 
> Right now, it seems like NHRP is the only candidate we have for a
> solution which allows a client to request both intra- and inter-LIS
> address resolution.
> 
> > This would suggest that most NHRP servers should also be ATMARP servers and
> > thus be able to answer all questions with one request, not two.
> 
> I think that we should ensure that NHRP servers always have complete
> information, so that an ATMARP request after an unsuccessful NHRP query
> is not needed.
>

Has, or can get complete information?

> 
> This seems consistent with the aim of moving complexity to the server,
> rather than the client.
> 
> -tjs



						Eric Gray