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

From: Yusuke DOI <[email-masked]>
Date: Thu, 20 Mar 2014 10:07:38 +0900

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

Subject: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
From: Yusuke DOI <[email-masked]>
To: Matthew Ryan <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sun, 16 Mar 2014 14:27:52 +0900

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

Subject: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
From: Matthew Ryan <[email-masked]>
To: Yusuke DOI <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 14 Mar 2014 11:05:16 -0700

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 <[email-masked]> 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: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> 
> 
> 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
> [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ines Robles <[email-masked]>
Date: Wed, 19 Mar 2014 22:22:53 -0300

Thank you Yusuke for keeping us posted.

Kind Regards,

2014-03-19 22:07 GMT-03:00 Yusuke DOI <[email-masked]>:

> 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
>
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>