Re: Review on draft-ietf-v6ops-v6-in-mobile-networks-03

Rajeev Koodli <rkoodli@cisco.com> Tue, 01 March 2011 21:53 UTC

Return-Path: <rkoodli@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413ED3A6A16; Tue, 1 Mar 2011 13:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.985
X-Spam-Level:
X-Spam-Status: No, score=-109.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5jRZ9JVKut1; Tue, 1 Mar 2011 13:53:16 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 753E63A6ACD; Tue, 1 Mar 2011 13:53:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=2425; q=dns/txt; s=iport; t=1299016461; x=1300226061; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=foQUC48YT2AHqR2drGk7jBVXiQ2SFf+2VN7sW84OXxk=; b=DhXCdjBAIAWvi7U4PtpTPnlA03URVHpIVjk9Ch00tM4RDnuNqKumX2nh QmosG3SbyxlwQT9JqEDcW4cmdpu9VZPHe1XF25yp8HJXBiZkPkTE+aMKJ XwiEA3dr3K7TQEFWYjq+LTFOt7z+me3tPr6x0+72ImEEZuMj6zRNx8+ut g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMf5bE2tJV2Y/2dsb2JhbACmUHSheJwAhWEEhRKHDYNG
X-IronPort-AV: E=Sophos;i="4.62,249,1297036800"; d="scan'208";a="221643690"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2011 21:54:19 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p21LsICs013977; Tue, 1 Mar 2011 21:54:18 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 15:54:19 -0600
Received: from 10.21.118.204 ([10.21.118.204]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Mar 2011 21:54:17 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 01 Mar 2011 13:55:02 -0800
Subject: Re: Review on draft-ietf-v6ops-v6-in-mobile-networks-03
From: Rajeev Koodli <rkoodli@cisco.com>
To: Tina TSOU <tena@huawei.com>, ops-dir@ietf.org, 'The IESG' <iesg@ietf.org>, ietf@ietf.org
Message-ID: <C992AB36.DF60%rkoodli@cisco.com>
Thread-Topic: Review on draft-ietf-v6ops-v6-in-mobile-networks-03
Thread-Index: AcvYLUFEfpsS+cO+Qg2+OHiCm81bQQALg+Tx
In-Reply-To: <019f01cbd82d$55faaa50$01effef0$@com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 01 Mar 2011 21:54:19.0341 (UTC) FILETIME=[37687FD0:01CBD85B]
X-Mailman-Approved-At: Wed, 02 Mar 2011 10:10:04 -0800
Cc: draft-ietf-v6ops-v6-in-mobile-networks@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2011 21:53:18 -0000

Hi Tina,

Thanks for the review.

On 3/1/11 8:25 AM, "Tina TSOU" <tena@huawei.com> wrote:

> Comment #1
> In section 3.1, "Delaying the public IPv4 address exhaustion involves
> assigning private IPv4 addressing for end-users, as well as extending an
> IPv4 address (with the use of extended port ranges).
>  
>>> do you mean using some solution like address + port
> (http://tools.ietf.org/html/draft-ymbk-aplusp-09)?
>      If yes, where do you think Address + Port solution should be
> implemented? Maybe one of the node could be GGSN/PDN gateway, how about the
> other node, is it the mobile node or the ANG?


My personal opinion is that you would have to modify the MN.

It is not the intent of the ID to suggest location of A+P elements, as you
probably realize.

>  
>  
> Comment #2
> In section 3.1
> "An approach to  address this problem is to make the always-on PDN to be
> IPv6, and
>    enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4
>    socket interface. This ensures that an IPv4 address is not assigned
>    for every attached MN, but only to those attempting to use the
>    traffic.  The IPv4 PDN may be subject to session idle timers upon the
>    expiry of which, the PDN (and the assigned IPv4 address) may be
>    deleted.  Another option specified in the 3GPP standards is to defer
>    the allocation of IPv4 address on a dual-stack IPv4v6 PDN at the time
>    of connection establishment.  This has the advantage of a single PDN
>    for IPv6 and IPv4, along with deferring IPv4 address allocation until
>    an application needs it"
>  
>>> now, and in the near future, most of the content would still be available
> in IPv4 network, not sure whether this solution could save private IPv4
> address.

Sure. However, by deferring the allocation of an IPv4 address until a PDN
and/or an application actually needs it, you also conserve the pool.

>     And this would also require some modification in the mobile devices.

Right. The operators who are interested in this already have the necessary
"bindings" - when a user clicks on an app (that requires IPv4 PDN), it
invokes the necessary PDN signaling if the PDN is not active already.

Regards,

-Rajeev


> 
> 
> We keep our promises with one another - no matter what!
> 
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
> 
> 
>