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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 3 Oct 2003 Andreas.Schmid1@swisscom.com wrote:
> > On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote:
> > [...]
> > > > 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..)

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

> > > > Furthermore, introducing (some) IPv6 support in the network
> > > > does not cause problems with the current IPv4 network, i.e. 
> > > > IPv6 can be run simultaneously without disrupting IPv4 
> > > > traffic! This is not a 3GPP-specific thing; this is one of 
> > > > the good sides of the dual stack deployment. There is no need 
> > > > to immediately move from native IPv4 to native IPv6 support 
> > > > in the cellular networks.
> > > 
> > > Of course, still you have to touch the running system. Operating 
> > > people don't like that.
> > > 
> > > One of the hidden problem might be that IPv6 testing had been done 
> > > mainly in the R&D site. These guys know what it is all 
> > about and have 
> > > enough trust to implement it. The operations guys have to 
> > go through 
> > > this step first.
> > 
> > Right... this is not an uncommon problem, and comes up in 
> > every space, not just 3GPP.  
> > 
> > The problem seems to be (speaking wearing both R&D and ops 
> > hats) that R&D polishes the technology too long in it's own 
> > circles, and doesn't involve ops folks early enough.  The ops 
> > guys need to get involved with the stuff 1-2 years (at least) 
> > before you start talking about putting it in the backbone...
> >
> 
> We are trying to involve them since about 1-2 years. But they have
> enough other things to do that directly have an impact on the revenue.
> So it's not that easy.

Yep.. which is when you have to start talking to their superiors, i.e. use
the administrative methods.  Any other means is going to fail (and if the
admin methods fail also, I don't see how enabling tunneling is going to
help either)..
 
> I guess it's a problem in the design of the innovation process. But we
> are probably not the only operator with such problems.

Right..
 
> 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 influencing too much on
what must be done at the UE side (I'd prefer to keep that minimal).

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