Re: addition of TLV to locator ID or locator ID set

[Erik Nordmark <erik.nordmark@sun.com>]

Jason Schiller (schiller@uu.net) wrote:

> However, if one of the links to destination B is getting over loaded, then
> destination B will want to migrate some traffic away from what most people
> are seeing as the lowest latency link.  

But this could be done by B adjusting some preference (e.g. a weight) 
instead of trying to pad something like a latency. For instance, if it 
turns out that the applications care more about throughput than latency, 
then inflating the latency number might not have the desired effect.

Of course, for host B to be able to send anything, it needs to somehow 
discover that the border routers sees overload on one link but not the 
other; I think this is another desirable feature of a signaling 
mechanism from the border routers (we talked earlier on the mailing list 
about the border routers being able to influence the source address 
selection). I view these as potentially useful optimizations; I'm not 
sure we should have shim6 depend on the existence of some such new 
communication mechanism from the border routers to the hosts.


> I'm not married to the concept of using a TLV if there is a better
> approach that is equally flexible.  I proposed TLV as it seems very
> flexible, can be used to carry multiple sets of values that can allows for
> a complex nested sorting, and doesn't seem like a re-invention of the
> wheel.  

Multiple sets of values assume something about how the peer will 
interpret the values. If what A cares about is to tell B to prefer some 
other locators when sending to A, I think we can handle that by just 
allowing A to send updated preferences for its locators to B.
Once we agree on such a capability, then we can discuss what the actions 
should be on B's side (immediately switch vs. something else).


> The question here is what are the solution spaces for path failure
> detection, and do any of them fit nicely with trying to determin some sort
> of forwarding plane measured "best" path.  

Presumably a notion of "best" path is dynamic. If it can't be detected 
dynamically by A or B, then we have another case where the border 
routers need to tell the hosts in their site. But it isn't clear to me 
how a signal about the paths can avoid having to effectively tell all 
the hosts about all the paths. I think the hosts should only need 
information about the destinations/paths they are using, which seems a 
bit challenging in this context.

   Erik