[dhcwg] Re: PD lifetimes

Ole Troan <ot@cisco.com> Tue, 04 February 2003 23:17 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 SAA07695 for <dhcwg-archive@odin.ietf.org>; Tue, 4 Feb 2003 18:17:03 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14NMi600337 for dhcwg-archive@odin.ietf.org; Tue, 4 Feb 2003 18:22:44 -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 h14NMiJ00334 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 4 Feb 2003 18:22:44 -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 SAA07650 for <dhcwg-web-archive@ietf.org>; Tue, 4 Feb 2003 18:16:32 -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 h14NLFJ32739; Tue, 4 Feb 2003 18:21:15 -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 h14NKDJ32697 for <dhcwg@optimus.ietf.org>; Tue, 4 Feb 2003 18:20:13 -0500
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07568 for <dhcwg@ietf.org>; Tue, 4 Feb 2003 18:14:00 -0500 (EST)
Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h14NHbSQ017219; Tue, 4 Feb 2003 15:17:37 -0800 (PST)
Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA11574; Tue, 4 Feb 2003 23:17:36 GMT
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
Cc: rdroms@cisco.com, dhcwg@ietf.org
From: Ole Troan <ot@cisco.com>
Date: Tue, 04 Feb 2003 23:17:36 +0000
In-Reply-To: <y7vy95cf9ta.wl@ocean.jinmei.org> (JINMEI Tatuya / 神明達哉's message of "Thu, 23 Jan 2003 19:18:57 +0900")
Message-ID: <7t5el6neiun.fsf@mrwint.cisco.com>
User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8)
References: <y7vy95cf9ta.wl@ocean.jinmei.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [dhcwg] Re: PD lifetimes
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>

> I have several comments about lifetimes of prefix delegation (PD).  In
> this message, I'm talking about
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt.
>
> 0. (I once discussed this point privately, but I could not help
>    raising this again.  Please forgive me for this repetition.)
>
> I cannot understand the reason why the prefix has the notion of
> the preferred lifetime, whose role is not clear.  The role of the
> valid lifetime is very clear; the period that the delegated site can
> use the prefix.  However, the preferred lifetime only controls a loose
> relationship with the preferred lifetime in router advertisements
> within the site, and roughly controls the T1/T2 values.
>
> It would be much simpler to have a single "lifetime" only, which
> controls T1 and T2, and loosely affects the RA lifetimes.

I believe this was brought up during the DHC meeting in Yokohama. the
main argument (coming from Thomas I think) for including the preferred
lifetime was to simplify renumbering. it also allows for more granular
control if PD is used in other contexts than the one specified in the
draft.

the draft specifies how a prefix is delegated but has intentionally
left unspecified (apart from suggesting some defaults) how it is to be
used within the site. the only requirement is that the valid lifetime
is adhered to, anything else can be configured in any way the local
administrator (if there is one) wants.

> In the following comments, however, I'll assume the current valid +
> preferred scheme.
>
> 1. Section 9 says
>
>      In a message sent by a delegating router the preferred and valid
>      lifetimes should be set to the values specified in section "Router
>      Configuration Variables" of RFC2461 [3], unless administratively
>      configured.
>
> Technically, the wording 'values specified in section "Router
> Configuration Variables"' is not clear, because the router
> configuration variables of RFC 2461 do not contain the valid and
> preferred lifetimes.  The intended variables should probably be
> AdvValidLifetime and AdvPreferredLifetime, respectively.  Even so,
> however, I still suspect these are appropriate values.
> AdvXXXLifetimes are for each end host (in a site), but the lifetimes
> given by PD affect the entire site.  In general (and IMO), the latter
> should be larger than the former.

section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and
AdvPreferredLifetime, so I'm not sure what is not clear.

> Today, on typical IPv6 links, we see fixed values of the valid and
> preferred lifetimes in Router Advertisements, i.e., AdvValidLifetime
> and AdvPreferredLifetime.  However, according to the default values of
> the PD lifetimes and to the specified relationship between the PD
> lifetimes and RA lifetimes described in the last paragraph of Section
> 11.1, it is highly possible to see smaller RA lifetimes than the
> current typical cases.  Moreover, if the requesting router simply uses
> the PD valid (or preferred) lifetime for the RA valid (or preferred)
> lifetime, we'll see the RA lifetime being decremented.
>
> I believe the default values of PD lifetimes should keep the default
> values of RA lifetimes in the typical configuration.  Thus, I would
> recommend the following values:
>
> The default value for the PD preferred lifetime is
> (5 / 4) * AdvPreferredLifetime.
> The default value for the PD valid lifetime can be an arbitrary value,
> but should not be smaller than AdvValidLifetime + PD preferred lifetime.
>
> The rationale of the default is that we won't see "abnormal" RA
> lifetimes unless the requesting router fails renew/reply exchanges and
> starts rebinding, assuming that "T2" for the prefix is (equal to or
> smaller than) the PD preferred lifetime * 0.8.

I don't see decrementing lifetimes in RA's as abnormal, nor do I see
the benefit of advertising fixed values in RA's. there is nothing
prohibiting an requesting router implementation to use fixed values,
as long as it behaves correctly when the PD valid lifetime < RA
lifetime.

> 2. Section 9 also says
>
>    In a message sent by a delegating router to a requesting router, the
>    requesting router MUST use the value in the valid lifetime field and
>    MAY use the value in the preferred lifetime field.
>
> This sentence is not clear to me.  Where and how does the requesting
> router "use" the lifetimes?  This ambiguity also makes the term "MUST"
> and "MAY" unclear.  Perhaps the sentence intends to specify the
> relationship between RA lifetimes and PD lifetimes described in
> Section 11.1, but I cannot be sure without any reference.

agree, should be clarified.

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