The Routing Over Large Clouds Mailing List Archive by date

[yakov@watson.ibm.com]

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.