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