Re: [MEXT] IPv4 home address option in DSMIP

Shi Xiaoyan <shi_xyan@huawei.com> Mon, 19 January 2009 01:49 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AEC3A691C; Sun, 18 Jan 2009 17:49:11 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA9F3A691B for <mext@core3.amsl.com>; Sun, 18 Jan 2009 17:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.166
X-Spam-Level:
X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 N688US8Cf5OS for <mext@core3.amsl.com>; Sun, 18 Jan 2009 17:49:09 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 232F93A67D6 for <mext@ietf.org>; Sun, 18 Jan 2009 17:49:09 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDP002RA3P3MK@szxga04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDP0086I3P31Y@szxga04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST)
Received: from s68128b ([10.111.148.189]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDP003MQ3P27G@szxml04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST)
Date: Mon, 19 Jan 2009 09:48:38 +0800
From: Shi Xiaoyan <shi_xyan@huawei.com>
In-reply-to: <C5983911.B200%hesham@elevatemobile.com>
To: 'Hesham Soliman' <hesham@elevatemobile.com>
Message-id: <002901c979d8$0cc8c1b0$bd946f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfA=
Cc: mext@ietf.org
Subject: Re: [MEXT] IPv4 home address option in DSMIP
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

> -----Original Message-----
> From: Hesham Soliman [mailto:hesham@elevatemobile.com] 
> Sent: Saturday, January 17, 2009 10:41 PM
> To: Shi Xiaoyan
> Cc: mext@ietf.org
> Subject: Re: IPv4 home address option in DSMIP
> 
> 
> On 17/01/09 7:17 PM, "Shi Xiaoyan" <shi_xyan@huawei.com> wrote:
> 

> 
> > I think it is redundant since only IPv6 HoA is the key for 
> BCE lookup. 
> > In maillist, I find some disscussion mails about this 
> quesion, but I 
> > can't find the reason why all BU must include IPv4 home 
> address option.
> 
> => Two reasons:
> 1. This is how a BU works, all options need to be included in 
> order for a binding to be refreshed 2. The only way the MN 
> can delete the IPv4 binding is to not include it in the BU. 

1. BU without IPv4 home address option works well for extending lifetime. I
can't understand what you said "how a BU works". Is there any Specification
to require that BU for exending lifetime  must be consistent with BU for
first register? Is there any special effect? In fact, with more and more
extension for BU in future, the requirement that BU for exending lifetime
must be consistent with BU for first register will cause unnecessary load.

2. We can find many other ways to delete the IPv4 binding if it is consensus
that re-registration BU does not have to include the IPv4 HAO. It could not
be a resason for re-registration BU must including IPv4 HAO.

> 
> Hesham
> 
> >  
> > 
> > Regards,
> > Xiaoyan
> 

Regards,
Xiaoyan

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext