[MEXT] [mext] #10: The usage of "HA lifetime" [Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

["mext" <trac at tools.ietf.org>]

Ticket #10: The usage of "HA lifetime"  [Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

 Does the MN remove the HA entry used for current home registration,
 when the lifetime of that HA is expired?  Or, does the MN start
 discovering the HA again and re-send the BU to the newly discovered HA?

 ...  if MN manages the HA lifetime if the lifetime is available,
 we need some operational description when the lifetime is not available.
 RFC3775 clearly said that the HA entry MUST be deleted when its lifetime
 is expired.  BUT the lifetime is not always available...

 <Proposed resolutions>:[[BR]]
 1. George Tsirtsis <tsirtsis at googlemail.com>[[BR]]
     No cache. MN does not record the HA information in its home agent
 list.[[BR]]
 2. Vijay Devarapalli <vijay at wichorus.com>[[BR]]
     Local configuration matter. No modification is required to
 RFC3775.[[BR]]

 I personally agree with Vijay, but I think we need some clarification
 for this in the bis.  We might need to define the default value for
 the locally configured HA lifetime..

 -------------------------------------------------------------------------

 Benjamin Lim <benjamin.limck at sg.panasonic.com> wrote:

 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?


----------------------------------------+-----------------------------------
 Reporter:  charliep at computer.org       |       Owner:  charliep at computer.org
     Type:  defect                      |      Status:  new                  
 Priority:  minor                       |   Milestone:                       
Component:  draft-ietf-mext-rfc3775bis  |     Version:                       
 Severity:  Active WG Document          |    Keywords:                       
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/10>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext