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

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 25 Nov 2003 Jonne.Soininen@nokia.com wrote:
> > 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!

Again, you assume that the user actually has to configure anything at 
all.  That doesn't need to be the case, I think.  (At least, I haven't 
heard technical arguments why it couldn't be.)

Who said that the user has to configure anything itself?  The user
receives a magical SMS message from his operator, the tunnel gets
automatically activated, and we're done?

Or does the user manually configure the APN as well, based on the SMS 
messages it sends/receives?

> > > 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. 

Sounds like a circular argument without justification.

> > 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?

We know that there is a scenario where tunneling is desirable in
certain cases, yes.  However, I'm not sure if we know the requirements
of the scenario, or the scenario itself, well enough yet (see the
points above why exactly configuring is bad, what exactly would need
to be configured, etc.).

Of course, talking about solutions might be OK as well, but only if 
one keeps the scenario in mind.

I don't know what you mean by the ISATAP reference.  Clearly, we could
take it, and apply it in this specific scenario, and I think it would
work, at least to some definition of "work".  That doesn't mean it's
the right thing to do, of course. Is it the *right* tool for the job?  

For example, a proof of concept procedure was introduced in
draft-savola-v6ops-conftun-setup-01.txt; it would probably solve the
problem in a much simpler and easier way; it's basically just
expanding the couple of bullet points above about configured tunneling
set-up methods.  In the case of 3GPP, only proto-41 would be necessary
-- basically just configured tunneling at the UE, and some tricks at
the 3GPP operator side, depending on the mode in which it wishes to
operate.

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