Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt

Lorenzo Colitti <> Thu, 23 January 2014 18:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 82C371A0035 for <>; Thu, 23 Jan 2014 10:52:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6nJn8hXbDYi for <>; Thu, 23 Jan 2014 10:52:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22a]) by (Postfix) with ESMTP id 036901A0024 for <>; Thu, 23 Jan 2014 10:52:54 -0800 (PST)
Received: by with SMTP id u16so1662981iet.29 for <>; Thu, 23 Jan 2014 10:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rvu+rAcz/W1DlOPTyzLNNgfPgzJF5476Xhw0wyVnWU0=; b=aOcNog0957CCfWMnKPhv3EDiDhV/Wrh3X+c94Ux6+SM99O1XoIkM/Hj4BHN+j2qAj+ BkE/2hG6xFomQ4C+qX5WhkqaxdIZ6vGWMAh7ZTyzCr/AXKN7AH+F9HFXmF/1NbwWclaE QuyUFv/ytGpprSFwRJq6Paz3WfR97QeTajSdbnj21wh/w3X0ol0q0He7L3hWnNAoCEbK HTgHnBFum2rIRKDSWBo0tVFSteyxlwqatPG0etEurVBGAcnNr6/dAjqkMnnGMW/gRetI qqSGEd8tzIy0WzMtUzSaaJB2eNWoZv+y+rBwGEuiH8mOWxiPHfZKkJsntM8u/9+FPIyc 1/WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Rvu+rAcz/W1DlOPTyzLNNgfPgzJF5476Xhw0wyVnWU0=; b=aMv3GdbhSZnHY3zaxjJ96sx9XVRZqgdChON4Vidf5WLnMR1pZTq+DPPXEn1HU2Dofp KvRZ0XH9r85HtNspytsuu2m2MbG9Hf0zPybElE3LMzIMqFeN4UgMf3eYF4Kr3cowbWnj QO6sZq+NRECcTcLrnt8wUMB66d8lO2PZXxuJ2Qhfc0J5MSEqeouaGcfC5todi9K2eaKx V2AThl/fDxoUJhYc4aKMhJXx9U+IJOE2ZBH7STfMJtU0DItLkwYmxpuyufcRS/5l+gTX rEC294TIR/fUoOLBTnWgF3NyT0PlNCU+tKmk4cSiTZNKGSeyUgMzoPS7LfNJK5h2yBOz jKaw==
X-Gm-Message-State: ALoCoQlJa2ve7g22Xhsv/rASIstdmn5ktrMq0T+nWWT3AIiJ0Q2nz4STNR5374dhWy0HaelxcxgAFDRR8BucgUiTRgU4htLFT90t7bq02UiHhROIoryXjEnYdg4PWaq5ENXGMKpSLqAl33huG3Bwej/bnU2aIjKxeYwtxMt0Z1/+R7uBineSv62LLFuyieYqr/mmmdNqcP2t
X-Received: by with SMTP id ek6mr543176icb.97.1390503173772; Thu, 23 Jan 2014 10:52:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Jan 2014 10:52:33 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Lorenzo Colitti <>
Date: Thu, 23 Jan 2014 10:52:33 -0800
Message-ID: <>
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
To: Ralph Droms <>
Content-Type: multipart/alternative; boundary="20cf303ea61abbc39104f0a7bff3"
Cc: IETF IPv6 Mailing List <>, draft-ietf-6man-resilient-rs <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2014 18:52:58 -0000

On Thu, Jan 23, 2014 at 9:48 AM, Ralph Droms <> wrote:

> > This may be difficult to specify correctly. Specifically, it may be hard
> to distinguish something that is being deprecated by the network (e.g., an
> RA whose lifetime is counting down because it comes from a PD) from an RA
> that is about to expire.
> Might not be necessary to differentiate.  Regardless of why the prefix
> lifetime expired and whether the host has configured other , the host will
> likely want to send periodic RSs in case a new prefix becomes available and
> "unsolicited multicast Router Advertisements are never sent" implies no RA
> to announce new prefixes.

That's true, but then you get into Erik's concern that whenever a host sees
that $SOMETHING is about to expire then it sends out an RS with exponential
backoff (until what? until it gets an RA - any RA, from anyone?).

The concern is that basically ends up with hosts sending RSes all the time
- in other words, you implement dynamic reconfiguration via polling. This
is not necessarily a good use of hosts' CPU and battery resources.

I do think that nodes should be free to send RSes if they so choose, and I
think we should say that a host MAY do so in this draft, but I don't think
we should attempt to design an architecture that depends on polling.

Any objection to saying that hosts MAY send RSes when they want to refresh
information (e.g., when it's about to expire)?