Re: [dhcwg] Re: PD lifetimes

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Sun, 26 January 2003 14:00 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 JAA17995; Sun, 26 Jan 2003 09:00:26 -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 h0QEKHJ04888; Sun, 26 Jan 2003 09:20:17 -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 h0Q9VHJ25031 for <dhcwg@optimus.ietf.org>; Sun, 26 Jan 2003 04:31:17 -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 EAA15452 for <dhcwg@ietf.org>; Sun, 26 Jan 2003 04:10:51 -0500 (EST)
Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q9EHR86987; Sun, 26 Jan 2003 18:14:17 +0900 (JST)
Date: Sun, 26 Jan 2003 18:14:39 +0900
Message-ID: <y7v8yx8uvb4.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.1043473586.27159.nordmark@bebop.france>
References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> <Roam.SIMC.2.0.6.1043473586.27159.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: 59
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 Sat, 25 Jan 2003 06:46:26 +0100 (CET), 
>>>>> Erik Nordmark <Erik.Nordmark@sun.com> 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.
					jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg