Re: some more transport MH ideas...

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

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?

-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
>
>
>