Re: [dhcwg] Re: PD lifetimes

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Tue, 04 February 2003 14:14 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23137 for <dhcwg-archive@odin.ietf.org>; Tue, 4 Feb 2003 09:14:39 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14EK8Y29727 for dhcwg-archive@odin.ietf.org; Tue, 4 Feb 2003 09:20:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EK8J29722 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 4 Feb 2003 09:20:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23118 for <dhcwg-web-archive@ietf.org>; Tue, 4 Feb 2003 09:14:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EIGJ29576; Tue, 4 Feb 2003 09:18:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147m5J05490 for <dhcwg@optimus.ietf.org>; Tue, 4 Feb 2003 02:48:05 -0500
Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13116 for <dhcwg@ietf.org>; Tue, 4 Feb 2003 02:42:12 -0500 (EST)
Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h147jgP73721; Tue, 4 Feb 2003 16:45:43 +0900 (JST)
Date: Tue, 04 Feb 2003 16:46:11 +0900
Message-ID: <y7vk7ggij3w.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Erik Nordmark <Erik.Nordmark@sun.com>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Re: PD lifetimes
In-Reply-To: <Roam.SIMC.2.0.6.1044305155.5448.nordmark@bebop.france>
References: <y7v8yx8uvb4.wl@ocean.jinmei.org> <Roam.SIMC.2.0.6.1044305155.5448.nordmark@bebop.france>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset="US-ASCII"
X-Dispatcher: imput version 20000228(IM140)
Lines: 103
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

>>>>> On Mon, 3 Feb 2003 21:45:55 +0100 (CET), 
>>>>> Erik Nordmark <Erik.Nordmark@sun.com> said:

>> Yes, *if we want to allow the delegating router to have the ability to
>> control the downstream valid and preferred lifetimes*. 

> I agree that this "if" is a key question.

> But what I don't understand is the semantics of any lifetime
> if we decide that the delegating DHCP server should not be able to
> control the prefix lifetimes, then what is the purpose of having any
> lifetime in the prefix delegation option? Wouldn't it be sufficient to
> just have T1/T2 in that case?

It is, unless we do not want to control per-prefix lifetime in a
single IA_PD.  (If we remove the notion of per-prefix lifetime, then
we'd clarify the maximum retransmission duration (MRD) of Rebind for
IA_PD accordingly).

>> 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.

> Yes, but the counter argument is for home sites that don't have
> an administrator it might make sense to allow the ISP to be able to suggest
> or control the lifetimes. Of course, managed sites might be able to override
> the lifetimes.

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.  

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.

Thus, if we introduce the lifetime parameters as a kind of optional
information for ISP to specify the lifetimes, we need to clarify which
parameters are essential and which ones are optional.

>> 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

> 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.

> 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?

>> 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.

> I don't understand this point. Did you inverse it?
> Are you saying that the RA lifetimes must not exceed the PD lifetimes
> that the router received?

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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg