Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing

[Benjamin Lim <benjamin.limck at sg.panasonic.com>]

Hi Charlie,

I agree with your points.  Below is the propose text to Section 11.4.1
capturing the discussed points (hopefully).  Pls feel free to provide
comments for better wording.

Old Text (Section 11.4.1)
========
...

In this case, the mobile node MAY attempt to discover the address of
a suitable home agent on its home link.  To do so, the mobile node
sends an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address [16] for its home subnet
prefix.  As described in Section 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message.  This message gives the
addresses for the home agents operating on the home link.

The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to
any of the unicast IP addresses listed in the Home Agent Addresses
field in the Reply.  For example, the mobile node MAY attempt its
home registration to each of these addresses, in turn, until its
registration is accepted.  The mobile node sends a Binding Update to
an address and waits for the matching Binding Acknowledgement, moving
on to the next address if there is no response.  The mobile node
MUST, however, wait at least InitialBindackTimeoutFirstReg seconds
(see Section 13) before sending a Binding Update to the next home
agent.  In trying each of the returned home agent addresses, the
mobile node SHOULD try each of them in the order they appear in the
Home Agent Addresses field in the received Home Agent Address
Discovery Reply message.

New Text
========
..

In this case, the mobile node MAY attempt to discover the address of a
suitable home agent on its home link.  To do so, the mobile node sends
an ICMP Home Agent Address Discovery Request message to the Mobile IPv6
Home-Agents anycast address [16] for its home subnet prefix.  As
described in Section 10.5, the home agent on its home link that receives
this Request message will return an ICMP Home Agent Address Discovery
Reply message.  This message gives the addresses for the home agents
operating on the home link without having any lifetimes associated with
the addresses.  The mobile node MAY store these home agent addresses in
an internal list to perform its home registration procedures (e.g.
sending of Binding Update).

The mobile node, upon receiving this Home Agent Address Discovery Reply
message, MAY then send its home registration Binding Update to any of
the unicast IP addresses listed in the Home Agent Addresses field in the
Reply.  For example, the mobile node MAY attempt its home registration
to each of these addresses, in turn, until its registration is accepted.
 The mobile node sends a Binding Update to an address and waits for the
matching Binding Acknowledgement.   If the mobile node does not receive
a matching Binding Acknowledgement, the mobile node SHOULD remove that
Home Agent Address from its internal list before moving on to the next
address in its list.  The mobile node MUST, however, wait at least
InitialBindackTimeoutFirstReg seconds  (see Section 13) before sending a
Binding Update to the next home agent.  In trying each of the returned
home agent addresses, the mobile node SHOULD try each of them in the
order they appear in the Home Agent Addresses field in the received Home
Agent Address Discovery Reply message.  When the internal list is
depleted, the mobile node can re-attempt the discovery process by
sending an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address for its home subnet prefix.

Regards,
Benjamin Lim


Charles E. Perkins wrote:
> 
> Hello Benjamin,
> 
> Along the way to resolving issue #10, I had some thoughts
> about the points you raised.
> 
> If you go along with my suggestion that the home agent addresses
> supplied in the Home Agent Address Discovery Reply message
> do not have lifetimes associated with the addresses, then we can
> make a reasonable suggestion about list maintenance and processing.
> 
> I would suggest that the home agent addresses obtained from the
> Reply message should be stored and used as necessary.  When the
> current home agent becomes inaccessible, the mobile node should
> try to send an update to the next home agent on the list.  When one
> of the home agents on the list seems unresponsive, it should be
> deleted from the list of available home agents.  When the list is
> depleted, the mobile node can re-attempt the discovery process.
> 
> But these are rare events.  Perhaps the mobile node would have to
> try the discovery process on a timescale measured in months or
> years, under most scenarios for administering the home network.
> 
> If you agree with this, then I guess there is again a need for some
> clarifying text in section 11.4.1.  Contributions are always welcome.
> 
> The previous discussion points are documented at the following URL:
>    http://trac.tools.ietf.org/wg/mext/trac/ticket/10
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> 
> Benjamin Lim wrote:
>>
>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not
>> specifically
>> mention what MN will do to the list of HA address received in DHAAD
>> reply. I
>> think the confusion comes in because the section state one possible
>> way to
>> do home registration is to perform a sequential trial of each home agent
>> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA
>> address --> fail --> until end of list or succeed.) So this implies
>> that MN
>> should store the list of HA address in order to do the above action.
>> Whether
>> this list is store temporary (just to find HA) or permenantly (info
>> for MN
>> in case HA goes down) is not mention. Maybe we should add some clarifying
>> text for this matter?
>>
>> Regards,
>> Benjamin Lim
>>   
> 
> 


_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext