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

From: <[email-masked]>
Date: Tue, 25 Nov 2003 15:51:44 +0200

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Nov 2003 16:52:23 +0200 (EET)

On Tue, 25 Nov 2003 [email-masked] wrote:
> 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?

> The configuration overhead is too much - period. 

Sounds like a circular argument without justification.

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

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 25 Nov 2003 14:03:11 -0800

>the right thing to do, of course. Is it the *right* tool for the job? 

Perhaps what might help would be an applicability statement such as the one
I have just submitted to the I-D repository and have available for immediate
perusal at:

  http://www.geocities.com/osprey67/isnoid-00.txt

The document title and abstract appear below:

Fred
[email-masked]

>
> Network Working Group                                         F. Templin
> Internet-Draft                                                     Nokia
> Expires: May 25, 2004                                  November 25, 2003
>
>
>                     Applicability of ISATAP for NOID
>                     draft-ietf-templin-isnoid-00.txt
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on May 25, 2004.
>
> Copyright Notice
>
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
>
> Abstract
>
>    This document describes the operation of the NOID multihoming
>    proposal on nodes with ISATAP interfaces. It uses the global DNS as
>    an extension of the ISATAP Potential Router List (PRL) and ISATAP
>    link-local addresses as next-hop addresses for IPv6 routes.