Re: [dhcwg] Re: PD lifetimes

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Wed, 5 Feb 2003 14:56:15 +0100 (CET), 
>>>>> Erik Nordmark <[e-mail]> said:

>> IMO, per-prefix (valid) lifetime (with T1/T2), along with some default
>> rules of conversion, are enough for the ISP to suggest or control
>> lifetime parameters on downstream links.  

> If you only have the valid lifetime (plus T1 and T2) then it isn't
> possible for the ISP to drive the renumbering since the ISP can't deprecate
> a prefix - the site would have to do the deprecation by twiddling something
> in the router.

> Thus AFACT if you want to allow the site to delegate renumbering to the ISP
> using PD you need (optional) valid and preferred lifetimes per prefix.

As I replied to Ole, I'm now okay to have the preferred lifetime in
the PD specification.  So let's concentrate on other points:

>> Also, we need to note the difference on the role of valid/preferred
>> lifetimes (in DHCPv6 messages) between the PD case and the address
>> assignment case.  In the context of this current thread, the DHCPv6
>> lifetimes (particularly the preferred one) are just informational
>> parameters for PD.  On the other hand, the DHCPv6 lifetimes are
>> essential parameters for address assignment.  In fact, there is no
>> value meaning "any" for the lifetimes in DHCPv6 messages from the
>> server to the client.

> Maybe I'm misunderstanding but I don't see that much difference between
> DHCP address assignment and prefix assignment. If the DHCP server provides
> a lifetime for the allocation then after that lifetime expires (assuming
> no successful renew) the address/prefix might no longer work.

> This still allows the DHCP client to use a shorter lifetime for the 
> address/prefix than the server stated, but, for both address and prefix
> assignment, using a longer lifetime than the server provided is risky.

Absolutely.  I did not say that the client (requesting router) should
be able to use longer RA lifetimes than the server (delegating router)
provided.  Perhaps my point is clearer in a related message in
response to Ole (attached below).

>> > If you add the P and V bits, then wouldn't the decrement behavior be
>> > controlled by those bits?
>> 
>> Yes.  I guess I was not clear, but I was talking about the "default"
>> behavior in the bullet 2 above.  That is, the P and V bits should be
>> off (not decrementing) by default.

> Agreed.

>> > I'm assuming that if those bits indicate that the lifetimes should not
>> > decrement in real time, then we need to specify what should happen when
>> > renew/reply fails. A reasonable approach would be to switch to decrementing
>> > in real time at that point in time.
>> 
>> This might make sense, but please let me make it sure.  Suppose that
>> we have been delegated a prefix P/48 with
>> valid lifetime: 1000sec
>> V: off
>> preferred lifetime: 500sec
>> P: off
>> T1: 250sec
>> T2: 400sec
>> 
>> Then we first advertise (say) P:1/64 on a downstream link, with fixed
>> lifetime values: 1000 and 500 sec, respectively.  After 250 sec later,
>> we start renew/rebind exchanges, if the exchange fails (after 400secs
>> since we have been delegated), we need to start decrementing the RA
>> lifetimes.  From which values should we start?  1000 and 500 secs just
>> before?  600 and 100 secs, considering the period we have spent?  Or
>> others?

> Good question.

> The 2 hour rule for stateless addrconf means that decrementing the valid
> lifetime faster than real time below the 2 hour limit will be ignored
> by the hosts.

> Thus I think starting at 1000 and 500 secs makes sense plus documenting
> that the server should be configured taking T2 into account when determining
> the max time the prefix will be used.
> Thus in this example  the server thought it was ok for the prefix to be
> used for 1000+400 secs after it handed it out.

But doesn't this change the semantics of the Valid lifetime?  Are you
saying the real "lease duration" should be valid lifetime plus T2 (if
so, what if T2 is 0, which specifies the client to choose the value)?

> Alternatively, the DHCP client should always decrement the lifetimes in
> real time i.e. the RAs will contain decrementing prefix lifetimes
> until the renew when the lifetimes would jump back up again.

>> Yes, I am (sorry if I was not clear).  To be more precise and
>> concrete, suppose that we are delegated a prefix with the valid
>> lifetime VL at time T.  Then if we advertise a downstream prefix (in
>> an RA) at time T + n(sec), the valid lifetime in the RA must not be
>> larger than VL - n, unless the delegated prefix is renewed.

> That fits what I called "alternatively" above, and in that case you don't
> need the P and V bits.

The restriction above is not that strict.  The client can use a fixed
RA valid lifetime which is much smaller than the PD valid lifetime.
This is because I prefer a larger default value for the PD valid
lifetime.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

--- Begin Message ---

>>>>> On Tue, 04 Feb 2003 23:17:36 +0000, 
>>>>> Ole Troan <[e-mail]> said:

>> 0. (I once discussed this point privately, but I could not help
>> raising this again.  Please forgive me for this repetition.)

(snip)

>> It would be much simpler to have a single "lifetime" only, which
>> controls T1 and T2, and loosely affects the RA lifetimes.

> I believe this was brought up during the DHC meeting in Yokohama. the
> main argument (coming from Thomas I think) for including the preferred
> lifetime was to simplify renumbering. it also allows for more granular
> control if PD is used in other contexts than the one specified in the
> draft.

Okay, according to the discussion in this thread, it seems that I'm in
the minority on this.  So, I'm okay to keep the preferred lifetime in
the PD specification.

> the draft specifies how a prefix is delegated but has intentionally
> left unspecified (apart from suggesting some defaults) how it is to be
> used within the site. the only requirement is that the valid lifetime
> is adhered to, anything else can be configured in any way the local
> administrator (if there is one) wants.

As I said in a separate message, this approach treats the preferred
lifetime as (a kind of) optional information, while the preferred
lifetime takes an essential role in address assignment.  In the PD
spec, the valid and preferred lifetimes are sometimes essential and
sometimes informational, which make me confused:

- the PD valid lifetime specifies the "lease duration" of the site
  prefix.  (this is essential)
- the PD valid lifetime also specifies the upper bound of the RA valid
  lifetime.  (this is a bit strong, but still informational)
- the PD preferred lifetime controls the (recommended) default values
  of T1 and T2.  (this is essential)
- the PD preferred lifetime specifies a suggestion of the RA preferred
  lifetime.  (this is informational)

Thus, it would most make sense to me if the essential and
informational parts are clearly separated.  For example,

- we have three parameters for a prefix; lease duration, valid
  lifetime, and preferred lifetime.  we also have T1 and T2 for an IA_PD.
- the lease duration is an essential information, which specifies the
  "lifetime of the site prefix" and must be specified in Reply
  messages.  It also controls the default value of T1 and T2.
- the valid and preferred lifetimes are informational, which may or
  may not be (concretely) specified in Reply messages.  If specified,
  those values mean the suggested values of the RA lifetimes.
- there are of course some trivial relationship between the
  parameters.  For instance, the valid and preferred lifetimes must
  not be larger than the lease duration.

(we may need additional bits for the valid and preferred lifetimes as
Erik suggested, but I omitted the additional bits here for simplicity.)

Doesn't this make much sense?

>> In the following comments, however, I'll assume the current valid +
>> preferred scheme.
>> 
>> 1. Section 9 says
>> 
>> In a message sent by a delegating router the preferred and valid
>> lifetimes should be set to the values specified in section "Router
>> Configuration Variables" of RFC2461 [3], unless administratively
>> configured.
>> 
>> Technically, the wording 'values specified in section "Router
>> Configuration Variables"' is not clear, because the router
>> configuration variables of RFC 2461 do not contain the valid and
>> preferred lifetimes.  The intended variables should probably be
>> AdvValidLifetime and AdvPreferredLifetime, respectively.  Even so,
>> however, I still suspect these are appropriate values.
>> AdvXXXLifetimes are for each end host (in a site), but the lifetimes
>> given by PD affect the entire site.  In general (and IMO), the latter
>> should be larger than the former.

> section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and
> AdvPreferredLifetime, so I'm not sure what is not clear.

My point is that the text should be like this:

  In a message sent by a delegating router the preferred and valid
  lifetimes should be set to AdvValidLifetime and
  AdvPreferredLifetime, respectively, as specified in section "Router
  Configuration Variables" of RFC2461 [3], unless administratively
  configured.

(though I'd like larger default value as I said below.)

>> I believe the default values of PD lifetimes should keep the default
>> values of RA lifetimes in the typical configuration.  Thus, I would
>> recommend the following values:

(snip)

> I don't see decrementing lifetimes in RA's as abnormal, nor do I see
> the benefit of advertising fixed values in RA's. there is nothing
> prohibiting an requesting router implementation to use fixed values,
> as long as it behaves correctly when the PD valid lifetime < RA
> lifetime.

Regarding this point, please refer to the succeeding discussion in
this thread.  However, if we clarified the essential and informational
parameters (see above), this part might not be an issue.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

--- End Message ---