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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Mar 2003 15:25:58 +0900

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 <[email-masked]> 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.
					[email-masked]

Subject: Re: [dhcwg] Re: PD lifetimes
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: [email-masked]
Date: Sun, 26 Jan 2003 18:14:39 +0900
List-Id: <dhcwg.ietf.org>

>>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> 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.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Mar 2003 16:14:05 +0900

>> 2. Section 11.1 now specifies the requesting router to use
>> Rebind/Reply exchanges to verify an existing binding (instead of
>> Renew/Reply exchanges).  According to the very recent
>> clarifications on the base DHCPv6 spec, however, I'm not sure if
>> Rebind is appropriate here; the server should drop the Rebind
>> message unless it has an explicit knowledge about the validity or
>> invalidity of the prefix, which should not be the case (e.g.) when
>> the upstream link flaps.

> Rebind now behaves just like Confirm. if by link flap you mean change
> of link to another delegating router, the delegating router can reply
> to a Rebind even without a binding if it knows through explicit
> configuration that the prefixes in the IA_PD is not valid for the link.

Are you referring to the following part of
draft-ietf-dhc-dhcpv6-interop-00.txt?

1. Response of servers to Renew and Rebind messages, sections 18.2.3 and
   18.2.4

   Resolution: Leave the sentence in section 18.2.3 unchanged.  Replace
      the sentence in section 18.2.4 with the following text:

         If the server cannot find a client entry for the IA and the
         server determines that the addresses in the IA are not
         appropriate for the link to which the client's interface is
         attached according to the server's explicit configuration
         information, the server MAY send a Reply message to the client
         containing the client's IA, with the lifetimes for the
         addresses in the IA set to zero.  This Reply constitutes an
         explicit notification to the client that the addresses in the
         IA are no longer valid.  In this situation, if the server does
         not send a Reply message it silently discards the Rebind
         message.

The problem here is that this is a MAY requirement and that "explicit
configuration information" is ambiguous.

Since this is a MAY, the delegating router (i.e. server) MAY NOT send
a Reply message, which will cause a bad effect (that the invalid
prefix is going to be used).  For the case of address assignment, this
should be a minor issue, because this situation only happens when none
of the events to issue a Confirm happen but the upstream router has
somehow been swapped.

For the PD case, however, we don't have Confirm/Reply exchanges.  So
the requirement level should be stronger enough.

The same argument should apply to the ambiguous of the wording
"explicit configuration information".  In my understanding, the author
intentionally uses an ambiguous term because this is a very minor case
and there can be a (unidentified) trick to build the explicit
information, e.g., a background communication between a primary server
and a secondary one.

Again, for the PD case, this is more likely to happen, so we need to
be specific enough.

Thus, I would suggest to add the following text (or something like
this) to the delegating router behavior:

         If the delegating router cannot find a requesting router
         entry for the IA_PD and the delegating router determines that
         the prefixes in the IA_PD are not appropriate for the
         requesting router according to the delegating router's
         explicit configuration information, the delegating router
         SHOULD send a Reply message to the requesting router
         containing the requesting router's IA_PD, with the lifetimes
         for the prefixes in the IA_PD set to zero.  This Reply
         constitutes an explicit notification to the requesting router
         that the prefixes in the IA_PD are no longer valid.  The
         explicit configuration information of the delegating router
         contains the fact that the proposed prefixes from the
         requesting router is not covered by a prefix for the
         organization of the delegating router.

In summary, I propose to change MAY to SHOULD and to add a concrete
example of "explicit configuration information."

It would also be helpful to describe how the requesting should react
to this event.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Mar 2003 16:18:03 +0900

>> 3. Section 10.2 contains the following sentence (newly added in the
>> latest revision):
>> 
>> If the delegating router cannot delegate any prefixes to an IA_PD in
>> the message from the requesting router, the delegating router MUST
>> include the IA_PD in the Reply message with no prefixes in the IA_PD
>> and a Status Code option in the IA_PD containing status code
>> NoPrefixAvail.
>> 
>> I guess the "Reply" should be "Advertisement" here, because this
>> section is talking about "Delegating Router Solicitation."  I also
>> guess the sentence was added in response to a question of mine in
>> the ML.  If so, a similar clarification should be introduced to
>> Section 11.2 as well.  Additionally, the corresponding client
>> behaviors should also be documented.

> yes, well spotted.

After re-reading the draft, I now believe this part is just invalid in
Section 10.2 and should be moved to somewhere in Section 11.2.  In
fact, NoPrefixAvail in Advertise against Solicit is already documented
in the last paragraph of Section 10.2

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Mar 2003 16:36:06 +0900

>> 4. The PD draft should reflect some parts of
>> draft-ietf-dhc-dhcpv6-interop-00.txt.  With a quick look, Sections
>> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft.

> I have made the changes where appropriate, i.e where we already have
> cut and pasted text from the DHCPv6 base specification.

I don't think it's enough.  For example, Section 8 of
prefix-delegation-02 is almost the exact copy of Section 22.4 of
dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g.

Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to
Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to
Section 8 of prefix-delegation.

I've not gone thorough the entire issues of the interop draft, but I'm
quite sure that there still exist similar cases.  (If you are not
convinced, I'll try to make a complete list.)

>> We may be able to omit some of them as trivial clarifications, but
>> we should reflect some other part of them because the base DHCPv6
>> spec (and thus the clarifications for it) is too specific to
>> address assignment.  In some cases, implementors can use analogy of
>> the base spec to implement the PD draft, but we should basically
>> provide comprehensive information in the PD draft itself to ensure
>> better interoperability.  (As some people, including me, have
>> repeatedly pointed out, the best approach would be to make the base
>> spec generic so that each stateful method can just refer to the
>> base spec.  Since we could not make it due to the "it's too late"
>> reason, we should be responsible to implementors for providing
>> detailed information within the PD specification).

> the PD specification is not meant to be complete and needs to be read
> in conjunction with the base DHCP specification.

I know (and agree), but I'm saying the PD specification should be
clear wherever a difference between address assignment and prefix
delegation exist.  We should be rather redundant than leave the
difference ambiguous.  At least please reconsider each issue in the
interop draft and merge necessary changes from it.

					JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Sat, 08 Mar 2003 23:16:31 +0000

Jinmei-san,

> of the events to issue a Confirm happen but the upstream router has

Rebind is only done for 10 seconds (using Confirms timers), then the
client goes back to Solicit state.

I don't think we can mandate that a delegating router will know in all
cases that a prefix is valid for a link or not. I think we should keep
the same text and reasoning as in the base spec.

could any of the DHCPv6 base spec guys answer why this is a MAY, as it
does delay detection of movement.

> the requirement level should be stronger enough.

we do. just that we have to use a Rebind/Reply exchange using Confirms
timers since we want a binding confirmation, rather than just movement
detection.

> information, e.g., a background communication between a primary server

I don't think "explicit configuration" is ambiguous as such. how a
server is configured to know which prefixes are appropriate for a link
is implementation dependent.

> Again, for the PD case, this is more likely to happen, so we need to

why do you say that? isn't it more likely that a host changes links?
what cases do you have in mind?

> It would also be helpful to describe how the requesting should react

requesting router should go to Solicit state. I think this will be
made clearer in modified base spec/new PD revision where we'll use
NotOnLink rather than lifetimes = 0.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Sat, 08 Mar 2003 23:19:45 +0000

Jinmei-san,

> in the last paragraph of Section 10.2

you are absolutely right, I'll fix.

/ot

---

From: Ole Troan <[email-masked]>
Date: Sat, 08 Mar 2003 23:27:42 +0000

Jinmei-san,

> interop draft and merge necessary changes from it.

agree. revision 3 of the PD draft should have most of the issues from
the interop document included.

the interoperability testing at Connectathon last week showed that the
DHCPv6 base spec and PD specifications cannot be that bad. no protocol
problems found.

/ot

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Mar 2003 17:19:45 +0900

>>>>> On Sat, 08 Mar 2003 23:16:31 +0000, 

> client goes back to Solicit state.

Ah, okay, I missed the point.  Then I'm fine with the current
specification.  It would still be helpful to explicitly note that
Rebind only continues for 10 seconds, though.

> NotOnLink rather than lifetimes = 0.

Hmm, opt-prefix-delegation-03 still says:

   Rebind message      If the delegating router cannot find a binding
(...)
                       the delegating router MAY
                       send a Reply message to the requesting router
                       containing the IA_PD with the lifetimes of the
                       prefixes in the IA_PD set to zero.

or are you talking about a change in a future revision?

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Mar 2003 17:22:00 +0900

>>>>> On Sat, 08 Mar 2003 23:27:42 +0000, 

> the interop document included.

Okay, I'll check the changes in more detail.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Mar 2003 13:08:10 -0500

I guess the next rev of the draft should change the text to indicate the 
use of NotOnLink.

- Ralph

At 05:19 PM 3/12/2003 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>[snip]