RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node

[Soliman Hesham <H.Soliman@flarion.com>]

Pekka, 
 
 > > => There is also the time it takes to setup a PDP
 > > context, which is significant.
 > 
 > These need to be spelled out properly so we can make 
 > reasonable decisions.
 > 
 > >  > Lots of things require state in the network, including 
 > any kind of 
 > >  > protocol translator.  Protocol translators mitigate the need 
 > >  > for radio 
 > >  > channels, 
 > > 
 > > => This is not related to radio channels, it's related
 > > to the time and the resources consumed in the network.
 > 
 > This is very much related.  If you, using e.g. IPv6 proxies, 
 > make it so
 > that you basically never need IPv4, the time and resources 
 > consumed for
 > IPv4 in the network is much smaller.

=> But what's the relevance of this to radio channels? 
There is one physical network that supports an aggregate
(X) amount of traffic, whether it's v4 or v6. 

My comment was related to the time it takes to setup the context 
and the resources consumed in the SGSN and GGSN. 

 > > => I don't understand the above statement. There is no
 > > relationship between the resources/time consumed to setup
 > > a context and the number of customers. 
 > 
 > There is.  draft-elmalki-* seems to give an impression that 
 > the absolute
 > number of state (for all users combined) is too much 

=> I read your comment to mean that the number of radio
channels is not important when there is a small number
of users. That's what I couldn't parse.

Certainly the no of PDP contexts does matter and is part
of a GGSN spec (how many it can handle). 

   -- and 
 > my immediate
 > reaction to that is that by reducing the amount of 
 > concurrent state the
 > problem could be handled.
 > 
 > This also helps to a lesser extent wrt. time consumed to 
 > setup contexts
 > (if there are free resources == few customers in the 
 > network, you can set
 > up contexts pre-emptively).

=> I've lost you here, how do you make the decision
that there are few customers in the network? How
does the UE know that? 

 > > => They are tightly coupled. The draft first makes 
 > > the case for NAT-PT and then goes into how IMS would
 > > use it. If IMS requires translation anyway, NAT-PT
 > > will be used. Everything is running in the same
 > > network. 
 > 
 > Disagree.
 > 
 > If IMS requires translation, we may end up designing a 
 > translation which
 > suits IMS.  The previous sections don't indicate which 
 > translation will be
 > used for IMS, 

=> What types of translation are there? We need IP
address and port translation, hence NAPT-PT. The
draft discusses how to install the translation
state in the translator (i.e. installing it before 
traffic goes through the translator). 


   or that if IMS uses translation, the 
 > translation would also
 > be used in *any* other kind scenario.

=> It doesn't, but how can you restrict
that in an IETF spec? If a UE doesn't get an IPv4 context, 
it will go through the translator.

Hesham