PD lifetime issues again (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt)

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

Sorry for not responding sooner.

From this message, I'll separate the thread for each particular issue.

>>>>> On Fri, 28 Feb 2003 00:46:37 +0000, 
>>>>> Ole Troan <[e-mail]> said:

>> 1. Issues about the preferred and valid lifetimes were not fully
>> addressed.  I've not seen consensus on this in the dhc-wg ML.
>> Please re-check the thread entitled "PD lifetimes" that started on
>> Thu, 23 Jan 2003 19:18:57 +0900.

> what specifically are you referring to here? in my opinion we reached
> consensus that:

>  - both preferred and valid lifetimes are needed
>  - prefixes or addresses derived from the prefix MUST not be used
>    beyond the valid lifetime

These two are okay.

>  - adding P and V bits to specify if a prefix advertised in an RA
>    should use a fixed lifetime or a real time lifetime, is not needed
>    as it does not seem to add value or solve any specific problem.

I'm not yet fully convinced on this, particularly about the P bit.
The motivation of having the preferred lifetime should be to allow the
delegating router to control smooth renumbering.  In a renumbering
phase, the preferred (and valid) lifetime in RA at a downstream link
should be decreasing in real time.  But it is not clear to me how the
preferred lifetime in RA is decreasing.  The PD draft just says:

   A
   requesting router MAY use the preferred lifetime specified in the
   IA_PD Prefix option.
(Section 11.1 of prefix-delegation-02)

What does "use" mean here?  If it means the requesting router copies
the PD pltime to the RA pltime, the latter won't decrease.  If this
has the same meaning as that for the valid lifetime:

   the requesting router MUST
   set the valid lifetime in those advertisements to be no later than
   the valid lifetime specified in the IA_PD Prefix option.
(just before the sentence cited above)

why not just use the same phrase?

I also requested that the default value of the valid lifetime in a PD
prefix option be larger than AdvValidLifetime (see the "summary" part
of the message).  At least I've not seen a "consensus" to reject the
request.  Erik rather seemed to share my motivation according to the
discussion after the attached message below.

Furthermore, I still have a concern about the difference between the
role of prefix pltime and that of address pltime (I have repeatedly
tried to point it out, but perhaps I was not clear enough).  The
former is a kind of an optional parameter, while the latter is a
mandatory one:

   A
   requesting router MAY use the preferred lifetime specified in the
   IA_PD Prefix option.
(Section 11.1 of prefix-delegation-02)

   In a message sent by a server to a
   client, the client MUST use the values in the preferred and valid
   lifetime fields for the preferred and valid lifetimes.
(Section 22.6. of dhc-dhcpv6-28)

Note the former uses a MAY but the latter uses a MUST.

Despite the difference on the requirement level, the PD draft has
(almost) exactly the same recommendation about the relationship
between T1/T2 and pltime as that of the DHCPv6 draft:

   Recommended values for T1
   and T2 are .5 and .8 times the shortest preferred lifetime of the
   prefixes in the IA_PD, respectively.
(Section 8 of prefix-delegation-02)

   Recommended values for T1 and T2 are .5 and .8 times the
   shortest preferred lifetime of the addresses in the IA, respectively.
(Section 22.4 of dhc-dhcpv6-28)

The recommendation of DHCPv6 seems reasonable, since the client MUST
use the preferred lifetime in the IA.  In the PD case, however, the
requesting router (i.e. the client) MAY "NOT" use the preferred
lifetimes in the IA_PD, which makes the recommendation less
reasonable.

Now I have a concrete proposal.

  - add a special value for the PD preferred lifetime which means
    the requesting router can choose the RA preferred lifetime.  0
    would be a reasonable value for this.
  - change the default value of the PD preferred lifetime to the
    special value.
  - change the requesting router behavior on the received preferred
    lifetime to:
      (if the preferred lifetime in IA_PD is not the special value)
      the requesting router MUST
      set the preferred lifetime in those advertisements to be no later than
      the preferred lifetime specified in the IA_PD Prefix option.
  - change the recommendation on the T1/T2 values so that they are
    based on the valid lifetimes, e.g.:
      Recommended values for T1
      and T2 are .5 and .8 times the shortest valid lifetime of the
      prefixes in the IA_PD, respectively.
  - (assuming the change on the recommendation) choose the default
    value of the PD valid lifetime so that the RA valid lifetime won't
    decrease as long as Renew/Reply exchanges succeed.  5 times the
    AdvValidLifetime would be a good candidate.
  - (optional) it may also make the intention clearer if we could
    change the field name of PD valid and preferred lifetimes to,
    e.g., "lease-time" and "adv-preferred-lifetime", respectively.

With this proposal, the typical (default) operation will be like this:
(assuming 0 as the "special value" for the PD preferred lifetime)

  - the delegating router suggests a following parameters for each
    prefix:
      AdvValidLifetime * 5 (150 days) as the valid lifetime
      0 as the preferred lifetime
    and T1/T2 be 75/120 days.
  - before T2 expires, the requesting router can use any value for RA 
    valid lifetime not larger than 30 days (AdvValidLifetime).  In
    particular, it can use the constant value of AdvValidLifetime.
  - similarly, the requesting router can use any value for RA
    preferred lifetime not larger than RA valid lifetime until T2
    expires.  In particular, it can use the constant value of
    AdvPreferredLifetime.

When the delegating side wants to initiate a renumbering, the
delegating router will specify a positive (but finite) value as PD
preferred lifetime.  Then the succeeding RA preferred lifetime will
decrement in real time.

I strongly believe the proposed change makes the specification clearer
in terms of the intended usage of PD (comparing to that of address
assignment).  Also, the proposed change does not require a large
change on the actual behavior on the current draft; it just changes
the default value of the lifetime field, and introduces a minor change
about the relationship between PD lifetimes and RA lifetimes.  Thus, I
don't think the change affects early implementations much.

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

--- Begin Message ---

>>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET), 
>>>>> Erik Nordmark <[e-mail]> said:

> Presumably the PD draft could do this as well by having a bit (or two)
> indicating wheter the lifetime(s) should decrement in real time or be
> constant.

> Would that make sense?

Yes, *if we want to allow the delegating router to have the ability to
control the downstream valid and preferred lifetimes*.  Actually, RFC
2894 (Router Renumbering for IPv6) has a similar notation:

   V           A 1-bit flag indicating that the valid lifetime of the
               New Prefix MUST be effectively decremented in real time.

   P           A 1-bit flag indicating that the preferred lifetime of
               the New Prefix MUST be effectively decremented in real
               time.
(Section 3.2.1.2)

The current PD draft implicitly assumes the (not-yet-introduced)
additional flags are on, while these bits are off in the current
typical cases.

Before going that further, however, I still think it is overkilling
for the delegating router to have the ability to control the
downstream lifetimes.  IMO, the requesting router (and the site's
administrator) should be responsible for such parameters, with one
trivial constraint: the site lifetimes must not be smaller than the
lifetimes of each downstream link.

In summary,

I first would like to make a consensus if we need to allow the
requesting router to have the ability to control the downstream
lifetimes.  As I said above, I'm negative on this.

If our consensus is to allow the delegating router to have the
ability, it's okay.  Then,

  1. the requesting router should also have the additional bits (like
     P and V above),
  2. (this may be controversial) the lifetimes in router advertisement
     on each downstream link should be the same as the default of RFC
     2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT
     decreasing in real time), as long as Renew/Reply exchanges
     succeed, and
  3. in any case, the valid lifetime of a prefix delegated by PD must
     not be smaller than the valid lifetime in router advertisements
     on any downstream link.

Note that, as a consequence of 2 and 3, the default value of the valid
lifetime in a PD prefix option must be larger than AdvValidLifetime.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg

--- End Message ---