Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)

Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 08 July 2015 23:26 UTC

Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A6D1A1ABB; Wed, 8 Jul 2015 16:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.859
X-Spam-Level:
X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] 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 80mKzn1r3j2H; Wed, 8 Jul 2015 16:26:04 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053271A1AB9; Wed, 8 Jul 2015 16:25:57 -0700 (PDT)
Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t68NPumW026490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:25:56 +0900 (JST)
Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtEL006762; Thu, 9 Jul 2015 08:25:55 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 887; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtUd006759; Thu, 9 Jul 2015 08:25:55 +0900
Received: (from root@localhost) by arc11.toshiba.co.jp id t68NPt5U024470; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA24469; Thu, 9 Jul 2015 08:25:55 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t68NPtX6025535; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NPtXY005611; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id D4D4218F4B6; Thu, 9 Jul 2015 08:25:53 +0900 (JST)
Message-ID: <559D3EE0.4000904@toshiba.co.jp>
Date: Thu, 09 Jul 2015 00:16:48 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <20150708080446.7700.80046.idtracker@ietfa.amsl.com>
In-Reply-To: <20150708080446.7700.80046.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/gPRBrWxampwh5UsOKZiOmdD1A0o>
Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org
Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2015 23:26:07 -0000

Hi Stephen,

Thank you very much for the review.

On 2015-07-08 17:04, Stephen Farrell wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - I don't get the update model - if all MPL forwarders have
> to use the same parameters but they don't all do DHCPv6 at
> the same time, then won't new parameter settings take a
> while to propagate to most of the network? And won't that
> cause a problem? Don't you need a "start using this set of
> parameters in N seconds" field in the dhcp option to handle
> that? This is not a DISCUSS as I think it relats to Barry's
> so please try address this when addressing that.

I believe your question is beyond Barry's DISCUSS. Let me clarify it here.

In general, all MPL Forwarders should have identical parameters to make 
a better load balance. However, the parameter synchronization is 'better 
to have' and even if there are mismatched parameter set it does not 
break interoperability or operation. Some forwarders would do more 
retransmission than others if the parameter is not identical. I consider 
this is acceptable behavior for MPL. To ease the unbalanced 
retransmission, I added some text to limit parameter update ratio per 
information refresh time.

For join and leave on forwarders, some node may not be able to receive 
messages during transitive period (not all forwarders have joined). 
However, adding some delay on the configuration will not ease the case. 
It's up to application to send a multicast message after all nodes have 
acquired the newest configuration, or to send a message during 
constructing MPL domain if the message is good even for delivered to a 
fraction of nodes.

> - please do not pretend rfc 3315 is a solution for anything
> unless you mean it and I don't think you do. 3315 is I think
> the canonical example for mythical security:-(

To be honest, my situation is to go without DHCPv6 security and expects 
network-level security. We do strict node admission using RFC5191 and 
assumes no untrusted node in a network.

I'm wondering how would I describe security consideration beyond my 
situation in the document, without relying on 3315. I appreciate if you 
give me some suggestion on this topic.

Thanks,

Yusuke