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

Ralph Droms <> Wed, 29 January 2014 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A86321A03D6 for <>; Wed, 29 Jan 2014 10:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z2i554vIdXQr for <>; Wed, 29 Jan 2014 10:24:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) by (Postfix) with ESMTP id 86DF11A03CB for <>; Wed, 29 Jan 2014 10:24:22 -0800 (PST)
Received: by with SMTP id n7so3373591qcx.30 for <multiple recipients>; Wed, 29 Jan 2014 10:24:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s9iCtpZ3DQJawlx8k6sxOVr9VX4AzqwbyUfKsdGrJws=; b=MpCl/q8PhUZcKulnprggoYouDiqpmE6zvwvvRj6o57e6+cvXB2MipMWwkZfuNjayGK 7smgh4doDAAUx8EoOYcppndcudw8Fkwx4aJ2OkAH2kT96XqCDuEtEDZ3HqNuq6oaL6cK AUrfmfIeFgj1mLS2lJJ1ksada63S82rD7AsWrMvdUCbWFMSG01hCRaoLWimLv5EaplXk Do954fxnzaFIfs0YjFi7FVr34NgQDIuWlMgUxjI9EGQxz5NPxpeYtIppUtXwohVFHrp8 5RvM5y37K3Po36ikt9NEcPHO9f6/ZuOd6rvwRTLruVFpPl5BpekWhFHNTaiEoHCcl17J PjBw==
X-Received: by with SMTP id j92mr13884953qgf.7.1391019859482; Wed, 29 Jan 2014 10:24:19 -0800 (PST)
Received: from ?IPv6:2001:4830:16b1:1:adcc:b047:711a:db0e? ([2001:4830:16b1:1:adcc:b047:711a:db0e]) by with ESMTPSA id h12sm4555156qge.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 10:24:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
From: Ralph Droms <>
In-Reply-To: <>
Date: Wed, 29 Jan 2014 13:24:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Lorenzo Colitti <>
X-Mailer: Apple Mail (2.1510)
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: Wed, 29 Jan 2014 18:24:24 -0000

On Jan 23, 2014, at 1:52 PM 1/23/14, Lorenzo Colitti <> wrote:

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

You and I are pretty much in agreement here.  I'm not trying to argue in favor of sending RSes all the time.  I'm just making the observation that the basic assumptions lead to the use of periodic RSes.  I don't see that solution as an improvement over periodic RAs.

- Raph

> 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)?