Re: Application Statement

Curtis Villamizar <curtis@ans.net> Fri, 03 March 1995 20:32 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10304; 3 Mar 95 15:32 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa10173; 3 Mar 95 15:31 EST
Received: from curtis.ansremote.com (curtis.ansremote.com [152.161.2.3]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id PAA17665 for <rolc@acton.timeplex.com>; Fri, 3 Mar 1995 15:25:21 -0500
Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.9/8.6.5) with ESMTP id PAA01043; Fri, 3 Mar 1995 15:24:15 -0500
Message-Id: <199503032024.PAA01043@curtis.ansremote.com>
To: dhc2@gte.com
cc: curtis@ans.net, rolc@acton.timeplex.com
Reply-To: curtis@ans.net
Subject: Re: Application Statement
In-reply-to: Your message of "Fri, 03 Mar 1995 13:56:39 EST." <9503031856.AA06227@minuteman.gte.com>
Date: Fri, 03 Mar 1995 15:23:21 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>

In message <9503031856.AA06227@minuteman.gte.com>om>, dhc2@gte.com writes:
> Curtis,
> <NHRP can only safely do address resolution.  You are trying to
> <perpetuate the already disproven claim that NHRP is a viable
> <replacement for routing.
> 
> Well, that was not my intention.
> 
> <Curtis
> 
> Derya


Derya,

The applicability of NHRP is limited.  The application statement must
be very clear about what the limitations are.

Throughout your draft you explain that NHRP can be used for router to
router next hop resolution without mention of the limitation.  See
below.

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.  You are making claims to the contrary, then making brief
mention of the problem and attempting to make it sound like it's not
really very important because there are workarounds.  There are no
viable workarounds for a very broad class of topologies and the
applicability of this protocol is limited.  Your draft needs to say
this very clearly.

Curtis


  2. Introduction

  [...]

   If the destination station is not part of 
   the logical NBMA network, NHRP provides the source with the NBMA 
   address of the egress router towards the destination.

  3. Key Features

   ...  If the destination
   station is not attached to the NBMA, then NHRP provides with the
   NMBA address of the exit router.

   ...

    o NHRP Forward and Reverse Next Hop Server Record Options (IPv4). 
      These options keep track of NHRP Server addresses. They are used
      in updating cache tables and in detecting loops.

[ no mention that off network loops cannot be detected and persistant
loops can form]

  5. Discussion

   ...  It is recommended that
   during Router-to-Router operation, options that help to detect loops
   be invoked and NHRP requests be reissued periodically.

[ I'm not aware of any NHRP scheme that detects routing loops off
network, nor does reissuing requests remove the loops ]

   ...  For the purpose
   loop prevention, it is advisable avoid the non-NBMA paths between
   the routers where NHRP is being run.

[ as I've already pointed out, this is an absurb attempt to minimize
the issue ]