Re: [dhcwg] Re: PD lifetimes

Erik Nordmark <Erik.Nordmark@sun.com> Sat, 25 January 2003 08:10 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 DAA21730; Sat, 25 Jan 2003 03:10:57 -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 h0P8RYJ08980; Sat, 25 Jan 2003 03:27:34 -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 h0P6g6J26864 for <dhcwg@optimus.ietf.org>; Sat, 25 Jan 2003 01:42:06 -0500
Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11082 for <dhcwg@ietf.org>; Sat, 25 Jan 2003 01:21:42 -0500 (EST)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00990; Fri, 24 Jan 2003 23:24:51 -0700 (MST)
Received: from localhost (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 h0P6OkP18551; Sat, 25 Jan 2003 07:24:47 +0100 (MET)
Date: Sat, 25 Jan 2003 06:46:26 +0100
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: [dhcwg] Re: PD lifetimes
To: Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
In-Reply-To: "Your message with ID" <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.1043473586.27159.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>

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

But there are two possible uses of this that need slightly
different behavior:
1. The DHCP server is suggesting that the RAs sent by the router have a valid
   and preferred lifetime of X and Y respectively, that do not decrement over
   time. 
   This is a useful mode when no renumbering is imminent but you want to
   control the lifetimes so that you know how quickly you can renumber.

2. The DHCP server is in the process of renumbering the site thus it
   it telling the router to send RAs with lifetimes that decrement over time
   so that they will reach zero X and Y seconds, respectively, after the DHCP
   reply was sent from the server.
   This is useful when renumbering is in progress - a new prefix has been
   introduced and the old prefix is counting down its lifetime.

Note that RFC 2461 has this ability in its conceptual router variables
e.g.
                        AdvValidLifetime
                             The value to be placed in the Valid
                             Lifetime in the Prefix Information
                             option, in seconds.  The designated value
                             of all 1's (0xffffffff) represents
                             infinity.  Implementations MUST allow
                             AdvValidLifetime to be specified in two
                             ways:

                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified
                                 time in the future, or

                               - a fixed time that stays the same in
                                 consecutive advertisements.
and similar text for AdvPreferredLifetime.

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?

  Erik

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