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