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

Tore Anderson <tore@fud.no> Tue, 07 July 2015 14:55 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F21ACD25 for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 07:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 0A91Oj9uj9qS for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 07:55:56 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8501AC41C for <v6ops@ietf.org>; Tue, 7 Jul 2015 07:55:56 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=57855 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1ZCUHo-0006ep-ER; Tue, 07 Jul 2015 16:55:52 +0200
Date: Tue, 7 Jul 2015 16:55:51 +0200
From: Tore Anderson <tore@fud.no>
To: v6ops@ietf.org
Message-ID: <20150707165551.6b90a7a3@envy.fud.no>
In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com>
References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BygY_m-XenaRPFR5xkNs82YEnpc>
Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 14:55:58 -0000

* fred@cisco.com

> A new draft has been posted, at
> http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast.
> Please take a look at it and comment.

Support WG adoption.

Comments:

1) Nit: Abstract: s/network/networks/ (Or so I think. I'm not a native
speaker.)

2) Section 2, second bullet: Would like to add that the lost
connectivity (due to default route expiring) persists after the device
has woken back up again. This is another big reason for a network
operator to send RAs frequently, to ensure that a device re-gains its
connectivity as soon as the user starts interacting with his device.
Furthermore, a reference to draft-ietf-6man-rs-refresh might be prudent
here.	

3) Section 3: Did you consider recommending making unicast the default
behaviour for solicited RAs on all networks, not just the ones with
sleepy devices? I was thinking about it for a while and I couldn't
immediately see any big issue with that, but I might be missing
something. If the recommended approach isn't also suitable for, say, an
enterprise wired LAN with desktop PCs, or a data centre server LAN,
maybe include some text describing why not?

4) Section 3: I think that for a complete solution you should also
recommend that hosts MUST not ignore multicast RAs when they're
sleeping. Otherwise, you're missing a big part of the solution - the
hosts I discussed in #2 still lost their connectivity while sleeping
and after waking back up, and the way to combat that would still be for
the network to send unsolicited (multicast) RAs frequently.

Tore