Re: Application Statement

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06715; 3 Mar 95 12:45 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa06702; 3 Mar 95 12:45 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 MAA14247 for <rolc@acton.timeplex.com>; Fri, 3 Mar 1995 12:37:13 -0500
Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.9/8.6.5) with ESMTP id MAA00515; Fri, 3 Mar 1995 12:12:33 -0500
Message-Id: <199503031712.MAA00515@curtis.ansremote.com>
To: dhc2@gte.com
cc: rolc@acton.timeplex.com
Reply-To: curtis@ans.net
Subject: Re: Application Statement
In-reply-to: Your message of "Wed, 01 Mar 1995 17:04:21 EST." <9503012204.AA04995@minuteman.gte.com>
Date: Fri, 03 Mar 1995 12:12:31 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>

Derya,

In message <9503012204.AA04995@minuteman.gte.com>om>, dhc2@gte.com writes:
> 
> 3. Key Features
> 
>    The most prominent feature of NHRP is that it avoids extra hops
>    in an NBMA with multiple LISs, as discussed in the previous section.
>    It provides the source with the NBMA address of the destination, if
>    the destination is directly attached to the NBMA. If the destination
>    station is not attached to the NBMA, then NHRP provides with the
>    NMBA address of the exit router.

The application statement MUST document situations in which the
protocol is NOT applicable.  You fail to do this.  There has been
considerable discussion of route loops and conclusion that NHRP has no
way to avoid them.  There is an application disclaimer in NHRP itself
in section 8.1 (Router to Router operation).  This topic is also
treated in the informational RFC-1620.

A statement of the limitations belongs in the key features section.

> 5. Discussion
> 
>    NHRP is well suited for IP networks where hosts are routers are 
>    interconnected via an NBMA network, especially if they are organized
>    in terms of multiple LISs. In a Router-to-Router operation, under 
>    certain conditions, a routing loop may occur. It is recommended that
>    during Router-to-Router operation, options that help to detect loops
>    be invoked and NHRP requests be reissued periodically. For the purpose
>    loop prevention, it is advisable avoid the non-NBMA paths between
>    the routers where NHRP is being run. If this option is not practical 
>    and the loops persist, then NHRP is not well suited for such environments.

The statement "For the purpose eeeg loop prevention, it is advisable
avoid the non-NBMA paths between the routers where NHRP is being run."
is total nonsense.  What you are stating is that if the Internet
deploys an ATM network where multiple Internet service providers
attach, those Internet service providers should never use routes
learned from other media.  This is an unworkable attempt to whitewash
the problem.

NHRP can only safely do address resolution.  You are trying to
perpetuate the already disproven claim that NHRP is a viable
replacement for routing.

Curtis