Application Statement

yakov@watson.ibm.com Wed, 08 March 1995 14:02 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02379; 8 Mar 95 9:02 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa02375; 8 Mar 95 9:02 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 IAA22603 for <rolc@acton.timeplex.com>; Wed, 8 Mar 1995 08:56:15 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: yakov@watson.ibm.com
Message-Id: <199503081356.IAA22603@maelstrom.acton.timeplex.com>
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3739; Wed, 08 Mar 95 08:57:13 EST
Date: Wed, 8 Mar 95 08:57:13 EST
To: bcole@cisco.com
cc: rolc@acton.timeplex.com
Subject: Application Statement

Ref:  Your note of Wed, 08 Mar 1995 00:25:39 -0800


Bruce,


>While NHRP can lead to routing loops, it can be configure in such a way
>that it will not.

It would certainly help if you (or somebody else in the group) would
produce a document describing how NHRP could be configured for the
router-to-router case in such a way as to avoid routing loops.

>If we throw up our hands on NHRP and go with routing protocol specific
>mechanisms, then the single solution goal of the ROLC group is not met...

It's far from obvious  whether this goal is realistic. Pursuing an
*unrealistic* goal may not be that useful.

>I think it would be unfortunate for us to require IP routing protocol
>specific solutions to this problem.

Whether it is "fortunate" or "unfortunate" to require IP routing protocol
specific solutions to the next hop resolution problem is a matter of
opinion. What is NOT a matter of opinion is that it was already shown
that NHRP doesn't work for certain router-to-router cases.

>Imagine an NBMA network with a single CIDR block allocated to it. Ie all
>stations on the NBMA net have IP addresses within the CIDR block, and all
>IP stations off the net have IP addresses outside the CIDR block.

To begin with, this may *or may not* be a realistic assumption. I would
especially question this assumption if an NBMA network has routers and
hosts that are under control of different organizations.

But even if there is such an environment, what are the mechanism(s) to
guarantee that this address assignment will be preserved -- that is
no host or router off the NBMA network wouldn't get an IP address out
of the CIDR block ?

>Extending NHRP to be aware of topology changes, or perhaps even to generate
>changes of its own would seem to be a possible solution for a class
>of more complex networks.

Would you explain how this would help to solve the problem that Joel
described in his message posted to this list in February ?

Yakov.