RE: shim - transport/app communication

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

Erik, thanks.  If we are to do this really I agree with your mail below
technically.  The key is that the ULID is dereferenced to an address
whereever possible in the nodes stack and always on the wire and if ULID
must be passed over the wire it must be in some encaped dst option is
one suggestion.  Also how do I trust it on the wire?

/jim 

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com] 
> Sent: Wednesday, March 16, 2005 9:47 PM
> To: Kurtis Lindqvist
> Cc: Bound, Jim; Pasi Sarolahti; ext Iljitsch van Beijnum; 
> Leif Johansson; shim6@psg.com
> Subject: Re: shim - transport/app communication
> 
> Kurtis Lindqvist wrote:
> > 
> > On Tue, 15 Mar 2005, Bound, Jim wrote:
> > 
> >>>So I'm afraid that applications that want to take advantage of shim
> >>>might need to use a different address family, at least.
> >>
> >>That is a non starter and will never be supported.  Might 
> as well move
> >>them to SCTP.
> > 
> > 
> > I have a vague memory that this was brought up after Erik's 
> presentation
> > to the apps area open meeting in D.C and I from what I 
> remember Erik was
> > stressing that this was one of fundamentals that could not 
> be changed. But
> > I hope that Erik can refresh my memory.
> 
> My take is that the shim6 approach provides working referral for 
> existing applications, as long as the locator that was picked 
> as a ULID 
> is still reachable. Thus you want to update the applications and 
> application protocols to do one of
>   - use a FQDN for referrals (since the DNS lookup will 
> return multiple 
> addresses to try)
>   - pass a list of addresses in referrals (so that the peer has a 
> fallback when the first one doesn't work)
> 
> But it is perfectly safe to use the shim for all applications. If an 
> application doesn't use the shim things will fail when the selected 
> address pair fails (even without any referrals), so the shim makes 
> things strictly better.
> 
> Of course, there might be performance reasons to not rely on 
> the shim. 
> For instance a DNS query, with multiple NS records to try, 
> might as well 
> bypass the shim since it has a higher level failover which doesn't 
> require creating state in the shim.
> 
> > In general the shim6 would have to be as transparent to the 
> application
> > (API) as possible.
> 
> yep.
> 
>     Erik
>