IETF Logo Mail Archive

Re: rs-refresh

Lorenzo Colitti <lorenzo@google.com> Thu, 05 March 2015 06:28 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CCB1B29C3 for <ipv6@ietfa.amsl.com>; Wed, 4 Mar 2015 22:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaJBCKcmd_m6 for <ipv6@ietfa.amsl.com>; Wed, 4 Mar 2015 22:28:21 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDA61B29C1 for <6man@ietf.org>; Wed, 4 Mar 2015 22:28:21 -0800 (PST)
Received: by igjz20 with SMTP id z20so43301411igj.4 for <6man@ietf.org>; Wed, 04 Mar 2015 22:28:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=en/0qaEApBgWfvFLUMdOjzlL0kR3a3fxbWd7p4ncWqo=; b=KGgn519jhUiPmJtLrYSv3JpbFib38LXcZHrZi4I13lhy5+Q4949TgaoW1EAO1NhZfF yeorCKpxkd37HSgKXW5HIgkdAbD3mRv/QHetXDtSFiYoSSR/+zG3885C769zVoOJlXIt HuNm13BELNmb16bNoUFiajtgD/ckxEx11vufzYnCwiebhbdhFqzDOjCXM5rYN2zWUAPb lPagnbxeMPfYnNfW+e+igrTKfCFBdUcWoDDh5nEYyqP6VD7YsqSgV0of4CCjlh7kzE2u cOCMp8eG/qdEJcihwukYIiYSlc59lm3arn/bO1elPrNFKiVqCv/1oTZxjlaqauoJCETF AFHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=en/0qaEApBgWfvFLUMdOjzlL0kR3a3fxbWd7p4ncWqo=; b=Wz2Ug2A4ppscqn/09ZVJxLGp6ojIcmYXO9Wht+Jj5q5s44hyCugvbu+x//1DlEgXiM bN0X46kjkKUWxj90Guy8rggUXEL9MJD6NAPI7JClcHqM8q6caSF2VYylm33u8i9QheWY 5lNnbW32wOsYc6RUiSNiEXMcil7oc746siC5OfNXX7Mw2WF/kXkF1NwBdsI1PD/zFdOQ yOtPLVfR7tnhXyH6RbYZwlS+y9Q3WNlFEk1Px8reLj1PXDtDu9TbTdLIwKFDNsXt+xgc CunUVgvwOgDywII+kixl5IBoWTC3uxSBbrI7ldXZY4Gr/8ff5RO+nuR4/rdjq5wo+x0M gY5Q==
X-Gm-Message-State: ALoCoQnREI/MqHxtHg2yLarUXjAsLzwU643oIUGuX1Wh/ja8TlR25/yOI2FiygBrO74G4KiucSwN
X-Received: by 10.107.152.211 with SMTP id a202mr17716985ioe.59.1425536901162; Wed, 04 Mar 2015 22:28:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.104 with HTTP; Wed, 4 Mar 2015 22:28:01 -0800 (PST)
In-Reply-To: <54F7EBB0.20209@acm.org>
References: <54F7EBB0.20209@acm.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 05 Mar 2015 15:28:01 +0900
Message-ID: <CAKD1Yr3=-GBo7y2=n9HwL4G-T1iNwRCzizO8Fbb2yKaUQ660wA@mail.gmail.com>
Subject: Re: rs-refresh
To: Erik Nordmark <nordmark@acm.org>
Content-Type: multipart/alternative; boundary="001a1140f5389bdba8051084acd0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/_VDAqHkRWJR3l1BNVU5OJKF4YR8>
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 06:28:23 -0000

On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <nordmark@acm.org> wrote:

> The idea is to provide an option where the network operator can move away
> from doing periodic multicast RA messages (on links like 3GPP/LTE, or WiFi
> where it is expensive) and instead have the routers instruct the hosts to
> send unicast RS messages to refresh the information - get a unicast RA.
>

I don't think this is as useful as it appears to be at first glance, for a
few reasons:

   1. This is only useful if all the hosts on the link support it. If one
   host does not support it, then we fall back to sending multicast RAs again.
   2. Despite what the document says (in two different sections), it is not
   possible to make it so that "updated nodes can sleep better" AND "preserve
   the timely and scalable reconfiguration capabilities that a periodic RA
   model provides" unless there are no legacy hosts on the network
   3. If the router misses all the RSes from a legacy node (which for a
   legacy node that doesn't implement resilient RS, means a total of 3 packets
   sent within 3 seconds of each other, which is quite possible) then that
   node is blackholed.
   4. If the router loses state, all legacy nodes are blackholed.

In general I'd prefer to see what the problems with the RA push model are,
and then address those, rather than going to a hybrid push/pull model like
this.

v2.23.0 | Report a Bug | By Email