Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)

Yusuke DOI <> Tue, 08 July 2014 09:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D50A1B27A8; Tue, 8 Jul 2014 02:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IiWnxEdz02-Q; Tue, 8 Jul 2014 02:14:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B73011B27A3; Tue, 8 Jul 2014 02:14:03 -0700 (PDT)
Received: from ([]) by with ESMTP id s689E2af002095; Tue, 8 Jul 2014 18:14:02 +0900 (JST)
Received: (from root@localhost) by id s689E2us020337; Tue, 8 Jul 2014 18:14:02 +0900 (JST)
Received: from [] by with ESMTP id UAA20336; Tue, 8 Jul 2014 18:14:02 +0900
Received: from (localhost []) by with ESMTP id s689E1tH017473; Tue, 8 Jul 2014 18:14:01 +0900 (JST)
Received: from by id s689CvWS005136; Tue, 8 Jul 2014 18:12:57 +0900 (JST)
Received: from by id s689AuBT012979; Tue, 8 Jul 2014 18:10:56 +0900 (JST)
Received: from [] ( []) by (Postfix) with ESMTPS id C810397D24; Tue, 8 Jul 2014 18:10:56 +0900 (JST)
Message-ID: <>
Date: Tue, 08 Jul 2014 16:55:27 +0900
From: Yusuke DOI <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andre Kostur <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jul 2014 09:14:05 -0000

Hi Andre,

Thank you for the comments.

I think I need to explain background more.

1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops.
I think a compact option format is more suitable for the case.

2) A parameter set is bound for an MPL domain. A network may have
multiple MPL domains. I think it is much simpler to handle all
parameters as a set.

(2014-07-08 01:32), Andre Kostur wrote:
> A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for
> Creating New DHCPv6 Options):
> - An encoded option is frowned upon.  Split all of those into separate
> options, and the "Reserved" parts simply disappear.  A "sub-optioned"
> option is also frowned upon (section 9, RFC 7227).

As described above, the parameters are considered as a set. I could not
find recommended design for parameter sets. More than one parameter set
will be configured. To make them separated I think each option should be
with MPL domain (= IPv6 address).

> - Why add the additional complexity of the floating point?   Why not
> use a 32-bit unsigned integer representing milliseconds which gets you
> a little over 40 days?  Not the 18 weeks that you currently can
> represent, but is there a practical use for timers over a month long
> in MPL?

The motivation behind the floating point is to reduce message length as
much as possible. As MPL has 7 timers, it will reduce 14 bytes. Though,
usually 40 days should be enough and this is just a tradeoff (I'm not
insisting on the floating point format).

> - If you do go with separate options, consider what it would mean if
> certain options don't exist.  ietf-roll-trickle-mcast appears to
> define defaults, perhaps reference that draft to say that if an option
> is missing, the client is to use the default defined in that draft?

If the draft goes with separate options, I agree it should be the
default values.

> - Speaking of RFC 7227...  I-D.ietf-dhc-option-guidelines got published in May

Thank you.