Re: [16NG] Comments on draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
"John.zhao" <john.zhao@huawei.com> Wed, 28 March 2007 09:01 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HWU1t-0001u8-S7; Wed, 28 Mar 2007 05:01:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HWU1t-0001u2-Dg
for 16ng@ietf.org; Wed, 28 Mar 2007 05:01:17 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWU1r-0007Hh-KU
for 16ng@ietf.org; Wed, 28 Mar 2007 05:01:17 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
(built Mar
3 2004)) with ESMTP id <0JFL0013CVIKLI@szxga01-in.huawei.com> for
16ng@ietf.org; Wed, 28 Mar 2007 16:56:45 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
(built Mar
3 2004)) with ESMTP id <0JFL000K4VIJ6F@szxga01-in.huawei.com> for
16ng@ietf.org; Wed, 28 Mar 2007 16:56:44 +0800 (CST)
Received: from z49950 ([10.121.32.173])
by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
(built Mar
3 2004)) with ESMTPA id <0JFL000QBVIG9V@szxml04-in.huawei.com> for
16ng@ietf.org; Wed, 28 Mar 2007 16:56:43 +0800 (CST)
Date: Wed, 28 Mar 2007 16:56:40 +0800
From: "John.zhao" <john.zhao@huawei.com>
Subject: Re: [16NG] Comments on draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
To: 16ng@ietf.org
Message-id: <080201c77117$005e1220$ad20790a@china.huawei.com>
Organization: Huawei Technologies Co., LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: Acdsx3y2IdlBG5rUTpe0XyeW2QPIZgETzTzg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: john.zhao@huawei.com
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org
Hello,all So how about anyone think if we can consider to modify about these problems in current draft? Best Rgds, Thanks, John.zhao -----邮件原件----- 发件人: John.zhao [mailto:john.zhao@huawei.com] 发送时间: 2007年3月22日 22:14 收件人: 16ng 主题: [16NG] Comments on draft-ietf-16ng-ipv6-over-ipv6cs-09.txt Hello,all Based on the discussion in Monday,there is something about idle mode need to be clarified in current draft about ipv6cs. Firstly, if the movement detection will be triggered to a simple IPv6 MN when it cross difference ARs including both of the handover normally and idle mode? Why we need to do this?Because if we didn't specify about this scenario,then normally when the MS cross difference ARs the new AR will advertise the Router Advertisement to this MS as soon as the IPv6 link is established(section 8.2).So how about the session ongoing?Didn't support it?Or decided by network side,and the method is out of scope to this draft. If true,what we should to specified in current draft? Generally,seems have some choice can be chosen as the following: 1)Change this sentence "The AR should send a number (configurable value) of router advertisements as soon as the IPv6 link is established, to the MS." to "The AR should send a number (configurable value) of router advertisements as soon as the IPv6 link is established and network policy permitted if it existed, to the MS." 2)If we need to involve the Anchor AR concept to distinguish the difference roles of AR to simple IPv6?Or we didn't support the action that cross different ARs to a simple IPv6 MN in current stage or our wg? 3)Specified something detail about idle mode is out of scope.(Seems not a good resolution). Secondly,to mobile IPv6,there still have some network policy exist. So the same situation will occured just as the simple IPv6 that we didn't need the AR to advertise the Router Advertisement as soon as the IPv6 link is established, to the MS.So if we can also consider similar description as above? Thirdly,if we accept that idea above has showed,then if we also need to specify any more about idle mode for the AR behavior?Something about the following need to be considered: 1)When a simple IPv6 wake from idle mode,if will the MS keep to use that original AR to keep the session continuable.And if that MS need to keep the IPv6 link with it's original AR when it is in normal mode. 2)AR need to distinguish the MS is simple IPv6 or mobile IPv6 or we can push these tasks to out of scope. But state that AR need to decide if advertisement need to be sent to a MS bese on the MN movement event and network policy decision. IMHO,in my opinion, I suppose to support the session continuable even for simple IPv6.At lease from protocol perspective. And if does like this will be decide by operator. About this drafts,I think there is another problem need to be clarify is in section 6.2. In step 2, it said that the capability exchange is the REG-REQ/RSP progress. IMHO, I don't where is this come from? In IEEE802.16d-2004 and IEEE802.16e-2005,I can't find something like this decription. In IEEE802.16,the step 2 about the capability exchange is should be the SBC-REQ/RSP and REG-REQ/RSP is processed after PKMv2(this is optional).So if this is correct,the section 6.2 need to be modified as IEEE802.16 document. Maybe I am right ,but maybe not. :-) Best Rgds, Thanks, John.zhao 2007-03-22 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng