Re: some more transport MH ideas...

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Mon, 3 Sep 2001, Ramakrishna Gummadi wrote:

> Hi Peter,
> Doesn't BGP provide the reachability information? Can't the site's border
> router look at the BGP feeds from its upstream providers and deduce the
> reachability information? Am I missing something here?

see my other message.

By strong aggregation, we remove a lot of information from the DFZ.  We can see
localized information, but not remote information unless the other end tells
us.

> 
> -ramki
> 
> On Tue, 4 Sep 2001, Peter Tattam wrote:
> 
> > I wanted to do this more formally by putting together a draft, but I'd like to
> > run the ideas before everyone first.
> >
> > There is an important feature of strongly aggregated networks that I think is
> > being ignored.  If a path to a particular point of the aggregation tree is
> > unreachable, it is highly likely that other addresses to that branch of the
> > tree are unreachable too.  This can provide hints to the address selection
> > mechanisms to list addresses with prefixes for that branch to have lower
> > priority in the selection process.
> >
> > If the aggregated structure of such an internet can be relied upon, I believe
> > that through the use of what I coin "reachability trees", one can resolve some
> > of the criticisms of transport layer multihoming has when it comes to address
> > list explosion as such trees might be reasonably more compressible when
> > exchanging address information and also lead to efficiencies in TCP stack
> > design.
> >
> > To find forward reachability information, one would probably need to retain
> > somewhere locally a "reachability cache" which contained many such reachability
> > trees.  Such a cache could live on the host itself, or could be operated in a
> > similar manner to a DNS server or a router's routing table.  The information in
> > such a cache is likely to much more volatile than DNS though and less complete
> > than a routing table.  Personally, I think that each node should manage its own
> > cache as it would have much finer control over the validity of the data in such
> > a cache, and also a host is likely to have localized information for it's
> > current connections.
> >
> > One could exchange information between nodes as there is likely to be
> > reasonable correlation between host caches like there is in DNS, but there is
> > then a difficulty with issues of security.  If addresses are still exchanged
> > between end points, spoofing is eliminated.  It just leaves the issue of denial
> > of service.  If we used the 1 hop rule as in ND, this could be managed in a
> > reasonable manner within a local network environment.   Important network
> > events could also be multicast by routers to expedite cache updating.
> >
> > Please note that while this sounds very similar to a routing tree, in practice
> > it might be managed somewhat differently.  It also sounds a bit like ARP for
> > the wider internet.
> >
> > Peter
> >
> > --
> > Peter R. Tattam                            peter@trumpet.com
> > Managing Director,    Trumpet Software International Pty Ltd
> > Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> >
> >
> >
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210