Re: [MEXT] New Text for home link detection in RFC3775bis
"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 10 July 2008 18:08 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 25E803A69AA; Thu, 10 Jul 2008 11:08:23 -0700 (PDT)
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 6E55E3A692A for <mext@core3.amsl.com>; Thu, 10 Jul 2008 11:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6]
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 0EzehVxFHgNp for <mext@core3.amsl.com>; Thu, 10 Jul 2008 11:08:21 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5C4AA3A69AA for <mext@ietf.org>; Thu, 10 Jul 2008 11:08:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iqSyH11f54/OnNdUdHkK/5U8N/w6L7MknyE61JY4xmewIi8LWIKX8BurIFrT7rJN; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1KH0ZE-0004ki-71; Thu, 10 Jul 2008 14:08:32 -0400
Message-ID: <4876501E.4060908@earthlink.net>
Date: Thu, 10 Jul 2008 11:08:30 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <486B8EDD.4070807@ericsson.com>
In-Reply-To: <486B8EDD.4070807@ericsson.com>
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5271dc38cf8100765df1bace963089f5c5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 75.26.137.116
Cc: mext@ietf.org
Subject: Re: [MEXT] New Text for home link detection in RFC3775bis
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hello Suresh, I'm creating a new issue for "home link detection" to go into the issue tracker. Your suggested text seems to have found consensus for resolving the issue, as long as it is located in a new section (as suggested in later messages). However, I would like to suggest a textual revision and simplification. Most of the revision relies on pointing out that one has to get a home network prefix before using it to compare against the list of prefixes received in the RA. The other revision, which I hope is O.K., is to dispense with creating the new acronyms CMA and CLPL. I am biased against having acronyms that are not used elsewhere in the document. Here is my result: NEW TEXT ======== Section 11.5.X Home Link Detection When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1x) it performs the following steps to determine if it is on the home link. o The MN performs the procedure described in Section 11.5.2x and configures an address. It also keeps track of all the on-link prefix(es) received in the RA along with their prefix lengths. o If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g. RFC5026) to determine the home prefix. o Given the availability of the home prefix, the MN checks whether or not the home prefix matches one of the prefixes received in the RA. If it does, the MN concludes that it has returned home. ================================================ It is also a bit tricky to determine where to locate this new section. The current organization of section 11.5 is as follows: 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 123 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 123 11.5.2. Forming New Care-of Addresses . . . . . . . . . . . . 125 11.5.3. Using Multiple Care-of Addresses . . . . . . . . . . 126 11.5.4. Returning Home . . . . . . . . . . . . . . . . . . . 127 After reading through the text, I think the new subsection would fit best after the current 11.5.1, making it a new subsection 11.5.2. ================================================ By the way, given the new subsection, the first sentence of the _current_ subsection 11.5.2 (to become subsection 11.5.3) needs to be changed: OLD: After detecting that it has moved a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. NEW: After detecting that it has moved to a link away from home, a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. ================================================= Strictly speaking, the names of section 11.5{,.1} are probably wrong. Perhaps they should be something more like "New Link{s, Detection}". This is because a node can require establishment of a new link without any movement. For instance, as we all know, sometimes wireless access points become unreachable even if we are standing still, and then we have to search for another access point in range. I haven't decided yet whether to actually go ahead and rename the sections. Comments are welcome! Regards, Charlie P. Suresh Krishnan wrote: > The WG had consensus to fold in text from draft-krishnan-mext-hld into > RFC3775bis. Here is the proposed text for doing so. Feel free to edit. > > > > This change is made in Section 11.5.4 > > OLD TEXT > ======== > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > > NEW TEXT > ======== > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section 11.5.1) it performs the > following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.2 and > configures an address referred to as the Current MN Address (CMA). > It also stores all the on-link prefix(es) received in the RA along > with their prefix lengths in a conceptual list called the Current > Link Prefix List (CLPL). > > o If the home prefix has been statically pre-configured on the MN > it checks if the home prefix matches one of the prefixes in the > CLPL. If it does, the MN concludes that it has returned home. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026) to determine > the home prefix. It then checks if the home prefix matches one of > the prefixes in the CLPL. If it does, the MN concludes that it has > returned home. > > _______________________________________________ > 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] New Text for home link detection in RFC377… Suresh Krishnan
- Re: [MEXT] New Text for home link detection in RF… fan zhao
- Re: [MEXT] New Text for home link detection in RF… Suresh Krishnan
- Re: [MEXT] New Text for home link detection in RF… mohamed.kassilahlou
- Re: [MEXT] New Text for home link detection in RF… Charles E. Perkins
- Re: [MEXT] New Text for home link detection in RF… Charles E. Perkins
- Re: [MEXT] New Text for home link detection in RF… Suresh Krishnan
- Re: [MEXT] New Text for home link detection in RF… Christian.Kaas-Petersen
- Re: [MEXT] New Text for home link detection in RF… Julien Laganier
- Re: [MEXT] New Text for home link detection in RF… Christian.Kaas-Petersen