Re: [MEXT] IPv4 home address option in DSMIP

Hesham Soliman <hesham@elevatemobile.com> Mon, 19 January 2009 12:42 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5A93A68B3; Mon, 19 Jan 2009 04:42:03 -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 39DA228C113 for <mext@core3.amsl.com>; Mon, 19 Jan 2009 04:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599]
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 BqP91pp2Q0SV for <mext@core3.amsl.com>; Mon, 19 Jan 2009 04:41:56 -0800 (PST)
Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 05E3B3A67E5 for <mext@ietf.org>; Mon, 19 Jan 2009 04:41:55 -0800 (PST)
Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LOsr1-0003fA-Vd; Mon, 19 Jan 2009 23:03:44 +1100
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Mon, 19 Jan 2009 23:03:40 +1100
From: Hesham Soliman <hesham@elevatemobile.com>
To: Shi Xiaoyan <shi_xyan@huawei.com>
Message-ID: <C59AB74C.B237%hesham@elevatemobile.com>
Thread-Topic: IPv4 home address option in DSMIP
Thread-Index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZw==
In-Reply-To: <002901c979d8$0cc8c1b0$bd946f0a@china.huawei.com>
Mime-version: 1.0
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


>> => 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.

=> Yes I know that will use more bandwidth but I don't understand what
you're objecting to. Implementations copy the contents of the new BU into
the BC to replace the old entry, as specified in 3775. So a new BU
overwrites the old one unless you desgin a new option per extension that
tells the receiver to only refresh.

> 
> 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.

=> Well, that's the reason now, if you have better ideas, other than
designing a new option per extension please send them to the list. This is
already a bit late given that I'm making the last update for IESG comments.

Hesham

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


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