[Roll] Fwd: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)

Yusuke DOI <yusuke.doi@toshiba.co.jp> Thu, 20 March 2014 01:07 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 640C01A0866 for <roll@ietfa.amsl.com>; Wed, 19 Mar 2014 18:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level:
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 LTK6YyilDbho for <roll@ietfa.amsl.com>; Wed, 19 Mar 2014 18:07:49 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 95FDB1A0869 for <roll@ietf.org>; Wed, 19 Mar 2014 18:07:48 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s2K17dcg020190 for <roll@ietf.org>; Thu, 20 Mar 2014 10:07:39 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id s2K17dBL006187 for roll@ietf.org; Thu, 20 Mar 2014 10:07:39 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA06185; Thu, 20 Mar 2014 10:07:39 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s2K17cmx011552 for <roll@ietf.org>; Thu, 20 Mar 2014 10:07:38 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s2K17cJh002408; Thu, 20 Mar 2014 10:07:38 +0900 (JST)
Received: from [133.196.16.135] (ncg-dhcp135.isl.rdc.toshiba.co.jp [133.196.16.135]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 95C4B97D18 for <roll@ietf.org>; Thu, 20 Mar 2014 10:07:38 +0900 (JST)
Message-ID: <532A3F5A.6030603@toshiba.co.jp>
Date: Thu, 20 Mar 2014 10:07:38 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: roll@ietf.org
References: <53253658.8010700@toshiba.co.jp> <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
In-Reply-To: <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
X-Forwarded-Message-Id: <53253658.8010700@toshiba.co.jp> <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
Content-Type: multipart/mixed; boundary="------------010905070002060309050907"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6BRC1q6Sv2XSHZAKe2TiBiTtwEk
Subject: [Roll] Fwd: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
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: <http://www.ietf.org/mail-archive/web/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: Thu, 20 Mar 2014 01:07:55 -0000

Hi,

Let me inform you there was a comment on my draft from Matthew Ryan. I will cross-post if any further discussion occurs.

Regards,

Yusuke
--- Begin Message ---
Matt,

Thank you very much for your comment.

(2014-03-15 03:05), Matthew Ryan wrote:
> Having an optional fragment at the head of an option will
> likely require custom code specific to this option in anything
> that has to read or write it (as opposed to just relaying
> it) and may be an impediment to adoption.  See section 6 of
> draft-ietf-dhc-option-guidelines.
>
> Since the only difference between the two forms is whether
> the address is present or not, you should place the address
> at the end of the option, and mark it as optional, as suggested
> by section 5 of the option guidelines draft.
>
> Note that, regardless of whether you place the address at the
> front of the option or the end of the option, you will not
> be able to count on any particular alignment of the address,
> or anything else, since there are no alignment guarantees
> in the protocol (section 19 of the option guidelines draft).

Sorry for confusion. The format I sent in the e-mail is what I tried to avoid some non-octet fields (P, C_K, DM_K). The version became awkward and I dropped the idea.

The submitted version follows the guideline. The format is as follows:

   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    OPTION_MPL_PARAMETERS      |          option_len           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |P| Z |   C_K   | Z2  |  DM_K   |         SE_LIFETIME           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         DM_IMIN               |          DM_IMAX              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         DM_T_EXP              |          C_IMIN               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         C_IMAX                |          C_T_EXP              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    (if option_len = 32 )
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          MPL Domain Address  (128bits)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          (cont'ed)                                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          (cont'ed)                                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          (cont'ed)                                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The draft also defines unsigned short floating point (section 2.1) for the timers. There are some reasons to define a new type:

1) Timers could be very short (*_IMIN in 10 ms.) or long (SE_LIFETIME may be in weeks)
2) Linear precision is not needed (There are no reason to say 1 week and 10ms.)
3) Packet should be short enough
4) Timer is unsigned and should be base-10 (not base-2)

An unsigned short floating point:

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | exp.|      significand        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timer values are significand * 10**exp in millisecond unit.

If you know similar value type already used in DHCPv6, please let me know.

Regards,

Yusuke




--- End Message ---
--- Begin Message ---
Having an optional fragment at the head of an option will
likely require custom code specific to this option in anything
that has to read or write it (as opposed to just relaying
it) and may be an impediment to adoption.  See section 6 of
draft-ietf-dhc-option-guidelines.

Since the only difference between the two forms is whether
the address is present or not, you should place the address
at the end of the option, and mark it as optional, as suggested
by section 5 of the option guidelines draft.

Note that, regardless of whether you place the address at the
front of the option or the end of the option, you will not
be able to count on any particular alignment of the address,
or anything else, since there are no alignment guarantees
in the protocol (section 19 of the option guidelines draft).

 - Matt

Ref: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-17


On Mar 13, 2014, at 5:03 PM, Yusuke DOI <yusuke.doi@toshiba.co.jp> wrote:

> Dear DHC folks,
> 
> I'm proposing an DHCPv6 option for configuration of MPL parameters that are (typically) used in wireless mesh networks.
> 
> The I-D is just adopted as roll WG draft. May I ask the dhc wg (again) to take a look on it?
> 
> I need to apologize I failed to follow a Bernie's suggestion given at last August.
> 
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg14587.html
> 
>> 2. While it may cost a few octets, I would strongly encourage you to
>> use separate fields for some items (such as C_K and DM_K). This will
>> cost you one octet but keeps the encoding simpler (flags, C_K, and
>> DM_K octets).
> 
> I tried to follow the comment, and at the same time, I think it should be aligned with word boundary, *and*, it should be compact as possible because it's intended to be used in wireless mesh networks (I feel too nervous if I waste 24 bits of all of the DHCP responses on the all mesh networks of ours). This results following awkward format. I personally think it is even more simple to make some bitmasking (and we are get used to it) than the following optlen={17|33} format. Currently, the proposal is still in the previous format with some 5-bit field and a bit for a flag.
> 
> [the format to have independent C_K/DM_K octet -- *not* included in the I-D]
> 
>    (if option_len = 17 )
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    OPTION_MPL_PARAMETERS      |          option_len           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         DM_IMIN               |          DM_IMAX              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         DM_T_EXP              |          C_IMIN               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         C_IMAX                |          C_T_EXP              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         SE_LIFETIME           |    FLAGS      |    C_K        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      DM_K     |
>    +-+-+-+-+-+-+-+-+
> 
>    (if option_len = 33 )
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    OPTION_MPL_PARAMETERS      |          option_len           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          MPL Domain Address  (128bits)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          (cont'ed)                                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          (cont'ed)                                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          (cont'ed)                                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         DM_IMIN               |          DM_IMAX              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         DM_T_EXP              |          C_IMIN               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         C_IMAX                |          C_T_EXP              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         SE_LIFETIME           |    FLAGS      |    C_K        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      DM_K     |
>    +-+-+-+-+-+-+-+-+
> 
> 
> Thanks,
> 
> Yusuke
> 
> 
> -------- Original Message --------
> Subject: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt
> Date: Thu, 13 Mar 2014 07:39:42 -0700
> From: internet-drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> CC: roll@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.
> 
>        Title           : MPL Parameter Configuration Option for DHCPv6
>        Authors         : Yusuke Doi
>                          Matthew Gillmore
> 	Filename        : draft-ietf-roll-mpl-parameter-configuration-00.txt
> 	Pages           : 9
> 	Date            : 2014-03-13
> 
> Abstract:
>   This draft defines a way to configure MPL parameter set via DHCPv6
>   option.  MPL has a set of parameters to control its behavior, and the
>   parameter set is often configured as a network-wide parameter because
>   the parameter set should be identical for each MPL forwarder in an
>   MPL domain.  Using the MPL Parameter Configuration Option defined in
>   this document, a network can be configured with a single set of MPL
>   parameter easily.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

--- End Message ---