Re: [MEXT] IPv4 home address option in DSMIP
Yungui Wang <w52006@huawei.com> Sat, 24 January 2009 01:02 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 AFB953A691B; Fri, 23 Jan 2009 17:02:18 -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 F17C83A691B for <mext@core3.amsl.com>; Fri, 23 Jan 2009 17:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.296
X-Spam-Level:
X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 lf+msMft3wI3 for <mext@core3.amsl.com>; Fri, 23 Jan 2009 17:02:15 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2099C3A67F3 for <mext@ietf.org>; Fri, 23 Jan 2009 17:02:09 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY006ZYAV277@szxga03-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY00DQGAV2GJ@szxga03-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST)
Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDY00E24AUY5P@szxml06-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST)
Date: Sat, 24 Jan 2009 09:01:46 +0800
From: Yungui Wang <w52006@huawei.com>
To: "Giaretta, Gerardo" <gerardog@qualcomm.com>, Hesham Soliman <hesham@elevatemobile.com>, Shi Xiaoyan <shi_xyan@huawei.com>
Message-id: <003e01c97dbf$566847b0$150ca40a@china.huawei.com>
Organization: Huawei Technologies
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-Priority: 3
X-MSMail-priority: Normal
References: <00d801c97d0b$b3f61150$bd946f0a@china.huawei.com> <C59F9017.B3CE%hesham@elevatemobile.com> <057632CE4CE10D45A1A3D6D19206C3A3DBE30037@NASANEXMB08.na.qualcomm.com>
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: multipart/mixed; boundary="===============1233154669=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Maybe rfc3775bisxxx need state the explicit action of HA 'how to do when a mobility option is (not) carried within the lifetime extension re-registration (BU)'. Then, new MO in the subsequent draft could make consistent. B.R. Yungui ----- Original Message ----- From: Giaretta, Gerardo To: Hesham Soliman ; Shi Xiaoyan Cc: mext@ietf.org Sent: Saturday, January 24, 2009 12:27 AM Subject: Re: [MEXT] IPv4 home address option in DSMIP I agree with Hesham on this. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham > Soliman > Sent: Thursday, January 22, 2009 8:18 PM > To: Shi Xiaoyan > Cc: mext@ietf.org > Subject: Re: [MEXT] IPv4 home address option in DSMIP > > > > > On 23/01/09 2:35 PM, "Shi Xiaoyan" <shi_xyan@huawei.com> wrote: > > > Hi Hesham, > > > > HA doesn't replace the BCE such as remove the old BCE and creat a new one > > when recieved BU. > > HA just update the option in BCE also included in BU and others option in > > BCE remain valid. > > > > Such as draft-ietf-monami6-multiplecoa-11, When multiple Binding Identifier > > mobility options are present in the Binding Update, it is treated as bulk > > registration. But not all BCE should be removed. Only when 'O' flag is set, > > HA remove all old BCE. > > => We've discussed this specific point for the MCoA draft and for flow > binding. Ryuji explicitly stated that they did modify the semantics of the > BU for that draft. Please review those exchanges to see the details. > > I don't see the need for doing what you suggested below because it adds > ambiguity and the benfits are minimal. Given this late stage I'm not in > favour of making further optimisations. No one else seems to express > opinions on this so my preference is to leave it as it is. > > > Hesham > > > > > Regards, > > Xiaoyan > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Shi Xiaoyan > >> Sent: Tuesday, January 20, 2009 6:06 PM > >> To: 'Hesham Soliman' > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] IPv4 home address option in DSMIP > >> > >> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: Monday, January 19, 2009 8:04 PM > >>> To: Shi Xiaoyan > >>> Cc: mext@ietf.org > >>> Subject: Re: IPv4 home address option in DSMIP > >> > >>>> 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. > >>> > >> > >> In my opinion, re-registration BU should not include the IPv4 > >> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. > >> 2. Cause extra load on HA. Because HA must verify if the > >> address in IPv4 HAO match that in BCE in order to avoid MN > >> use a unauthorized IPv4 address. > >> > >> In fact, since "the home agent MUST be able to find the IPv4 > >> home address of a mobile node when given the IPv6 home > >> address", section 5.5, why IPv4 HAO must be include in > >> re-registration BU? I can't find any benefit. > >> > >> I didn't find the description in 3775 for "a new BU > >> overwrites the old one". > >> It should be implementation issue. > >> It also could be done as that attributes in BCE also include > >> in re-registration BU should be overwriten and other > >> attribute not included in re-registration BU should remain valid. > >> > >> De-registration for IPv4 HoA can be done by adding a bit in > >> IPv4 HAO option for indicating de-registration, or any other > >> ways. It is all ok. > >> I just think it is unnecessary that re-registration BU > >> include the IPv4 HAO. > >> :-) > >> > >> > >> > >>>> > >>>> 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 > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
_______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] IPv4 home address option in DSMIP Shi Xiaoyan
- [MEXT] IPv4 home address option in DSMIP Shi Xiaoyan
- Re: [MEXT] IPv4 home address option in DSMIP Hesham Soliman
- Re: [MEXT] IPv4 home address option in DSMIP Shi Xiaoyan
- Re: [MEXT] IPv4 home address option in DSMIP Hesham Soliman
- Re: [MEXT] IPv4 home address option in DSMIP Shi Xiaoyan
- Re: [MEXT] IPv4 home address option in DSMIP Shi Xiaoyan
- Re: [MEXT] IPv4 home address option in DSMIP Hesham Soliman
- Re: [MEXT] IPv4 home address option in DSMIP Giaretta, Gerardo
- Re: [MEXT] IPv4 home address option in DSMIP Yungui Wang