RE: Next question...

["Tony Hain" <alh-ietf@tndh.net>]

Tony Li wrote:
> Tony,
> 
> |   Removing per-host from the solution set ... 
> |   blinds the host
> |   & applications from the alternatives.
> 
> 
> Well, if the host is not blind to the routing subsystem then you
> end up with a tight binding between the subsystems in the
> architecture.  Not to mention the fact that the host has to 
> maintain or refer to a great deal of state.

There is a difference between the host being aware of the routing
subsystem, and being aware of alternative locators. Yes the host has to
maintain state, but not much more than it would anyway, and the overall
system scales much better if state maintenance is at the edge rather
than somewhere in the middle.

> 
> 
> |   From the app point of view, a network 
> |   that does not
> |   react appropriately is useless for anything more than a 
> bit-pipe and
> |   will be routed around or tunneled over (re: POTS, ATM, 
> |   ...). 
> 
> 
> Have a network that reacts then implies that you have no 
> visibility in the
> host and then have pushed the issues into the network.  Am I 
> not following
> you?

I didn't do a very good job of clearly making the point... ;) 
In the cases where the multi-homing approach is to mask alternatives
from the host, if the network has locked on a path that is unacceptable
to the application, there is no way to fix it. In the case where the
host is aware of alternative locators, it has the option to walk the
list until it finds an acceptable set. It doesn't need to know the
details of the path and be tightly interlocked with routing, but it does
need an option to signal the routing system to make a different choice.
The only current mechanism the host has to signal the routing system is
choice of locators.

> 
> 
> |   Managing
> |   fine-grained TE aspects of uncoordinated traffic sources 
> with an IGP
> |   sounds like a nice research topic.
> 
> 
> I think that you can safely assume that I, of all people, would not 
> recommend that.

I was not suggesting you would, so much as reacting to other comments in
the thread where TE appeared to be a goal. The theme seemed to be that
we have to do TE in the local network, but we refuse to let the hosts
play any part because they are not managed by the network gods. It is a
fine thing that the goal of TE is to manage resources, but it is often
the case that people forget that the role of the network is to deliver
the expected service to an application. If the applications are
effectively uncoordinated traffic sources, it is challenging to figure
out a way to deliver the expected service to every app. 

Tony


> 
> Tony
>