Re: [Roll] [roll] #159 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Format to encode timers

["roll issue tracker" <[e-mail]>]

#159: mpl-parameter-configuration-00 - Format to encode timers


Comment (by [e-mail]):

 Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08609.html]


 To: Matthew Ryan <Matt.Ryan at nominum.com>


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


 From: Yusuke DOI <yusuke.doi at toshiba.co.jp>


 Date: Sun, 16 Mar 2014 14:27:52 +0900




 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:

   [Go to Source]

 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:

  [Go to Source]


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


 To: Yusuke DOI <yusuke.doi at toshiba.co.jp>


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


 From: Matthew Ryan <Matt.Ryan at nominum.com>


 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 <yusuke.doi at 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 )
 >
 >    [Go to Source]

 >
 >
 > Thanks,
 >
 > Yusuke
 >

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [e-mail]          |  [e-mail]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  draft-doi-roll-mpl-      |     Version:
  parameter-configuration            |  Resolution:
 Severity:  Active WG Document       |
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/159#comment:1>
roll <http://tools.ietf.org/wg/roll/>