Re: [mif] Route option for DHCPv6 - next steps?

Margaret Wasserman <mrw@lilacglade.org> Thu, 29 March 2012 13:40 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09E21E801A for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 06:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.329
X-Spam-Level:
X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P02UoOvvFx0u for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 06:40:55 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E05B321F8B53 for <mif@ietf.org>; Thu, 29 Mar 2012 06:40:49 -0700 (PDT)
Received: from dhcp-43e9.meeting.ietf.org (dhcp-43e9.meeting.ietf.org [130.129.67.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id CBA24204D5; Thu, 29 Mar 2012 09:40:03 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <4F74546D.4060808@gmail.com>
Date: Thu, 29 Mar 2012 15:40:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF94E991-E81B-4424-BEE7-2D7C086293E4@lilacglade.org>
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <CAE97176.17DF4%wdec@cisco.com> <CANF0JMD_zfXGcfMy+rCOFXS1aCZ3RPHoRtkBeS8kDgOFcfQ8Fg@mail.gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <CANF0JMBbhrF0G=hSvcvyZAddAMW7oSO5KpzUmcJXCtwcnmyWOw@mail.gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <DD1241D5-B794-49C3-A3A2-4294248DDD10@gmail.com> <4F719186.3060507@gmail.com> <CAKD1Yr3tSoDPcheriWdZEeKyhqpDANCP7Co0wVVqK5+mXc7e5A@mail.gmail.com> <4F72CD22.3080604@gmail.com> <CAKD1Yr3RUUthiawKrmxjSNqzEbJcOLpHvDGb9XLtdiU-tfEYyw@mail.gmail.com>, <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Route option for DHCPv6 - next steps?
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 13:40:56 -0000

Hi Alex,

On Mar 29, 2012, at 2:24 PM, Alexandru Petrescu wrote:

> Le 29/03/2012 14:22, Tomek Mrugalski a écrit :
>> On 12-03-29 13:35, Ted Lemon wrote:
>>> Probably the best thing to do is set the router lifetime to the DHCP
>>> renewal time, and not send a lifetime separate from that.
>> We are talking about two timers here: route lifetime and renewal time
>> (governed by information refresh time, defined in RFC4242). Will add
>> clarification text that route lifetime should be greater than
>> information refresh time. Making them equal is not a such good idea as
>> it could trigger race conditions. Otherwise badness will happen.
> 
> We may be talking three timers: route lifetime, router lifetime (ND) and renewal time.

I am not exactly sure what you mean by a "timer" in this sentence?  In the implementations I have done, there is no "timer" (in the embedded systems sense) associated with each route entry.  There is a timestamp that indicates the current end of the valid lifetime for that route (the expiry time).  Before a route is used, the expiry time is checked to see if it is still valid.  Each routing table entry would have (at most) one expiry time associated with it.  Static routes have no expiry time.

Margaret