[dhcwg] Re: PD lifetimes

Ralph Droms <rdroms@cisco.com> Fri, 24 January 2003 01: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 UAA26568; Thu, 23 Jan 2003 20:14:41 -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 h0O1WdJ09703; Thu, 23 Jan 2003 20:32:39 -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 h0O1V7J09650 for <dhcwg@optimus.ietf.org>; Thu, 23 Jan 2003 20:31:07 -0500
Received: from rtp-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 UAA26541 for <dhcwg@ietf.org>; Thu, 23 Jan 2003 20:11:50 -0500 (EST)
Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O1G5qs007111 for <dhcwg@ietf.org>; Thu, 23 Jan 2003 20:16:05 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA29303 for <dhcwg@ietf.org>; Thu, 23 Jan 2003 20:15:15 -0500 (EST)
Message-Id: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Jan 2003 20:15:10 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
In-Reply-To: <y7vy95cf9ta.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

0. The preferred lifetime is there for the case in which the DR and RR have 
agreed to let the DR control the lifetimes on the links downstream from the RR.

1. In response to your first comment, suppose we change the paragraph in 
question to:

      In a message sent by a delegating router the preferred and valid
      lifetimes for each prefix should be set to the values
      AdvValidLifetime and AdvPreferredLifetime for that prefix, as
      specified in section "Router Configuration Variables" of RFC2461
      [3], unless administratively configured.

If I understand your second comment correctly, following the PD spec will 
result in the valid lifetimes in the RAs on the downstream links from the 
RR grow smaller over time, so as not to exceed the valid lifetime for the 
prefix in the IA_PD, until the RR sends a Renew to extend the valid 
lifetime on the prefix.  Did I get that right?  Is this situation a problem 
for the hosts on the downstream links and should we try to fix the problem?

2. Proposed clarification for the sentence in question:

    The requesting router MUST select the value of AdvValidLifetime
    assigned to any prefixes subnetted from a delegated prefix to be
    less than the preferred lifetime in the prefix option for that
    delegated prefix.  The requesting router MAY use the preferred
    lifetime in the prefix option for a delegated prefix as the value
    of AdvPreferredLifetime for a prefix subnetted from that delegated
    prefix, if the requesting router chooses to allow the delegating
    router to control that value.  Otherwise, the requesting router
    chooses a value of AdvPreferredLifetime for the subnetted prefix
    that is less than the value of AdvValidLifetime for that prefix.

- Ralph

At 07:18 PM 1/23/2003 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>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.
>
>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.
>
>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.
>
>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.
>
>                                         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