Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

Mark Smith <> Tue, 21 July 2015 09:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 185F41B2C73 for <>; Tue, 21 Jul 2015 02:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q491B4WHd8Ou for <>; Tue, 21 Jul 2015 02:51:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E5721B2C97 for <>; Tue, 21 Jul 2015 02:51:11 -0700 (PDT)
Received: by ietj16 with SMTP id j16so137989784iet.0 for <>; Tue, 21 Jul 2015 02:51:10 -0700 (PDT)
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=QzIApqBYNgfC+Avpw6O4+e29x3v0y3Gaoj1NIcNUons=; b=ha+qumOTjVEzVNZ7iwHaAOqDJ2Ze/8GzdCPbPBQHQ6x8N6p2UisJTjEH01Ja71ExEJ 4s13iKikR9GGv/IDVCRMYougfTH3kZdVe+/PUOHYUJEhNl9b+y5flTTmDmKWHPk+m4Zz o5YkZz2OWA9xRBJopjE0pf5jHszVQdOGThDbzatLEqG9S6m5zyrZOcz//Jni9uFlmFs8 D4FCcTXZoW+F/j0WzJxsFL+zjD0fyytv/8GLtKkWc5z74ruwG8nvm0k7zwSBk05YKMBa VbHVWAywV8/xC88OmnNnOEotzKHHYkgqcNc8Or3yYHXoLZclpt5o37/bvGaDmtMwjbIL Qb9g==
X-Received: by with SMTP id cr1mr7098414igb.35.1437472270495; Tue, 21 Jul 2015 02:51:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Jul 2015 02:50:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Mark Smith <>
Date: Tue, 21 Jul 2015 19:50:40 +1000
Message-ID: <>
To: Lorenzo Colitti <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: v6ops list <>, "" <>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2015 09:51:12 -0000

On 21 July 2015 at 19:35, Lorenzo Colitti <> wrote:
> On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <> wrote:
>> But in terms of implementation, isn't it simpler to always(*) respond to a
>> RS with a unicast RA?
> It would be simpler to document, yes, but I don't know that we should make a
> one-size-fits all recommendation, because there might be link types or
> environments where this is more expensive.
>> As background, the text in RFC4861 comes from the old concern that all
>> devices might boot at the same time when the power is re-established after a
>> building power failure; that doesn't happen since most devices (laptops,
>> smartphones, IoT devices) have batteries today. In that case it might have
>> made sense to sending fewer RA messages by using multicast.
> This sort of thing can still happen. If lots of devices join at once, (e.g.,
> if something happens at a large-scale event when hundreds of people pull
> their phones out of their pockets and turn them on at the same time), it may
> well be cheaper for the network to send one multicast RA.

Actually I've witnessed these sorts of events in recent times - when
1000s or 10s of 1000s of residential broadband subscribers come back
on-line after the BRAS/BNG has booted either due to failure or
maintenance, or the backhaul infrastructure between the BRAS/BNG and
subscribers has failed and recovered.

Unicast RAs in the specific scenarios I've seen it in though may not
have helped, as the subscribers were attached via individual PPPoE
sessions, so multicasting a single RA to many/all of them efficiently
might not be possible, unless there was some fancy hardware/firmware
that meant the control plane didn't have to do it.

However, if single link/multi-access methods of attaching subscribers
are used e.g., TR-101 N:1 VLAN, then solicited multicast RAs would
help significantly reduce the number of multicast RSes from CPE during
these events.

> I'm not opposed to changing the standards as well, but I think respinning
> RFC 4861 would require much more careful consideration than simply
> publishing an operational guidance document such as this one. Perhaps we can
> just recommend in this document that 6man consider this operational need and
> consider modifying the protocol?