Re: [RRG] Hosts using routing

[Olivier Bonaventure <[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