Re: [MEXT] New Text for home link detection in RFC3775bis

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