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
- [dhcwg] PD lifetimes JINMEI Tatuya / 神明達哉
- [dhcwg] Re: PD lifetimes Ralph Droms
- Re: [dhcwg] Re: PD lifetimes Jun Xie
- Re: [dhcwg] Re: PD lifetimes Ralph Droms
- Re: [dhcwg] Re: PD lifetimes Erik Nordmark
- Re: [dhcwg] Re: PD lifetimes JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: PD lifetimes JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: PD lifetimes Erik Nordmark
- Re: [dhcwg] Re: PD lifetimes JINMEI Tatuya / 神明達哉
- [dhcwg] Re: PD lifetimes Ole Troan
- Re: [dhcwg] Re: PD lifetimes JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: PD lifetimes Erik Nordmark
- Re: [dhcwg] Re: PD lifetimes JINMEI Tatuya / 神明達哉
- Re: [dhcwg] Re: PD lifetimes Erik Nordmark
- PD lifetime issues again (Re: [dhcwg] WG last cal… JINMEI Tatuya / 神明達哉