Re: Application Statement

["j.garrett" <[e-mail]>]

Jeffrey,

> John,
> 
> > If NHRP was the only solution available, I would understand
> > the "better a flawed solution than no solution" argument.
> > Fortunately, there are at least two different ways to solve the
> > address resolution problem - (1) embed subnetwork (e.g., ATM) addresses
> > in the routing protocol or (2) a query/response address resolution
> > protocol with querys sent to the router that provided the next-hop
> > information, rather than to the next-hop.  The query/response
> > approach resolves both next-hop router addresses and destination
> > host addresses, while embedding subnetwork addresses in the routing
> > protocol only resolves next-hop router addresses.
> 
> Couldn't this "query/response address resolution protocol" be interpreted as
> "server mode" NHRP? As I read the specification, there is not clear statement
> as to how NHS interoperate. Could not an NHS be a router? Thus, the NHS are
> the "routers" for the NBMA network. Therefore, every NHS has the correct answer
> and the NHS forwarding procedures in NHRP can be ignored.

The problem is that the routers for the NBMA network need a procedure
to get the correct answer.  The scope of today's address resolution
procedures is one IP network.  If the "optimal" next-hop is not on
the same IP network as the router that wants to use the next-hop,
how does the router resolve the ATM address of the next-hop?  My
suggestion (2) is to send a request to the peer router that advertised
the next-hop.  Could NHRP be modified to do this?  Sure.  It doesn't
do this in the current document.  Note that Directed ARP (RFC1433)
does.  Are there aspects of NHRP (or better, the original - NARP, RFC1735)
that would improve the Directed ARP syntax?  Probably yes.  The key
is that the router that provides the routing information is the
source that can also provide address resolution.  When that's
understood, we can quibble on syntax.

John Garrett
[e-mail]
908 580-4719