The Routing Over Large Clouds Mailing List Archive by date

["j.garrett" <jwg@mare.att.com>]

In message <199502031921.OAA12373@curtis.ansremote.com>, Curtis@ans.net wrote:

> In message <199502031616.LAA08448@maelstrom.acton.timeplex.com>, yakov@watson.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