Re: [dhcwg] Re: PD lifetimes

Erik Nordmark <Erik.Nordmark@sun.com> Mon, 03 February 2003 20:49 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 PAA21218 for <dhcwg-archive@odin.ietf.org>; Mon, 3 Feb 2003 15:49:59 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Kt8k24585 for dhcwg-archive@odin.ietf.org; Mon, 3 Feb 2003 15:55: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 h13Kt8J24582 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 3 Feb 2003 15:55: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 PAA21206 for <dhcwg-web-archive@ietf.org>; Mon, 3 Feb 2003 15:49:28 -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 h13KqkJ24492; Mon, 3 Feb 2003 15:52:46 -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 h13KpdJ24426 for <dhcwg@optimus.ietf.org>; Mon, 3 Feb 2003 15:51:39 -0500
Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21057 for <dhcwg@ietf.org>; Mon, 3 Feb 2003 15:45:59 -0500 (EST)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04300; Mon, 3 Feb 2003 13:49:35 -0700 (MST)
Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h13KnUP01669; Mon, 3 Feb 2003 21:49:31 +0100 (MET)
Date: Mon, 03 Feb 2003 21:45:55 +0100
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: [dhcwg] Re: PD lifetimes
To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
Cc: Erik Nordmark <Erik.Nordmark@sun.com>, dhcwg@ietf.org
In-Reply-To: "Your message with ID" <y7v8yx8uvb4.wl@ocean.jinmei.org>
Message-ID: <Roam.SIMC.2.0.6.1044305155.5448.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
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>

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

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


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

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.

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

   Erik

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg