The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] ARP and NHRP question
> From: James Watt <james@ca.newbridge.com> > Subject: Re: ARP and NHRP question > To: ip-atm@matmos.hpl.hp.com, rolc@nexen.com > 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. 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. This seems consistent with the aim of moving complexity to the server, rather than the client. -tjs
|
|