RE: some more transport MH ideas...

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

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                            peter@trumpet.com
	Managing Director,    Trumpet Software International Pty Ltd
	Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210