[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




 > 
 > The text in elmalki draft seems to suggest that there a UE 
 > with only v6 
 > PDP context requires one radio channel, while a UE with 
 > v4/v6 PDP contexts 
 > require two radio channels (regardless of the fact that the 
 > aggregate 
 > bandwidth usage is the same).
 > 
 > I don't know the radio technology well enough to to say whether this 
 > perception is true or not.

=> Ok, we can add some text to clarify this.


 > > => 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? 
 > 
 > I don't know what (if any) signalling there is between the UE and the
 > network where some hints about network utilization could be 
 > piggybacked.  
 > Probably a lot.

=> None exists today. 

 > 
 > But even if there wasn't any, the first UE's could be 
 > programmed to open
 > both PDP contexts when they start, and possibly discard the 
 > other one if
 > it is not used in X minutes (or even keep it, no matter).

=> You're making assumptions about product rollouts and deployment
that are not necessarily correct. To be precise, you're assuming
that UE's will come in phases: "First UE's", seconds ...etc and
that they are synched with different scales of deployment.
This is not the case. Second, you assume that early networks
will be underutilised. This is also not necessarily a general
rule and depends on each operator.

 > > => What types of translation are there? We need IP
 > > address and port translation, hence NAPT-PT. 
 > 
 > No.

=> No what?

 > 
 > > The
 > > draft discusses how to install the translation
 > > state in the translator (i.e. installing it before 
 > > traffic goes through the translator). 
 > 
 > Yes, but for a very specific purpose only.

=> The draft discusses a specific case, it doesn't
_design_ a new translator for it. It discussed
the use of the existing translator.

 > > => 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.
 > 
 > Please, we're discussing the 3GPP solutions document.  We as 
 > the WG can do
 > it any way we see fit.  Hopefully the solutions are 
 > reasonable though.  
 > If operators or vendors want to do something else, that's 
 > their problem
 > and fine too.
 > 
 > We should not write the document based on what people think 
 > might happen,
 > but what we think *should* happen 

=> What _should_ happen IMHO is that we explain how
the technology would apply to 3GPP, specify pros and
cons to our knowledge and stop right there. It is futile
to try to restrict something without having a protocol
fail if you attempt to do that restricted action. 
At least this is the aim of the existing keywords in 
RFC 2119. 

Hesham