Application Statement

yakov@watson.ibm.com Tue, 07 March 1995 15:00 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04805; 7 Mar 95 10:00 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa04787; 7 Mar 95 10:00 EST
Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id JAA05900 for <rolc@acton.timeplex.com>; Tue, 7 Mar 1995 09:40:29 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: yakov@watson.ibm.com
Message-Id: <199503071440.JAA05900@maelstrom.acton.timeplex.com>
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6909; Tue, 07 Mar 95 09:41:24 EST
Date: Tue, 7 Mar 95 09:41:24 EST
To: Juha.Heinanen@lohi.dat.tele.fi
cc: rolc@acton.timeplex.com
Subject: Application Statement

Ref:  Your note of Sat, 4 Mar 1995 16:45:47 +0200


Juha,

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

What is certainly true is that for some scenarios of the router-to-router
case NHRP produces persistent forwarding loops. If NHRP is to be used
for the router-to-router case, then it must have mechanism(s) to prevent
its usage for the cases where a loop can occur. Does NHRP provide
such mechanism(s) ?

Perhaps NHRP should be constrained (at least initially) to be used
only as an address resolution protocol. However, by no means this should
make NHRP the only way to perform address resolution. Other approaches
should be tried as well. It would be very useful to get some operational
experience with various schemes and compare the results.

Yakov.