Re: [RRG] Hosts using routing

[[e-mail]]

 
Oliver,
At first, my own solution wouldn't have any scaling problems, in case the  
hosts and their links to different ISPs (via L2-connections) were supposed to  
become part of the  routing topology (because it doesn't have any scaling  
problems if the internet were even 1000 times bigger). Given the paradigm  of 
using the shortest path, it were up to the assigned weight value for each  link 
between the destination host and the respective router at the ISP-end of  the 
L2-connection, as to influence which routers (plural!!) would consistently  
choose a next forwarding hop as to reach the destination host via one very  
particular last hop.
 
I repeat: it would be up to the assigned weight value, and not up to the  
decision of the destination host.
After all, the destination host has no idea where the sender is  located. 
At the same time I must admit: It wouldn't be up to the sender's  decision 
either.
The sender may, eventually, be to far away. If the sender were in Europe  and 
the destination were in California  it would happen that the precise  last 
link can't be seen prior entering California. The same applies if the  sender 
were in Asia. He wouldn't see either which particular last hop could and  might 
be chosen ( this is the (bearable ) price for eliminating the routing  churn 
!) And as soon as the packet entered California, the first and all  consecutive 
routers would convey to some other route (than that one coming  from Europe) 
that ends by some other last hop to the destination  host.
 
Will say: although the scaling problem would be eliminated, multi-homing  
would be supported.
And this is not all: Yes, even multipath to multi-homing.
 
Heiner
 
 
 
Heiner
 
 
 
 
 
 
In einer eMail vom 18.04.2008 22:07:28 Westeuropäische Normalzeit schreibt  
[e-mail]:

Joel,

> In the discussion of who selects the Ingress link (to  the egress site, 
> just to confuse the language) the question of  whether the hosts have 
> enough information comes up.
> This then  leads to the question of whether the hosts participate in 
>  routing.
> There is a very strong tradition that we keep hosts out of  routing.
> While there are multiple factors, including control and  policy issues, 
> there are two important and closely related issues  that tend to cause us 
> to want to keep hosts out of the routing  game.
> 

...

> 
> Unfortunately, this tends to  lead to a situation where if we want the 
> hosts to have enough  information to sensibly influence Ingress link 
> choices, we also seem  to need to define a routing->host information 
> protocol to go with  that.

One possible alternative would be to allow the hosts to send  queries to 
a service that relies on routing information among others to  aid the 
host in selecting the best path according to routing metrics,  policies, 
performance ...

We have proposed in  
http://tools.ietf.org/html/draft-bonaventure-informed-path-selection-00
the  development of a new request-response service to aid hosts to rank 
paths  according to different metrics. This service has been presented at 
the  shim6 wg during the last IETF.

One realisation of this service is  described in
and  http://tools.ietf.org/html/draft-saucez-idips-00

Basically, the IDIPS  service works as follows. When a host needs to 
contact a destination which  is reachable via multiple addresses (e.g. 
shim6, destination with ipv4 and  ipv6 addresses, p2p content available 
from multiple servers, ...), then it  sends to the IDIPS service the list 
of the possible source addresses and  the list of possible destination 
addresses. The IDIPS server will reply by  sending an ordered list of the 
source-destination pairs that should be  used by the host. The IDIPS 
server can based its ranking on routing  metrics (e.g. IGP weigth, BGP 
decision process), performance (e.g. delay,  losses, ...) and policies 
configured by the network  administrator.

Comments on this approach are  welcome


Olivier

-- 
http://inl.info.ucl.ac.be ,  UCLouvain, Belgium

--
to unsubscribe send a message to  [e-mail] with the
word 'unsubscribe' in a single line as the  message text body.
archive: <http://psg.com/lists/rrg/> &  ftp://psg.com/pub/lists/rrg