Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd)

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jul 2003 15:12:58 +0300 (EEST)

Karim's original message was off-list, so this was my response.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: Thu, 24 Jul 2003 15:03:57 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Karim El-Malki (HF/EAB)" <[email-masked]>
Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep
    loyment

On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote:
>  >  2) The use of ISATAP is misguided in this space: it's only 
>  > useful if the
>  > 3GPP operator supports IPv6 (i.e. provides the ISATAP 
>  > routers and other
>  > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc.  This
>  > seems in direct conflict with 3GPP goals.
> 
> It is not in conflict with any 3GPP goals. Note that the 3GPP operator
> requires IPv6 for SIP-based IMS but this doc also covers generic access
> (which is where we talk about tunnelling). On the contrary it helps
> operators to start rolling out IPv6 without having to upgrade everything
> all at once. This is an important issue which we have addressed. Also,
> when a user roams to a network that does not support IPv6, 

I take it that by the latter you mean a network under that same 3GPP
operator which does not support IPv6?

>  >  3) we should be able to assume that unless the 3GPP 
>  > operator where the 
>  > user buys his service doesn't support IPv6, the user cannot 
>  > use IPv6 on 
>  > his gadget.  On the other hand, if the particular GGSN the user is 
>  > connected using IPv4 supports only IPv4, there is nothing 
>  > stopping the 
>  > user from using some other GGSN for IPv6 support.
> 
> That can't be done. The user doesn't choose GGSNs.
> 
>  >   That is, 
>  > as long as the 
>  > 3GPP operator has basically one IPv6-aware GGSN, SGSN and 
>  > HLR, IPv6 users 
>  > are happy.
> 
> That is not correct. If you happen to go to the wrong SGSN/GGSN
> you just don't get IPv6 service, independently from the fact
> that there may be another SGSN/GGSN somewhere else in the
> network supporting IPv6.

On these two issues, I keep getting mixed signals from different people 
involved with 3GPP work.  Some say it can be done, some say it can't.

I think a separate and very clear analysis with refs should be done on 
that subject.

> You have left out the issue that when we're introducing a new
> technology nowadays we don't do it all at once but gradually.

Dubious 3GPP specs (see above) are a real hindrance to deployment, it 
seems..

> That means we will have to deal with IPv6 capable mobiles
> trying to use IPv6 app.s even in areas where IPv6 native
> connectivity is not possible. If we don't consider this case
> then we won't be providing a full set of answers to 3GPP.

Or 3GPP is making expectations it shouldn't.  It may just be that we could 
say, "if you want to use IPv6, require IPv6".

-- 
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: Thu, 24 Jul 2003 16:41:09 +0300 (EEST)

On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote:
> Both a separate operator and a portion of the network (e.g. SGSN).

Ok, see the other thread with Brian C.

> I can't remember seeing emails on this list saying the opposite,
> but if anyone has corrections to make please feel free. 

I've talked with a few people in Nokia and they seem to have said so.  Of
course, I know close to nothing of 3GPP, so they might have misunderstood
my questions or I might have misunderstood their answers.

> I'd say "interpretations" are a hindrance as with all non-IETF specs
> which get discussed in IETF. 

I agree.

And where do those interpretations stem from?  Lack the IETF understanding
non-IETF specs and the lack of non-IETF people understanding IETF specs.  
Let's look at the former.

I don't know whether it is the responsibility of the IETF reader to
educate himself with non-IETF specs, or the responsibility of the people
discussing non-IETF specs in the IETF context to educate IETF folks.  

There are probably different opinions on this, but as 3GPP comes to the
IETF, my personal feeling is that it is the latter. (I.e. to provide
enough context of 3GPP so that IETF folks can make reasonable decisions.)

> I think the design team has the right competence to address these issues
> and we didn't have major disagreement.

You misunderstand the role of the design team.  The design team is to 
address issues, yes, but all its decisions are brought to the working 
group, and the most importantly, all those decisions must be justified -- 
and the working group has to feel good with them.  There may be good 
reasons for decisions made in the process, but at least all of them do not 
appear to be apparent.

Design team is a brain-storming activity to cook up proposals for the WG.  
WG then decides what to do with those proposals based on how it feels 
about them.

From RFC2418:

6.5. Design teams

   It is often useful, and perhaps inevitable, for a sub-group of a
   working group to develop a proposal to solve a particular problem.
   Such a sub-group is called a design team.  In order for a design team
   to remain small and agile, it is acceptable to have closed membership
   and private meetings.  Design teams may range from an informal chat
   between people in a hallway to a formal set of expert volunteers that
   the WG chair or AD appoints to attack a controversial problem.  The
   output of a design team is always subject to approval, rejection or
   modification by the WG as a whole.

> We could apply the same reasoning to fixed ISPs but I'm not sure
> this method (overnight upgrade of full live network) works for
> everyone.

There is a reason why we have "3GPP scenarios", "ISP scenarios" and
"Unmanaged scenarios" are separate (I'm assuming here that 3GPP doesn't
overlap with Enterprise :-): it is assumed that 3GPP is *different* in
some respect, and has some unique characteristics.

Of course, different people's assumptions on _what_ those unique
characteristics are may be different (which may be causing
misunderstandings).

My assumptions include for example:
 - large number of UE's (at least after the kickoff)
 - very plain & simple UE's (IPv6 implementation-wise)
 - strong network support for IPv6 ("IMS is exclusively IPv6" etc.)
 - others

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 24 Jul 2003 17:38:19 +0200

More comments below.

 > Let's look at the former.

Interpretations can stem from misunderstanding of the questions
or answers as you wrote above. That's often the case since that is
an important means by which knowledge is shared.

 > enough context of 3GPP so that IETF folks can make 

I agree and that's been an important part of RFC 3314 and the
scenarios draft. I think they do a good job.

 > WG then decides what to do with those proposals based on how 

You're jumping to conclusions here. I never said that design teams
are above the WG. The point is that you are the person raising
these objections and I was trying to find out what they are based on.
If the WG thinks that RFC 3314, analysis and scenario drafts don't provide
enough background info to support the need for tunnelling we can put in
something to explain it better. However what you were saying previously was
that you talked to some people who told you the opposite of what is written
in the draft. So it looks like the meaning and recommendation is your issue
rather than the clarity. If people disagree with what I have written on
3gpp in these emails or what is in the draft then they should bring it up
now so it can be addressed. Otherwise we can just work on the clarity
and move on.

/Karim