RE: shim - transport/network communication

["Bound, Jim" <jim.bound@hp.com>]

John, is correct in my view.  I think we make sure we do not break
mobility per charter statements Jaro sent out and when we are done we
can see if there is benefit to mobility.

/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of john.loughney@nokia.com
> Sent: Tuesday, March 22, 2005 7:56 AM
> To: brc@zurich.ibm.com; jabley@isc.org; shim6@psg.com
> Subject: RE: shim - transport/network communication
> 
> 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
> 
>