Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review)

From: "Krishna Kumar" <[email-masked]>
Date: Mon, 24 Jun 2002 11:17:50 -0700

Hi Charlie,

I feel that if the availability of nonvolatile storage should be a factor
in determining the lifetime, the following method would work better :

      If non-volatile storage is available, use a large value for
      lifetime  (which is the same as described in the draft, eg
      something in the range of many hours).
      Otherwise use smaller values (eg something in the range
      of many minutes).

Keeping a Refresh value is simulating the above algo by giving lower
values for a refresh if there is no non-volatile storage , and higher
values (full lifetime) if there is a non-volatile storage. Why not remove
the field completely and just use the values based on type of storage,
and get the same characteristics ?

I think that Refresh is not needed for the above mentioned reason, but
if the community feels otherwise, I feel an option might make it more
cumbersome. In that case it might be better to preserve this field in the
BA, instead of making significant changes.

Thanks,

- KK

                      "Charles E. Perkins"                                                                                                    
                      <[email-masked].        To:       Krishna Kumar/Beaverton/IBM@IBMUS                                                
                      com>                         cc:       [email-masked], [email-masked], [email-masked]      
                      Sent by:                     Subject:  Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review)                           
                      [email-masked]                                                                                                   
                      g.nokia.com                                                                                                             

                      06/22/2002 04:51 PM                                                                                                     

Hello Krishna,

The Binding Refresh Request message is useful for cases
where the Lifetime is 10 times or dozens of times larger
than the expected Refresh interval.  The idea was to avoid
having the availability of nonvolatile storage at the
home agent be a factor when choosing a value for the Lifetime.

Thus I think it is useful, but I really think that we will
have to wait and see to be sure.  Furthermore, if people
think that it is useful for only a small percentage of the
total number of Binding Updates, then we could reorganize
the feature as controlled by an option instead of a field
that is present in all Binding Update messages.  If this is
preferred, I'd like to find out immediately so that we can
fix the specification before the deadline.

Regards,
Charlie P.

> 19. Section 10.2 : The para about :
>
>    "-  The Refresh field MUST be set to a value less than or equal to"
>
>    Is Refresh useful at all ? I don't believe it is. It seems to imply
that
> it
>    helps in the case of the Home Agent crashing and has only a volatile
> storage
>    for the binding cache.  But if the Home Agent crashed before the
Refresh
>
>    interval is over, the behaviour is identical to the case where the
> Refresh
>    field contains the same value as Lifetime.
>
>    It will be useful only if the HA crashed after the Refresh interval
but
> before
>    the Lifetime interval. Hence it is completely useless in most
> situations.
>
>    If this can be removed safely, all references need to be removed in
the
>    draft and the Format of the BU section (6.1.8) needs to reflect this.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Jun 2002 19:22:13 +0300

> and get the same characteristics ?

I agree.

> BA, instead of making significant changes.

I agree here as well.

My suggestion is that we remove the field.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Jun 2002 16:36:13 -0700

Hello folks,

First, I need to clearly state that I am in the role of providing
information, not crusading, because I am neutral.

Having said that, I feel that there is a need to present the
information about this issue so that a better informed decision
can be made.   I forgot who originally proposed this field (it was
not me), but it was discussed more than once before, and it does
not seem right to expunge it if it's not clearly understood.

It is true, that mixing together lifetime issues due to two
different effects (home agent volatility vs. node mobility)
may invite problems in the future.  Thus, I do not like the
suggestion that we should make the lifetime to be the minimum
of the two effects in all cases.

On the other hand, we don't need to have the Refresh field
in all Binding Acknowledgements, most probably.  So, I will
take it out.  Then the question is whether we should have a
option for the information.  That seems to me to be the right
solution, given the long history of the field.  The purpose of
the information is only advisory; the home agent would keep
the binding current for the full lifetime of the Binding
anyway, even if a new Binding Update did not arrive within
Refresh seconds.

If consensus is to remove the feature entirely even after
understanding what it was for, then that is also O.K. with me.
I would just expect that it amounts to omitting the feature
entirely, not causing it to be commingled with whatever
considerations cause selection of a particular Lifetime value.

Regards,
Charlie P.