[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Hosts using routing



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 Olivier.Bonaventure@uclouvain.be:
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 rrg-request@psg.com 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