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

[Suresh Krishnan <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>>
> 

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext