RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]

[<Jonne.Soininen@nokia.com>]

Hi everybody,

(taking the chair hat off)

> 
> Do you mean:
> 
> [Juha W.]
> > Furthermore, I personally don't believe that configured tunnels make
> > a feasible solution for this specific problem (even though they
> > provide a good solution for some other scenarios). You must remember
> > the high number of UEs and dynamic addressing. And any extra
> > configuration effort isn't nice for the users. If you make the extra
> > configurations using SMS (like configuring APN settings for
> > different applications), that means one SMS more. The point is:  
> > IPv6 should be as easy as possible.
> 
> There are some assumptions in this paragraph and few 
> technical facts.  
> This needs more elaboration.
> 
> E.g.:
>  - why exactly would there have to be more than 1 SMS?  The 
> address is 
> just 32 bits, 4 characters (out of 160 or so :-).  Could be easily 
> compressed in one message.
> 
>  - why exactly should there be any extra config for the user?  It 
> could be completely transparent to them.

Pekka really, this will not work. This is not what people want and this is not what people do. The user wants to use the service and not to spend her/his time configuring the mobile. There are quite some things that have to be configured already and the last thing the user wants is to configure the IPv6 tunnel every time the PDP Context is set up. 
This is not going to happen!

> 
> >  > Would a modification be required?  I'm not so sure of 
> that.  There
> >  > must be some mechanisms to retrieve this information, either 
> >  > e.g. SNMP
> >  > query or access to a database, or something.  That 
> should be pretty 
> >  > much all you need.
> > 
> > That makes certain assumptions about implementations.
> > Seriously, it is not feasible. Also I can't understand why you think
> > digging info from a database is simpler than just using ISATAP.
> > Anyway, enough emails on this subject for me since we're not getting
> > anywhere.
> 
> I'd like to hear more of these assumptions.

The configuration overhead is too much - period. 

> 
> That avoids getting the other features of ISATAP we don't need here, 
> and provide a simpler architecture.
> 
> I do not believe this possibility has been analyzed well enough to
> understand it's possibilities (or potential flaws).

I think this thread and all the other threads seem to point to the fact that we have to start dicussing solutions instead of scenarios. We know the scenario now - we may need tunneling. If we could now wrap up ISATAP in that way that it fulfills the requiremets given by the scenarios/analysis. Right?

Cheers,

Jonne.

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 
>