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

From: <[email-masked]>
Date: Tue, 7 Oct 2003 09:44:28 +0200

> > > > > > > According to my current understanding, the above does not
> > > > > > > require big investments and in many cases software 
> > > upgrades are
> > > > > > > sufficient.
> > > > > > 
> > > > > > It's not about investments. It's about touching the running
> > > > > > system.
> > > > > > People do not trust IPv6 at the moment. Tunneling is a 
> > > way to show
> > > > > > them what could be done in a very inexpensive and easy way.
> > > > > 
> > > > > Would it be easier to convince the ops folks that IPv6 is 
> > > > > non-intrusive if you _added_ (not upgraded_) one IPv6-capable 
> > > > > GGSN, (and other components
> > > > > as needed), which would not serve regular IPv4 users?
> > > > 
> > > > Yes, easier but still not as easy as tunneling since there is 
> > > > other
> > > > equipment to touch (as written by in an earlier email):
> > > > - SGSN support for IPv6 signalling
> > > > - HLR support for IPv6
> > > 
> > > Right.. but could these be served in some other node as well?
> > > (I don't 
> > > know the 3GPP arch in enough detail..)
> > 
> > Also if you serve it in some other node, you have to implement the 
> > functionality. There is less to implement if you do tunneling (very 
> > little signalling).
> 
> You'll have to implement _something_ anyway, because the 
> tunnels have to be terminated.  The termination need not be 
> done at a 3GPP equipment though..

Of course, we have to implement something. But the IPv6 implementation
will be totally non-intrusive. Therefore, the 3GPP equipment does not
have to be "touched".

> 
> I guess what you are saying that you don't want to implement 
> any 3GPP IPv6 functinality before the business case, but 
> would be OK to implement generic IPv6 features which wouldn't 
> clash with current v4 3GPP operations?

Yes.

> 
> > > > > Partially parallel infrastructure ("dedicated low-end IPv6 
> > > > > router running tunnels") is how many have done it during the
> > > first phases
> > > > > in ISP space.  Would this be a possibility for 3GPP as well?
> > > > 
> > > > I'd prefer to do tunneling instead of a parallel infrastructure.
> > > > Parallel infrastructures cost money to run them - tunneling 
> > > > infrastructure is probably cheaper.
> > > 
> > > The problem here is that this doesn't seem to do anything to
> > > convince the ops folks that they should be enabling the v6 
> > > support in the main network
> > > -- which is the goal here.  They wouldn't get any experience 
> > > with native v6 or other nice new features this way.
> > > 
> > > So, it seems if we do something like this, it will stay
> > > around for a long time, and we won't get to the goal, the 
> > > real IPv6 service, any time soon.
> > > 
> > > So, tunneling might be counter-productive here.
> > > 
> > > (Note that the situation is slightly different when your home
> > > networks support v6, but the network you roam to, doesn't.)
> > 
> > Maybe. But if the hurdle to go native is too high then we 
> have no IPv6 
> > at all. And that's even worse!
> > 
> > Native IPv6 will come once IPv6 usage takes up and apps are around 
> > that use IPv6. But to initiate the app development it is crucial to 
> > have a network out that supports IPv6. This network has to be built 
> > without business case. Therefore, tunneling is the only way 
> to do this 
> > IMHO.
> > 
> > I don't think that this is counter-productive here.
> 
> I'm not saying the networks have to be native through-out.  
> Tunneling can very well be applied in many places if folks 
> feel like it.  However, recommending tunneling at the 3GPP 
> network <-> UE interface would have a significant impact on 
> how 3GPP networks would get deployed & implemented.  
> The changes at this interface would not be transparent.

True. But I still think that recommending a tunneling approach to the UE
would help a lot to convince operators making the first steps to the
IPv6 introduction. Remember, that this is just a first step. And, the
native solution would follow within 1-2 years (which would again bring
transparency back).

> 
> > > > I still think that having tunneling mechanisms in the v6ops
> > > standards
> > > > is a good thing and would convince more service providers to do 
> > > > the
> > > > first steps of the IPv6 introduction. And this is needed to 
> > > spread out
> > > > IPv6 to the users and service developers to facilitate the
> > > development
> > > > of services using IPv6 which will finally lead to the full
> > > success of
> > > > IPv6.
> > > 
> > > There is a doubt that such mechanisms are counter-productive
> > > for IPv6 deployment (see above for example), and whether such 
> > > mechanisms could be done reliably/easily/robustly/etc. enough 
> > > without infl uencing too much on what must be done at the UE 
> > > side (I'd prefer to keep that minimal).
> > 
> > I don't care too much about reliability/robustness/etc of the first 
> > IPv6 introduction step.
> 
> Oh, you should care! :-)  It has been a reason why IPv6 
> deployment hasn't 
> kicked off yet.  A reason why vendors aren't putting on v6 by 
> default, 
> etc.  Everything is about reliability and robustness.  If 
> folks try IPv6, 
> and it doesn't work, they're not likely to try again any time soon!

Well, from our experience (running an ISATAP solution almost half a year
operationally in our fixed network) we have seen that tunneling
mechanisms like ISATAP are robust enough if not as robust as native
solutions. The main difference is performance. And performance is anyway
bad in today's 2.5/3G networks and applications using these networks are
used to bad performance. Therefore, it is not that a big issue.

> 
> For a couple of perspectives, have a look at: 
> http://www.netcore.fi/pekkas/ietf/draft->
savola-v6ops-6bone-mess-01.txt
> http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefa
ult-01.txt

> By the way, often 3G UE will be used as modem for
> PCs. And, on the PC side tunneling mechanisms are already implemented 
> and very easy to use (at least in the case of Windows XP with ISATAP).

This has nothing to do with 3GPP (except that it's done on top of v4
3GPP network), right?  The UE doesn't know anything of v6, and the 3GPP
network doesn't know anything of v6.  The 3GPP operator is just acting
as an IPv4 ISP, offering tunneled v6 service for folks using its private
v4 addresses?

=> yes. But the operator has to place the tunnel server in its Gi
backbone because he is generally using private IPv4 address space and
the user cannot use a tunnel server in the Internet therefore.
Furthermore, the UE will probably soon also implement tunneling
mechanism (we are asking SonyEricsson and Nokia to implement ISATAP in
their handsets).

> I see tunneling as a quite easy and cheap mechanism to bring IPv6 to 
> the users. As in the IPv4-Internet, applications will just appear. And

> once they appear for IPv6, native IPv6 will be needed (robustness, 
> etc) but the business case will be there to do this!

I fear the robustness etc. which you shrug away are preconditions for
more 
generic deployment and application development.

=> as stated above, tunneling is quite robust. Just performance is a
problem. But application development is exactly the reason why I am in
favor of a quick (and dirty) IPv6 introduction in the networks. You
know, it's a quicken-egg problem. We have to see that we "lay the egg"
as soon as possible to let application developers start implementing
applications using IPv6. And tunneling is for me one very viable way to
do the first step (of course it is still somehow "quick and dirty").
Remember, that sometimes it is better to go for a 80/20 solution than to
wait for the 100% solution...

Regards
Andreas

-- 
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: Havard Eidnes <[email-masked]>
Date: Tue, 07 Oct 2003 10:54:58 +0200 (CEST)

Hi, guys,

please allow myself to supply a remark on the style of the text in
this e-mail discussion: it really would make it so much easier for
those of us trying to follow the discussion from the sidelines if a
few simple and commonly accepted rules were adhered to with regard
to quoting of material:

1) please cut down on the included comments to narrow down to just
   what you are commenting on.  Adding 5 lines of your own text to 100
   lines of (recursively) included comments makes it unneccessarily
   hard to find the 5 new lines, especially in combination with
   violations of rule number 2 below.

2) it would make it much easier to follow the discussion if the
   commonly accepted quoting practice of "indent each line with '> '"
   was adhered to.  The alternative makes it Really Difficult to see
   who said what, as in

> mechanism (we are asking SonyEricsson and Nokia to implement ISATAP in

   Inserting an inconspicious "=>" at the front of a possibly
   multi-paragraph reply (just a single paragraph here, I'll
   concede) doesn't quite provide the same visual cues that the
   "indent every included line with '> '" does.

> Andreas

Now, who wrote this?!? ;-)

I now return you to the discussion at hand.

Regards,

- Håvard

---

From: Pekka Savola <[email-masked]>
Date: Fri, 10 Oct 2003 10:44:59 +0300 (EEST)

Hi,

Clipping the text quite a bit and tailing it down..

On Tue, 7 Oct 2003 [email-masked] wrote:
> > [me:]

I'm not sure how much that would help.

There seem to be two cases, one with two subcases here:

 1) UE is used as a "modem" for a laptop (seems common in current GPRS 
networks)
   o UE doesn't have to know about IPv6 at all
   o UE implements only IPv4 stack, and not even much of that
   o The laptop performs the tunneling and has IPv6
  ==> this is not really (IMHO) a 3GPP scenario, but could perhaps be 
considered here as the "zeroeth step".  The solutions are probably pretty 
much the same as with Unmanaged/ISP scenarios behind NAT.  One could 
employ some tunneling mechanism at the laptop.

 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
    ==> in all other cases than this, the user pays (money, performance) 
        for the IPv6 tunneling overhead.

  b) UE uses a form of tunneling for its IPv6 connectivity
    ==> putting complexity to the UE
    ==> which are the cases where 1) above is not applicable?
    ==> could configured tunneling be made to work?

My initial take on this is that 1) would probably be pretty useful in the 
short term, but doesn't really require much at all.  2.b) seems like a 
case which is not so short-term solution, maybe needed if the UE 
implements and wants to use IPv6 services itself -- but aren't we then 
already quite far in the transition process, and IPv6 PDP context should 
be used instead.

(Are there other cases, like the laptop initiating a PDP context of its 
own or something.. I'm not sure..)

> wait for the 100% solution...

I agree that some simple forms of tunneling, at least (configured tunnels,
what more do you need? :-) can be rather robust.  The more complexity you add, the more
fragile it gets.

But I'm not sure whether the tunnels (especially the more complex forms
of) are best applicable in 3GPP networks; the tunneling is absolutely a
major way in some other cases, like unmanaged networks. The 3GPP scenarios
are supposed to be somewhat special.