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

[Pekka Savola <pekkas@netcore.fi>]

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

Ok, see the other thread with Brian C.

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

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

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

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