Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

[Jouni <jouni.nospam@gmail.com>]

Hi Rajeev,

Thanks for your clarifications. I have few more comments inline.


On Apr 16, 2010, at 9:26 PM, Rajeev Koodli wrote:

> 
> Hi Jouni,
> 
> Thanks fo ryour input.
> 
> 
> On 4/16/10 7:27 AM, "jouni korhonen" <jouni.nospam@gmail.com> wrote:
> 
>> 
>>   (typically a /64) at the time of connection establishment, and an
>>   IPv4 address is assigned only on-demand (e.g., when an application
>>   binds to an IPv4 socket interface).  This is feasible on the same
>>   (dual-stack) PDN in LTE networks (with short DHCP lease times), or
>>   with on-demand IPv4 PDNs.  On-demand IPv4 PDN and address management
>>   can be effective in conserving IPv4 addresses; however, such a
>>   management could have some implications to how the PDN and addresses
>>   are managed at the MN.
>> 
>> Does the on-demand IPv4 PDN management here imply establishing and tearing
>> down IPv4 PDN connections based on the IPv4 use?
> 
> Not necessarily. This is typically based on session (PDN/PDP) timers on the
> network side. 

We have seen mobiles trying to be too clever here as well (not for preserving IPv4 addresses but battery). However, the outcome will be more or less the same if the document encourages establishing and tearing down connections "in a clever way". 

> 
>> If so, how does the stack
>> figure out when to tear down the IPv4 PDN connection? Such dynamic IPv4 PDN
>> connection handling probably has somewhat undesired signaling load effect
>> against the core network.
> 
> The MN does not have to do any signaling.

I am not concerned about MN doing IP layer signaling, that's peanuts. I am worried about the signaling caused by the MN playing around with the PDN connection that is then seen between core network nodes as signaling bursts. This is an issue especially with pre-LTE stuff, which seems to be the part that would actually get affected by recommendation of on-demand IPV4 connection management.. Even if the draft targets for the LTE, majority of the networks will be mix of 3G and LTE for a long time. Some text explaining pros and cons/side effects would actually be all that is needed.


>> 
>> Regarding delayed IPv4 address management. I have my concerns on "split UE"
>> cases, where the host OS runs DS stack and the  3G/4G terminal acts as a
>> modem. How would the (DHCP-based) delayed address management work in that case
>> without modifying the host OS stack? Typically the host OS stack would try to
>> configure the IPv4 address also immediately.. of course one can do tricks on
>> the driver level and fake addresses toward the host OS but..
> 
> As you know, Deferred Address Allocation is specified in 3GPP.
> The above is an issue for Deferred Address Allocation procedure for split-UE
> case in 3GPP. AFAIK, there has been no discussion of the split-UE case
> addressing. Are you aware of anything, specifically how Deferred Address
> Allocation would be used in split-UE case?

Not really.. that's why this document could/should actually make a clear distinction which of the recommended models/approaches apply where. 


> 
> Separately, I wonder how prevalent is/will-be the UE-as-a-modem model..

As for data volumes that will probably be the dominant. Also, notebooks with cellular broadband access seem to be and become increasingly popular..

- Jouni

> 
>> 
>> IMHO the draft should discuss side effects and constrains in more detail
>> related to the on-demand IPv4 PDN connection and address management before
>> suggesting them as a general guideline.
> 
> I would be glad to add more text, based on the WG discussion and consensus.
> 
> Before I do that, I would like to know whether there is interest in having
> this as a WG document :-)
> 
> Regards,
> 
> -Rajeev
> 
> 
> 
>> 
>> - Jouni
>> 
>> On Apr 16, 2010, at 1:04 AM, Rajeev Koodli wrote:
>> 
>>> 
>>> Hello folks,
>>> 
>>> I was asked at the Anaheim meeting to clarify the intended audience for this
>>> ID, which I have done in the Introduction; this document can be a useful
>>> reference for service providers and network designers.
>>> This ID does not propose any new protocols or suggest any new protocol work.
>>> 
>>> I also got a good review from Mohamed Boucadier (thanks!) which I have
>>> addressed. 
>>> 
>>> It seemed there was good interest that this ID is useful.
>>> 
>>> So, Chairs: how do we proceed?
>>> 
>>> Thanks,
>>> 
>>> -Rajeev
>>> 
>>> http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks-02
>>> 
>>> 
>>> 
>>> ------ Forwarded Message
>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>>> Date: Tue, 13 Apr 2010 16:30:59 -0700 (PDT)
>>> To: Rajeev Koodli <rkoodli@cisco.com>
>>> Subject: New Version Notification for
>>> draft-koodli-ipv6-in-mobile-networks-02
>>> 
>>> 
>>> A new version of I-D, draft-koodli-ipv6-in-mobile-networks-02.txt has been
>>> successfully submitted by Rajeev Koodli and posted to the IETF repository.
>>> 
>>> Filename:  draft-koodli-ipv6-in-mobile-networks
>>> Revision:  02
>>> Title:   Mobile Networks Considerations for IPv6 Deployment
>>> Creation_date:  2010-04-14
>>> WG ID:   Independent Submission
>>> Number_of_pages: 15
>>> 
>>> Abstract:
>>> Mobile Internet access from smartphones and other mobile devices is
>>> accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen
>>> as crucial for the continued operation and growth of the Internet,
>>> and in particular, it is critical in mobile networks.  This document
>>> discusses the issues that arise when deploying IPv6 in mobile
>>> networks.  Hence, this document can be a useful reference for service
>>> providers and network designers.
>>> 
>>> 
>>> 
>>> The IETF Secretariat.
>>> 
>>> 
>>> 
>>> ------ End of Forwarded Message
>>> 
>>> 
>> 
>