[16NG] Comments on draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

"John.zhao" <john.zhao@huawei.com> Thu, 22 March 2007 21:14 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 1HUUcN-0006pc-HG; Thu, 22 Mar 2007 17:14:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUcM-0006a2-0s for 16ng@ietf.org; Thu, 22 Mar 2007 17:14:42 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUUcK-0003Ml-91 for 16ng@ietf.org; Thu, 22 Mar 2007 17:14:42 -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 <0JFB00FVXPNEGM@szxga01-in.huawei.com> for 16ng@ietf.org; Fri, 23 Mar 2007 05:14:02 +0800 (CST)
Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFB00IEEPNDY8@szxga01-in.huawei.com> for 16ng@ietf.org; Fri, 23 Mar 2007 05:14:02 +0800 (CST)
Received: from jys5094075 (dhcp-4009.ietf68.org [130.129.64.9]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JFB00KSVPMQGB@szxml01-in.huawei.com> for 16ng@ietf.org; Fri, 23 Mar 2007 05:14:01 +0800 (CST)
Date: Thu, 22 Mar 2007 22:13:34 +0800
From: "John.zhao" <john.zhao@huawei.com>
To: 16ng <16ng@ietf.org>
Message-id: <0JFB00KSZPN1GB@szxml01-in.huawei.com>
MIME-version: 1.0
X-Mailer: Foxmail 5.0 beta1 [cn]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Subject: [16NG] Comments on draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
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>
Content-Type: multipart/mixed; boundary="===============1753548343=="
Errors-To: 16ng-bounces@ietf.org

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