[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some more transport MH ideas...
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
> 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 email@example.com
> > Managing Director, Trumpet Software International Pty Ltd
> > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
Peter R. Tattam firstname.lastname@example.org
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210