RE: shim - transport/network communication

[<john.loughney@nokia.com>]

Brian and Joe,

> > In that case we are saying the same thing -- dictating what "best" means 
> > (or, from another point of view, considering that there is only one 
> > "best" way) is a Bad Idea.
> > 
> 
> That's why, in the architecture of shim6, IMHO we should clearly
> separate the process of choosing the next address pair to use
> from the process of actually starting to use those addresses. The
> first part (choosing) I would regard as a pluggable component where
> implementers will no doubt learn with experience, and probably need
> not even be standardized.

I definately agree that this is orthogonal to the shim6 work. You could
imagine "best" being the most stable or reliable; highest capacity; lowest
cost; lowest latency, etc.  I think Thierry brought up the issue of letting
the user choose this, and in a wireless case (WLAN vs GPRS) this makes sense.

NSIS is building upon RSVP for path-related information; PCE & IPFix are working
on somewhat related issues with regards to finding out path information.  Some
smart folks might want to pair shim6 with some of the above for getting information
about the possible network paths that the address pair combinations traverse.
Coupling that with a policy, then, for selecting the addresses, probably would
give Fred what he wants.  

Building this into the protocol is not a good idea, in my opinion, but leaving
it for implementors / future work sounds good.  This topic also revolves
around failure detection - how do we detect when there has been a path
failure and what constitutes a path failure is open for some interpretation.

I think the address-pair (or path) selection policy will be very different in many 
deployment scenarios, so again I think that this shouldn't be part of what shim6 
solves, but allowing shim6 to be one piece of the solution is a good idea.
Now we just have to progress on shim6.

John