Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt

From: [email-masked]
Date: Tue, 01 Jul 2014 08:58:03 -0700

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-01.txt
	Pages           : 9
	Date            : 2014-07-01

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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-01

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/

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 07 Jul 2014 21:30:17 +0900

Hi,

I've updated the proposal to control MPL parameter over DHCPv6 option.

I believe this feature is required to use MPL over mesh networks in the wild, e.g. long-standing smart meter network etc. This proposal is a short one and I appreciate your review.

Thanks!

Yusuke

---

From: Andre Kostur <[email-masked]>
Date: Mon, 7 Jul 2014 09:32:25 -0700

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).
- 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?
- 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?
- Speaking of RFC 7227...  I-D.ietf-dhc-option-guidelines got published in May

-- 
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2014 17:19:11 +0000

Hi:

Not sure I'd suggest adding 10 (or 11) options for this?

But I certainly would suggest, as Andre did, much simpler values - flags and "compressed" data just make for much more complex and error prone processing on both client and server. A structure which would have all these values but in a much more standard set of data formats would be better.

Perhaps there is a middle grown to have groups of values (i.e., have 3-4 options)? I'm really not that familiar with MPL, but perhaps there are some logical groupings that make sense (seems that there are data and control messages would could be one logical separation).

Might also be nice in the Abstract to define MPL? 

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Andre Kostur
Sent: Monday, July 07, 2014 12:32 PM
To: Yusuke DOI
Cc: [email-masked]; Routing Over Low power and Lossy networks
Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)

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).
- 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?
- 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?
- Speaking of RFC 7227...  I-D.ietf-dhc-option-guidelines got published in May

--
Andre Kostur

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Yusuke DOI <[email-masked]>
Date: Tue, 08 Jul 2014 16:56:43 +0900

Hi Bernie, Thank you for comments,

(2014-07-08 2:19), Bernie Volz (volz) wrote:
> But I certainly would suggest, as Andre did, much simpler values -
> flags and "compressed" data just make for much more complex and
> error prone processing on both client and server. A structure which
> would have all these values but in a much more standard set of data
> formats would be better.

-2 for compressed data. I'd like to make 'uncompressed' version and
check if it's acceptable for roll-ish network.

> Perhaps there is a middle grown to have groups of values (i.e., have
> 3-4 options)? I'm really not that familiar with MPL, but perhaps
> there are some logical groupings that make sense (seems that there
> are data and control messages would could be one logical
> separation).

Ah, so your suggestion is to have (for example) three options?:

1) MPL Base configuration
    (P, SE_LIFETIME, {MPL Domain})
2) MPL Control channel configuration
    (C_K, C_MIN, C_MAX, C_T_EXP, {MPL Domain})
3) MPL Data channel configuration
    (D_K, D_MIN, D_MAX, D_T_EXI, {MPL Domain})

For me, duplication of MPL domain (128bit address x 3) seems to be wasteful.

> Might also be nice in the Abstract to define MPL?

Thanks, I'll add a definition.

Yusuke

---

From: Yusuke DOI <[email-masked]>
Date: Tue, 08 Jul 2014 16:55:27 +0900

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.

> 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).

> represent, but is there a practical use for timers over a month long

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).

> 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.

Yusuke

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2014 20:59:08 +0000

Hi:

I don't have a great answer for you as I have no idea what the typical usages are likely to be. If there are likely to be many instances and the desire to configure most of the values (and for multiple domains), then one single option for each domain with all of the values is certainly a better idea.

I think the main points here are to:
- avoid compressing the data / developing new data types and use more standard elements (i.e., 16 or 32-bit integers) - see RFC 7227.
- group things logically (i.e., alignment of the data, while making the picture easier to draw, is not a requirement [of course we assume it is octet (byte) aligned]).

There are many ways to format this data, each with pros and cons. Making those tradeoffs is something I am not in a good position to help you with.

- Bernie

-----Original Message-----
From: Yusuke DOI [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2014 3:57 AM
To: Bernie Volz (volz); Andre Kostur
Cc: [email-masked]; Routing Over Low power and Lossy networks
Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)

(2014-07-08 2:19), Bernie Volz (volz) wrote:
> flags and "compressed" data just make for much more complex and error 
> prone processing on both client and server. A structure which would 
> have all these values but in a much more standard set of data formats 
> would be better.

-2 for compressed data. I'd like to make 'uncompressed' version and check if it's acceptable for roll-ish network.

> 3-4 options)? I'm really not that familiar with MPL, but perhaps there 
> are some logical groupings that make sense (seems that there are data 
> and control messages would could be one logical separation).

Yusuke

---

From: Yusuke DOI <[email-masked]>
Date: Thu, 10 Jul 2014 14:17:28 +0900

Hi Bernie,

(2014-07-09 5:59), Bernie Volz (volz) wrote:
> Hi:
>
> I don't have a great answer for you as I have no idea what the
> typical usages are likely to be. If there are likely to be many
> instances and the desire to configure most of the values (and for
> multiple domains), then one single option for each domain with all
> of the values is certainly a better idea.

Thanks, I'll add some note to describe expected use case. The options
are likely to be used as a set and I think open single option is easier
to implement.

> I think the main points here are to: - avoid compressing the data /
> developing new data types and use more standard elements (i.e., 16
> or 32-bit integers) - see RFC 7227. - group things logically (i.e.,
> alignment of the data, while making the picture easier to draw, is
> not a requirement [of course we assume it is octet (byte) aligned]).

I agree. In addition, I noticed 8bit common exponent (in other words, 
unit time of timers) for all timers will be much much simpler.

> There are many ways to format this data, each with pros and cons.
> Making those tradeoffs is something I am not in a good position to
> help you with.

Your comments are very helpful for me, thanks!

Regards,

Yusuke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Jul 2014 16:48:57 -0400

> I think a compact option format is more suitable for the case.

This doesn't sound like something you'd configure with DHCP.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 12 Jul 2014 08:36:56 -0400

> This doesn't sound like something you'd configure with DHCP.

Ted - what does "this" refer to?  MPL in general?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Jul 2014 12:31:50 -0400

> Ted - what does "this" refer to?  MPL in general?

Using DHCP to push a big chunk of information about the state of a mesh network seems like a suboptimal approach.   The fact that compression is desired suggests that you are using the wrong tool for the job.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jul 2014 16:27:44 -0400

> Using DHCP to push a big chunk of information about the state of a mesh
    > network seems like a suboptimal approach.  The fact that compression is
    > desired suggests that you are using the wrong tool for the job.

It's not state about the network, it's configuration parameters about the
(multicast) routing protocol.   Ideally, the parameters need to be the same
across the mesh (but we have validated that mismatches in certain directions
and within certain tolerances are acceptable; usually causing excess energy
use, rather than network in-operation),  but over time the operator will want
to tune the parameters to optimize energy.

As such we need a protocol that assigns lifetimes to parameters and
facilitates expiring old values.  DHCP seems ideal for this; it's also not
RPL specific, as MPL is not tied to RPL.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Ted Lemon <[email-masked]>
Date: Sat, 19 Jul 2014 17:20:44 -0400

Okay, thanks.   I think compressing is saving three bytes; this is noise.   Please don't do that.   We need to define a fragment type for unsigned short floating point; that should be a quick, simple DHCP document.   The rest of the document looks fine at first glance, but as you've no doubt detected, I didn't read it before asking about the previous thing and I still haven't read it closely, so don't take that as a claim that I won't comment further later when I have more time (whenever that magic day comes).

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 21 Jul 2014 04:24:19 +0900

Hi Ted,

Thanks for your suggestion. As I wrote to Bernie, I'll update the draft
with standard data types.

Regards,

Yusuke

(2014-07-20 6:20), Ted Lemon wrote:
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 21 Jul 2014 19:48:33 +0900

Hi,

With valuable inputs from DHC working group, I updated the format and 
removed the tricky short float values.

----

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-02.txt
	Pages           : 9
	Date            : 2014-07-21

Abstract:
    This draft defines a way to configure a parameter set of MPL
    (Multicast Protocol for Low power and Lossy Networks) 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.

----

Thanks,

Yusuke