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

Matthew Ryan <Matt.Ryan@nominum.com> Fri, 14 March 2014 18:05 UTC

Return-Path: <Matt.Ryan@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6818A1A01C0 for <dhcwg@ietfa.amsl.com>; Fri, 14 Mar 2014 11:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 L-kBJgMTfgD5 for <dhcwg@ietfa.amsl.com>; Fri, 14 Mar 2014 11:05:30 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7331A01AF for <dhcwg@ietf.org>; Fri, 14 Mar 2014 11:05:30 -0700 (PDT)
Received: from newvir.ddns.nominum.com (newvir.ddns.nominum.com [64.89.225.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 36B691B8049; Fri, 14 Mar 2014 11:05:23 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Matthew Ryan <Matt.Ryan@nominum.com>
In-Reply-To: <53224737.7090109@toshiba.co.jp>
Date: Fri, 14 Mar 2014 11:05:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
References: <20140313143942.7850.75117.idtracker@ietfa.amsl.com> <53224737.7090109@toshiba.co.jp>
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Y4gZUd9IfQ4NDUbZjorHcawhqaI
Cc: dhcwg@ietf.org, Matthew.Gillmore@itron.com
Subject: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 18:05:32 -0000

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