RE: some more transport MH ideas...

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

On Mon, 3 Sep 2001, Michel Py wrote:

> Peter,
>  
> What kind of "metric" or "as-path" would that solution use? 

I'm not sure I understand the question and its relevance to what I'm
suggesting. Regular routing would take place as normally.  This is not a
replacement for any kind of routing.  I would envisage BGP holding together the
strong aggregated framework as we currently do, just that BGP ripples should
end up being localized. BGP generally provides a local picture of how to get to
a particular destination.  We are more concerned with what happens further away
from the local picture we have. Ideally all MH paths would be possible, but in
practice some will be better - I am not sure BGP or any protocol based on it
will be able to provide detail on remote paths within violating our requirement
to keep the DFZ small via aggregation.  Strong aggregation essentially means we
toss away the fine grained information about remote routing.   We need to get
that kind of information back, but not transfer it through the DFZ.

> Among the possible paths to the target, how would a host know which one is
> the best? 

I would also propose to add weights to branches of the tree in order to find
the best address.  The host should have some idea of which paths work & which
don't, and hopefully build up a history in its cache.  This information should
be exchanged along with the address exchange.  Because intervening routers need
not have to participate in such an exchange other than sending unreachable
messages either way, there need not be any routing protocol like BGP involved. 
We have traditionally pushed that burden onto routers withe the resulting
scalability problems.  Basically I'm asking the other end to tell me the best
way to get to it rather than the next hop router.  We have to start thinking
that routers are going to have to be dumber and hosts are going to have to be
smarter for any kind of scalability to happen. 


> The depth of the reachability tree does not appeal to me, because a
> multi-homed entreprise might be very close to the aggregation point of one
> ISP and not of another one.

Just like we have suggested placing an artificial limit on the size of the DFZ,
I think that it may be wise also to place a limit on the global aggregation
depth. 3-4 does seem reasonable for the next 10-20 years.  Alternatively, with
careful design, one could use a b-tree approach to allocation. Start at the top
& only suballocate on an as needs basis.  If an aggregation point reaches it's
capacity, split it into 2 or more aggregation points by network renumbering and
redistribute the sub aggregations between them.

To answer your question perhaps we need to qualify the distances not only down
the tree but also between branches which would mean a trip up & down the tree
(assuming the usual upside down trees) to the alternative addresses.  The main
cost is in address exchange between the nodes. For diverse addresses, the
compression efficiency in exchanging addresses would be reduced.  

Of course if all reasonably large network providers insisted on having a
presence in the DFZ, we would have a highly meshed network & the depth would be
quite low.  A measure of a provider's visibility would be how close they are to
the DFZ.  One would hope that the closer they are to the DFZ, the more
redundacy those providers might have at layers below the IP layer.

With the way the ISP industry is heading, I believe the number of tiers we have
been used to is likely to decrease, so economics may sort out the depth
problem for us anyway.

Regards

Peter

>  
> Thanks,
> Michel.
> 
> 	-----Original Message----- 
> 	From: Peter Tattam 
> 	Sent: Mon 9/3/2001 6:37 PM 
> 	To: Multi6 Working Group 
> 	Cc: 
> 	Subject: some more transport MH ideas...
> 	
> 	
> 
> 	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