RE: [netlmm] Issue: Link-local address collision on the access link

"John.zhao" <john.zhao@huawei.com> Thu, 09 August 2007 08:16 UTC

Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3Bo-0001DU-E1; Thu, 09 Aug 2007 04:16:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3Bn-0001DJ-61 for netlmm@ietf.org; Thu, 09 Aug 2007 04:16:15 -0400
Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ3Bm-0004wL-Fe for netlmm@ietf.org; Thu, 09 Aug 2007 04:16:15 -0400
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMH00G6KYY119@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 09 Aug 2007 16:15:37 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMH00HOPYY0TT@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 09 Aug 2007 16:15:37 +0800 (CST)
Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMH00EOTYXXA4@szxml04-in.huawei.com> for netlmm@ietf.org; Thu, 09 Aug 2007 16:15:36 +0800 (CST)
Date: Thu, 09 Aug 2007 16:15:33 +0800
From: "John.zhao" <john.zhao@huawei.com>
Subject: RE: [netlmm] Issue: Link-local address collision on the access link
In-reply-to: <200708081538.04722.julien.IETF@laposte.net>
To: 'Julien Laganier' <julien.IETF@laposte.net>
Message-id: <00d201c7da5d$75125d60$a864a8c0@china.huawei.com>
Organization: Huawei Technologies Co., LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcfZwWA+mSo+Ez8ZSvWc+awk8T1YJAAlHT2g
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: john.zhao@huawei.com
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org

On Wednesday 08 August 2007, John.zhao wrote:
> ...... (omitted those discussed)
> But juat as mentioned above the router 
> discovery still consume the time of this handover
> progress. 

The latency incurred by the router discovery itself  
(i.e RtSol/RtAdv exchange) one round trip time on the 
access link (MN-MAG). This is negligible compared 
latencies induced by other aspects of the PMIP 
protocol (e.g. PBU/PBA exchange between the MAG and an 
LMA far away in the core network).
[John.zhao] What means the negligible? During handover progress, MN will
detect the new router reachable after it can believe that old one is
unreachable. The neighbor unreachable detection will cost :
	Random factor times BaseReachableTime milliseconds.
	Comments: Random factor between MIN_RANDOM_FACTOR and
MAX_RANDOM_FACTOR
			MIN_RANDOM_FACTOR :0.5
			MAX_RANDOM_FACTOR :1.5
			The default value of basereachabletime is 30,000
	(The definition above come from RFC2461)
	to do the neighbor unreachable detection.
	Considering the time before MN initiate the NUD progress, this time
maybe less than 1 second, but can't be ignored to a continues application. I
estimate it will need 30-200 microseconds.
	So we can conclude that it not as simple as a round-trip RS/RA
progress.
> So MN seems not benefit much more from 
> this mechanism.

Yes it will benefit since it works well with DNAv6 
nodes, and DNAv6 avoids DAD latency which is 1 second 
by default.
[John.zhao] But DNAv6 is a option to MN, not mandatory.

And one second is a *lot* compared to the latencies 
we've talked about so far (RtSol/RtAdv latency, 
PBU/PBA latency).

> 	On the other hand , if we choose the IID of LMA,
> then everything is ok. The DAD is no need  and the
> router discovery is also no need during the handover
> progress. So seems this is the option 5#.

See my comments above. The router discovery induced 
latency is negligible relatively to PMIP induced 
latency. It doesn't make sense to optimize something 
negligible.

[ and BTW, in what you're proposing the MAG is no 
longer an IPv6 router, but a transparent IPv6-layer 
bridge. That's not the assumption we've been working 
with in the WG. ]
[John.zhao]The same as the above explanation. The discovery and decision for
default gateway isn't a negligible progress.
--julien



_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm