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.
- Application Statement dhc2
- Re: Application Statement Curtis Villamizar
- Re: Application Statement dhc2
- Re: Application Statement Jeffrey A. Buffum - Bay Networks
- Application Statement yakov
- Re: Application Statement Curtis Villamizar
- Re: Application Statement j.garrett
- Re: Application Statement Juha Heinanen
- Re: Application Statement Jeffrey A. Buffum - Bay Networks
- Re: Application Statement j.garrett
- Application Statement yakov
- Application Statement yakov
- Re: Application Statement Bruce Cole
- Application Statement yakov
- Re: Application Statement yakov
- Re: Application Statement Bruce Cole
- Re: Application Statement Bruce Cole
- Re: Application Statement j.garrett
- Re: Application Statement Curtis Villamizar
- Re: Application Statement j.garrett
- Re: Application Statement Curtis Villamizar
- Application Statement yakov
- Application Statement yakov
- Re: Application Statement Ross Callon
- Re: Application Statement Ted Matsumura
- Application Statement dhc2