Subject: [RRG] Hosts using routing

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Apr 2008 12:07:21 -0400

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.

Firstly, it is clearly desirable to be able to evolve the routing 
protocols and routing system behavior without having to change every 
host.  The IS-IS vs OSPF issues are messy enough.  They would be MUCH 
harder if the selection also had to allow for what the hosts support. 
Heck, the migration from RIP to either link state protocol in sites 
would have been effectively impossible if the hosts needed to be able to 
see and understand the routing of the day.  (They would have understood 
RIP.)
The second, related aspects is that good implementations of routing 
protocols are complex.  And given the information segregation, to really 
have enough information using existing routing protocols hosts would 
have to speak multiple routing protocols.  Getting it right, robustly, 
across all platforms, just seems extremely unlikely.

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.

Yours,
Joel

--
to unsubscribe send a message to [email-masked] 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

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 18 Apr 2008 22:04:38 +0200

Joel,

> to want to keep hosts out of the routing game.

...

> 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

---

From: [email-masked]
Date: Fri, 18 Apr 2008 18:09:30 EDT

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  
[email-masked]:

Joel,

...

We have proposed in  

Olivier