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

[<Jonne.Soininen@nokia.com>]

Pekka,

> -----Original Message-----
> From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: 25 November, 2003 16:52
> 
> 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?

Look, the IP address is dynamic and usually every PDP context activation means a new IP address. Then there would have to be a mechanism for the network to guess that the user would like to use IPv6 on this particular PDP Context and send an SMS to configure the tunnel. The configuration would have to be accepted by the user, and so on.
This would not work. 

 
> Sounds like a circular argument without justification.

I think the justification is above.

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

Configuration would not work. I think this has been explained above and in other mails sent on this list. Trust me on this - configuring the tunnels can be at the most a very marginal case.

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

Yes, now we do have already two different scenarios/analysis pairs that call for some kind of solution. I think we should concentrate to see what the solution would be.

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

It is at least one possible tools for this job. Do you have others candidates (except for configured tunnels)?

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

Sorry, I read the document really, really quickly. It is an interesting document and we should discuss the different solutions if we decide to go to the solutions space (not wearing chair hat-I think it would be time). Of course, we have to consider all solutions. 

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