Re: The Hole in my proposal
Curtis Villamizar <curtis@ans.net> Mon, 06 February 1995 19:10 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07357;
6 Feb 95 14:10 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US
id aa07300; 6 Feb 95 14:09 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 OAA20173
for <rolc@maelstrom.timeplex.com>; Mon, 6 Feb 1995 14:02:59 -0500
Received: from curtis.ansremote.com (localhost [127.0.0.1]) by
curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id LAA00332;
Mon, 6 Feb 1995 11:03:12 -0500
Message-Id: <199502061603.LAA00332@curtis.ansremote.com>
To: "j.garrett" <jwg@mare.att.com>
cc: curtis@ans.net, yakov@watson.ibm.com, jhalpern@newbridge.com,
rolc@maelstrom.timeplex.com
Reply-To: curtis@ans.net
Subject: Re: The Hole in my proposal
In-reply-to: Your message of "03 Feb 1995 20:10:00 EST."
<9502040111.AA02062@ig1.att.att.com>
Date: Mon, 06 Feb 1995 11:03:11 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
In message <9502040111.AA02062@ig1.att.att.com>om>, j.garrett writes: > In message <199502031921.OAA12373@curtis.ansremote.com>om>, Curtis@ans.net wrote > : > > > In message <199502031616.LAA08448@maelstrom.acton.timeplex.com>om>, yakov@wats > on.i > > bm.com writes: > > > Ref: Your note of Fri, 3 Feb 1995 09:33:08 +0500 > > > > > > > > > Joel, > > > > > > >There are a couple of possible solutions: > > > > > > Here is another one: > > > > > > (a) give up on "one size fits all" paradigm, (b) assume that the > > > solution will depend on the protocols the routers participate in, and > > > then (c) develop PROTOCOL SPECIFIC solutions. > > > > > > E.g. there may be one solution when the routers are BGP, and another > > > when the routers are just intra-area routers within a single OSPF domain. > > > > > > Yakov. > > > > > > I think this is along the lines of some of the thinking expressed in > > the past. For a topology that is constrained such that there are no > > multihomed networks not directly connects, NHRP is fine since there is > > no opportunity for loops. If there are multihomed networks behind a > > node, that node must run a routing protocol. This way all routers on > > the topology with multihomed networks behind them would still run a > > routing protocol. It would also help if all other nodes ran a true > > routing protocol instead of a query response protocol, so that > > suboptimal paths were not used to get to someplace smarter (but not > > absolutely required). Limiting the load on the latter group, making > > it possible for hosts to run a routing protocol, is one purpose of the > > routing information filters (RIFs). > > > > Curtis > > Some protocols (e.g., BGP) provide all of the > functionality needed except address resolution. > A BGP router, A, could advertise to a BGP peer, B, > the next-hop that A would use itself if the next-hop > was on the same (ATM) subnetwork as A and B, even if > the next-hop was not in the same classical LIS as B. > However, the advertisement would be useless to B, > unless B could determine the (ATM) subnetwork address > of the next-hop. > > Certainly A has a way to determine the (ATM) subnetwork > address of the next-hop, since it is the next-hop that > A would use. > > If A advertised the next-hop to B, B knows that A was > the source of the advertisement, and can reasonably > conclude that A must have a way to determine the (ATM) > subnetwork address of the next-hop. > > What is needed is a protocol for B to ask A for address > resolution help. Directed ARP, RFC1433 suggests such a > protocol. > > Using Directed ARP, routing protocols manage distribution > of routing information across the internet, and a > separate address resolution protocol manages the distribution > of address resolution information across a single Large Cloud. > > What is broken here? > > 1) The Directed ARP protocol in RFC1433 is the same as ARP. > ARP packets have no ttl field, and during routing churn > a Directed ARP packet could loop. This could be fixed by > adding a ttl field, so Directed ARP is different than ARP. > Or, another fix similar to record route could be borrowed > from NHRP. > > 2) Directed ARP does not dis-aggregate aggregated routes. > The router that advertises the next-hop must choose > whether or not to aggregate routes for which it would > use different next-hops, and advertise itself as the > next-hop to the aggregate or not. This is a tradeoff > of shorter routing paths versus less routing information > to store/process/distribute/... It is a policy > decision made by routing. > > 3) Others??? > > Thanks. > > John Garrett John, The ARP for large clouds is NHRP. It used to be NARP, be we decided to make it more complicated. :-) Now we are back to facing the fact that NHRP cannot be used for multihomed destinations. So we have a real routing protocol (I use BGP or IDRP as examples, but OSPF with LSA type 8, or the newer OSPF with an opaque LSA to accomplish the same, would do fine). In addition we have NHRP sering as ARP for the LC. We also have NHRP serving as proxy ARP for the single homed nets. I never suggested that we use directed ARP. Curtis
- The Hole in my proposal Joel Halpern
- The Hole in my proposal yakov
- Re: The Hole in my proposal Curtis Villamizar
- Re: The Hole in my proposal j.garrett
- Re: The Hole in my proposal Joel Halpern
- The Hole in my proposal yakov
- Re: The Hole in my proposal j.garrett
- Re: The Hole in my proposal Curtis Villamizar
- Re: The Hole in my proposal Curtis Villamizar
- Re: The Hole in my proposal j.garrett
- Re: The Hole in my proposal Curtis Villamizar