RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues]

[<Andreas.Schmid1@swisscom.com>]

> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Montag, 13. Oktober 2003 08:36
> On Fri, 10 Oct 2003 Andreas.Schmid1@swisscom.com wrote:

<...snip...>

>  
> > We are looking at what is available in commercial products 
> today. Most 
> > of our customers are using Windows (even if we don't like 
> it - it's a 
> > fact). And there, you have Teredo, ISATAP and 6to4 as automatic 
> > tunneling mechanisms (I don't count on configured tunnels since the 
> > user should not have to configure anything for IPv6).
> 
> Configured tunneling methods don't need to be manually 
> configured, unless 
> you want them to be (see more below).
> 
> > Teredo is not really stable and very complex. 6to4 is just 
> applicable 
> > if you have a public address (and this is not the case for 
> most if not 
> > all 3GPP networks of today).
> 
> Right..
> 
> > So ISATAP seems to be the solution of choice?!?
> > Of course, you could argue that you could convince Microsoft to 
> > implement something else. But this could be difficult....
> 
> I suppose one can run your own applications on top of a 
> Microsoft operating system.  For example, a very simple GUI 
> application which 
> transparently configures/unconfigures configured tunnels.  
> Shouldn't be 
> too difficult.

Yes, that's not too difficult. But it is much better if the users can
just use the new services without having to configure something.

If the user has to configure, you either distribute the tunnel-enabling
app with the new service app or let the user be aware of IPv6. The
second solution is bad because users should not be aware of IPv6 (but
just use it). The first solution would be possible but is still not
good. Operators want to offer new services without the user having to
install something. The OS (and the network) should take care of that.

> 
> The point is, the current basic transition mechanism 
> framework gives a lot of tools, if one is just willing to 
> take them and use them.

Yes, right - many tools there - _too many_ for the average operator. The
operators are lost! I guess that's one of the reasons why the v6ops WG
has been established; to break down the number of tools and make
proposals on what to use where.

> 
> > >  2) UE is used standalone or as IPv6 router for a laptop
> > >    o UE implements IPv6
> > >    o Native IPv6 packets flow between the UE and the laptop
> > > (if plugged in)
> > >    o UE acts as an IPv6 router/bridge for the laptop
> > >    o compared to the above, useful mostly if you want IPv6 
> > > connectivity at 
> > >      the UE as well as the laptop
> > > 
> > >   a) UE uses an IPv6 PDP context for its IPv6 connectivity
> > >     ==> pretty straightforward, and long term good approach
> > 
> > Right. But still, the operations department don't want this 
> today (I 
> > am repeating this again. But you can believe me this!)
> 
> Some operators probably see this as more desirable than others.

Yes, maybe...

> 
> [...]
> > >   b) UE uses a form of tunneling for its IPv6 connectivity
> > >     ==> putting complexity to the UE
> > 
> > Yes, I know this is probably only useful for smartphones...
> >
> > >     ==> which are the cases where 1) above is not applicable?
> > 
> > Where you want to use an application on the handset that is only 
> > running on IPv6.
> 
> Right.  The question is, is this scenario near-term enough?  
> Couldn't we 
> be able to proceed with just "laptop tunneling" and 
> recommending using 
> IPv6 PDP context when the phones leveraging IPv6 emerge?

Ok, we could do that. But even if we recommend IPv6 PDP context for the
phones we should add a side note that automatic tunneling as done in the
"laptop tunneling" case would also be possible if the phones support
that.

We (Swisscom) are currently asking the handset vendors (Nokia,
SonyEricsson, etc) to implement ISATAP in their phones. I know that
SonyEricsson has ISATAP in a pre-commercial phone implemented. 

> 
> > >     ==> could configured tunneling be made to work?
> > 
> > No, we need automatic tunnels. Configuring the handsets is 
> already too 
> > complex for our customers! We need something plug&play...
> 
> Note that "configured tunneling" refers to _somehow_ configuring the 
> tunnel endpoints.  The configuration itself need not be done 
> manually by 
> the user.  At the face value, this may not be obvious..
> 
> For example, one might be able to use a number of different 
> Over the Air 
> techniques for configuring the tunnel -- see the section in 
> the analysis 
> document?  (I haven't discussed whether this is possible with 3GPP 
> experts, but I don't see any reason why not..)
>  

If it's possible to automate configured tunneling (the automation
mechanism has to be built in the OS!) then this is fine for us. Because
what we need is the automated nature of IPv6 from a user point of view
(how this user experience is achieved is not that important for us).

> [...]
> > Remember that IPv6 is an enabler. The services will not be 
> developed 
> > if the network is not there. If we put the network there (cheap but 
> > still
> > automatic) the services will appear. But if we wait for the 
> services to
> > implement IPv6 to the handsets this will never happen....
> 
> Some others would probably count adding a few new 3GPP IPv6 
> features (as a 
> start-up phase installation, until the services are there) as an 
> acceptably cheap and automatic mechanism -- one which could 
> be expanded 
> easily when needed.
> 
> But I agree with you that the startup phase must be rather 
> cheap and relatively automatic.  Simplicity, reliability and 
> security also come to the mind.  I guess the argument is only 
> about how much of these is enough or too much..

Yes, exactly right!

> 
> [... snip to the end, except ...]
> 
> > This is a long discussion we have. I am not that used to 
> IETF mailing 
> > lists. But I am happy to send you my comments off the list if you 
> > like. Just respond me off the list if you think this is better.
> 
> I'm seeing at least some convergence here, and clarifications on what 
> "configured tunneling" means.  Therefore, it seemed useful to 
> continue on 
> list at least for now.  If you are more confortable with an off-list 
> discussion, that's fine too.

No problem from me with on-list discussion. I just don't want to fill
people's email inbox with something that is not useful for them.

Regards
Andreas