IETF Logo Mail Archive

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

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Thu, 29 March 2012 12:22 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
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 D97B121F86B6 for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 05:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 SI51gB2IKC2E for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 05:22:23 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 027A521F86B1 for <mif@ietf.org>; Thu, 29 Mar 2012 05:22:22 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2088839bku.31 for <mif@ietf.org>; Thu, 29 Mar 2012 05:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=mdPa2r8JAZ8Hqnpvf70xgtte1AaFzUsYiNvY2VvmTBI=; b=B9A28IJ1MFyAJBffvsSZsiTB/rS5ZsR83KPsKmRmUX+9o/3KdhE9XMQdqwnL3DYHEn 3GjA6efG4qyS4pFzis3z5hrALl9mkJsixu1RTVEpV0XnvFP43nPlGFA3yMP/hsjU5Cmw OH1gK77Q/ghu2QIEFy5p2e2rHEgh4+U1VX+aIInj9seidH+NaRcIhJgkMYza2UBwlQ5d K0lV2/kSgbaklZa2A38/EEdFhgURiySR+ihOLlXaQtay/SW0XNKbP23Vke8kmHjRGGHc y8uNr3cHae6yyqfEEtgWzUr9Dbus9837QvanuPIG1nhlQjnH5nx878o6QOEZVRZXis0i f5Dw==
Received: by 10.205.137.15 with SMTP id im15mr13781071bkc.54.1333023742110; Thu, 29 Mar 2012 05:22:22 -0700 (PDT)
Received: from tomek.local (APuteaux-551-1-66-68.w92-132.abo.wanadoo.fr. [92.132.145.68]) by mx.google.com with ESMTPS id v2sm13340089bki.7.2012.03.29.05.22.20 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:22:21 -0700 (PDT)
Message-ID: <4F7453FC.3010502@gmail.com>
Date: Thu, 29 Mar 2012 14:22:20 +0200
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
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>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 12:22:25 -0000

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.

Tomek

v2.23.0 | Report a Bug | By Email