Re: [MEXT] New Text for home link detection in RFC3775bis
Suresh Krishnan <suresh.krishnan@ericsson.com> Fri, 11 July 2008 18:18 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259BF28C26A; Fri, 11 Jul 2008 11:18:05 -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 284F328C26D for <mext@core3.amsl.com>; Fri, 11 Jul 2008 11:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
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 YzR3jZBrZetW for <mext@core3.amsl.com>; Fri, 11 Jul 2008 11:18:03 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1DAA028C267 for <mext@ietf.org>; Fri, 11 Jul 2008 11:18:03 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m6BIIJ2m018857; Fri, 11 Jul 2008 13:18:20 -0500
Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 13:18:19 -0500
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 13:18:19 -0500
Message-ID: <4877A473.6050109@ericsson.com>
Date: Fri, 11 Jul 2008 14:20:35 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
References: <486B8EDD.4070807@ericsson.com> <4876501E.4060908@earthlink.net>
In-Reply-To: <4876501E.4060908@earthlink.net>
X-OriginalArrivalTime: 11 Jul 2008 18:18:19.0575 (UTC) FILETIME=[7EFBE470:01C8E382]
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
Hi Charlie, Your suggested text sounds good. If you are looking for a new name for these sections may I suggest "Attachment to a new link" :-) Cheers Suresh Charles E. Perkins wrote: > > 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