Subject: RE: some more transport MH ideas...

From: "Michel Py" <[email-masked]>
Date: Mon, 3 Sep 2001 19:50:39 -0700

Peter,
 
What kind of "metric" or "as-path" would that solution use? Among the
possible paths
to the target, how would a host know which one is the best? 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.
 
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                            [email-masked]
	Managing Director,    Trumpet Software International Pty Ltd
	Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Peter Tattam <[email-masked]>
Date: Tue, 4 Sep 2001 13:35:09 +1000 (EST)

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

---

From: Peter Tattam <[email-masked]>
Date: Tue, 4 Sep 2001 15:38:11 +1000 (EST)

> will be able to provide detail on remote paths within violating our requirement
                                                 ^^^^^^
should read "without".