Re: Application Statement

"j.garrett" <jwg@garage.att.com> Wed, 08 March 1995 22:59 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14479; 8 Mar 95 17:59 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa14475; 8 Mar 95 17:59 EST
Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id RAA05080 for <rolc@maelstrom.timeplex.com>; Wed, 8 Mar 1995 17:55:52 -0500
Received: from garage.UUCP by ig1.att.att.com id AA16255; Wed, 8 Mar 95 17:57:32 EST
Message-Id: <9503082257.AA16255@ig1.att.att.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "j.garrett" <jwg@garage.att.com>
Date: 8 Mar 95 17:56:00 -0500
Original-From: garage!jwg (j.garrett)
To: Juha.Heinanen@lohi.dat.tele.fi
Cc: rolc@maelstrom.timeplex.com
Subject: Re: Application Statement

>    There are many people involved in the operation of the Internet that
>    feel that NHRP is not at all viable except as an address resolution
>    protocol.
> 
> if this were true, then i don't see much sense in deploying nhrp, since
> nbma arp as an address resolution protocol is much simpler.

Not only simpler, but for address resolution, nbma arp (RFC 1735)
works and nhrp doesn't.  nbma arp sends the address resolution
query to the peer that provided the routing information,
as described in RFC 1433.
nhrp sends the nhrp query to the same next-hop address that needs
to be resolved, a nasty chicken-egg problem.

> 
> -- juha
John