Subject: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 16 Jun 2015 00:31:42 +0000

Hi!

I just finished reading this document.

I think the document is almost ready to move forward — I have one major comment (below) related to sending the Option as it relates to the potential of mismatched options.  I am going to start the IETF Last Call, but expect at least a discussion about that comment before putting the draft in front of the IESG.

Thanks!

Alvaro.

Major:

  1.  Sending this Option.  It is "RECOMMENDED that all MPL Interfaces attached to the same link of a given MPL Domain use the same values for the Trickle Parameters” (I’m quoting draft-ietf-roll-trickle-mcast because it is not a MUST, even though rfc6206 talks about “unintended behaviors”).   This document says  (Section 2.4) that "the server will send MPL Parameter Configuration Option only if configured…and the client requested it”..and (Section 2.2) says that a client "MAY request MPL Parameter Configuration Option”.  In summary, the server won’t send the Option unless the client requests it; is that what is intended?  Furthermore, the request is optional (I’m assuming there may be resource considerations here), so there may be cases in which not all clients request the Option, resulting in potentially mismatched parameters.  Am I interpreting the text correctly?  If so, why was it specified this way (instead of having the server send the Option (when configured for a specific MPL Domain) always?  Does the client then require configuration to be able to request the additional configuration parameters?
     *   I don’t necessarily want to change the behavior proposed, as I’m assuming it has been discussed in the WG and there are good reasons behind it.
     *   Instead, I would like to see some discussion about it  in the Operational Considerations section.  Pointing to rfc6206 may be enough to remind people who are implementing this Option.
     *   Related to this point: I recommend moving the discussion in Appendix B to the Operational Considerations section.

Minor:

  1.  Section 1 (Introduction): "Some managed wireless mesh networks may have a DHCP server to configure network parameters.”  How common is the use of DHCP?  “Some..may” doesn’t sound like this extension will be used a lot.  How do other networks configure their parameters?  I’m assuming manually..
  2.  Section 2.1. (MPL Parameter Configuration Option Format).  The descriptions of the fields need to be very specific, specially if invalid contents are to be discarded (per 2.2 and rfc7227).
     *   When is P set?  It may be obvious that it is set when PROACTIVE_FORWARDING is TRUE, but please specify it.
     *   TUNIT: "Unit time of times”, what does that mean?
     *   DM_T_EXP/C_T_EXP: DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIONS are defined as the number of expirations, so how do you end with ms?
     *   The "MPL Domain Address” field is not defined.
  3.  Section 2.3 (MPL Forwarder Behavior)  Joining and leaving the domain.  I must be missing something..
     *   "the node MAY join the MPL domain given by the option”  Why would the client request the Option and then not join the domain?
     *   "A node MAY leave from an MPL domain..”  The conditions seem to say that the domain in the Option changed, is that true?  If the domain in the option changed, why would the node not leave the domain?
  4.  Section 4. (Security Considerations)  Please include references and comments (where needed) to the security considerations in rfc3315 and rfc7227.

Nits:

  1.  The word “draft” is used in a couple of places to refer to this document and MPL; use “document” instead.
  2.  Section 2 (MPL Parameter Configuration Option) s/there are following 10 parameters/there are the following 10 parameters
  3.  2.5. (DHCPv6 Relay Behavior).  A reference to rfc6422 would be nice.
  4.  Section 2.6. (Operational Considerations) "A parameter set for an MPL domain SHOULD NOT be updated more often than two times of expected refresh interval.”  I’m assuming that the “expected refresh interval” is Information Refresh Time, right?  If so, please call it what it is.
  5.  I would consider rfc7227 a Normative Reference.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jun 2015 09:35:07 -0400

> I think the document is almost ready to move forward — I have one
    > major comment (below) related to sending the Option as it relates to
    > the potential of mismatched options. I am going to start the IETF Last
    > Call, but expect at least a discussion about that comment before
    > putting the draft in front of the IESG.

Do you mean, if different parts of the network have different parameters?
I had that same question, and I asked it here:
  https://tools.ietf.org/wg/roll/trac/ticket/157

    > rfc6206 talks about “unintended behaviors”). This document says
    > (Section 2.4) that "the server will send MPL Parameter Configuration
    > Option only if configured…and the client requested it”..and (Section
    > 2.2) says that a client "MAY request MPL Parameter Configuration
    > Option”. In summary, the server won’t send the Option unless the
    > client requests it; is that what is intended? Furthermore, the
    > request is optional (I’m assuming there may be resource
    > considerations here), so there may be cases in which not all clients
    > request the Option, resulting in potentially mismatched parameters.

Clients that don't ask for the option probably don't support it....

    > Am I interpreting the text correctly? If so, why was it specified
    > this way (instead of having the server send the Option (when
    > configured for a specific MPL Domain) always? Does the client then
    > require configuration to be able to request the additional
    > configuration parameters?

That's mostly how DHCPv6 works.  The client sends a list of options it
cares about, and the server answers them.  That seems the right thing to
do with constrained nodes on a challenged network.

    > * Instead, I would like to see some discussion about it in the
    > Operational Considerations section. Pointing to rfc6206 may be
    > enough to remind people who are implementing this Option.
    > * Related to this point: I recommend moving the discussion in
    > Appendix B to the Operational Considerations section.

okay.

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

---

From: Yusuke DOI <[email-masked]>
Date: Thu, 18 Jun 2015 01:43:25 +0900

Hi Alvaro,

Thank you for the review,

(Chairs, it's first time to go throught the process for me.
  Shall I update the document accordingly as soon as possible?
  or shall I wait for further discussion?)

On 2015-06-16 9:31, Alvaro Retana (aretana) wrote:
> Major:
>
>  1. Sending this Option.  It is "RECOMMENDED that all MPL Interfaces
>     attached to the same link of a given MPL Domain use the same values
>     for the Trickle Parameters” (I’m quoting
>     draft-ietf-roll-trickle-mcast because it is not a MUST, even though
>       (Section 2.4) that "the server will send MPL Parameter
>     Configuration Option only if configured…and the client requested
>     it”..and (Section 2.2) says that a client "MAY request MPL Parameter
>     Configuration Option”.  In summary, the server won’t send the Option
>     unless the client requests it; is that what is intended?
>       Furthermore, the request is optional (I’m assuming there may be
>     resource considerations here), so there may be cases in which not
>     all clients request the Option, resulting in potentially mismatched
>     parameters.  Am I interpreting the text correctly?  If so, why was
>     it specified this way (instead of having the server send the Option
>     (when configured for a specific MPL Domain) always?  Does the client
>     then require configuration to be able to request the additional
>       * I don’t necessarily want to change the behavior proposed, as I’m
>         assuming it has been discussed in the WG and there are good
>         reasons behind it.

As Michael stated, I think this is normal behavior and intended behavior.

'unintended behaviors' are mostly unbalanced (unfair) data relay or loss 
of message. I think the reason is not critical enough to mandate the option.

> Minor:
>
>  1. Section 1 (Introduction): "Some managed wireless mesh networks may
>     have a DHCP server to configure network parameters.”  How common is
>     the use of DHCP?  “Some..may” doesn’t sound like this extension will
>     be used a lot.  How do other networks configure their parameters?
>       I’m assuming manually..

I have no other experience, but I assume the configuration will be done 
manually...

>  2. Section 2.1. (MPL Parameter Configuration Option Format).  The
>     descriptions of the fields need to be very specific, specially if
>     invalid contents are to be discarded (per 2.2 and rfc7227).
>       * When is P set?  It may be obvious that it is set
>         when PROACTIVE_FORWARDING is TRUE, but please specify it.
>       * DM_T_EXP/C_T_EXP:
>         DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIONS
>         are defined as the number of expirations, so how do you end with ms?

Thanks, I'll fix them. *_EXP are mistakes. It should be just integers as 
defined in MPL.

>       * "the node MAY join the MPL domain given by the option”  Why
>         would the client request the Option and then not join the domain?

One reason is resource constraint. As joining to a MPL domain requires 
certain amount of buffers allocated, a node may fail to join all of the 
domains given by the option.

>       * "A node MAY leave from an MPL domain..”  The conditions seem to
>         say that the domain in the Option changed, is that true?  If the
>         domain in the option changed, why would the node not leave the
>         domain?

There's no reason except the domain is configured manually at the same 
time (the first condition is not met). If there are a manual 
configuration, implementation may consider it's overriding the DHCPv6 
Option.

Is this clear?:

"""
A node SHOULD leave from a MPL domain if the node received a new option 
without configuration for the MPL domain, unless it has overriding 
external configuration on the MPL domain.
"""

>  4. Section 4. (Security Considerations)  Please include references and
>     comments (where needed) to the security considerations in rfc3315
>     and rfc7227.

Thanks. I'll add this.

> Nits:
>
>  1. The word “draft” is used in a couple of places to refer to this
>     document and MPL; use “document” instead.
>  2. Section 2 (MPL Parameter Configuration Option) s/there are following
>     10 parameters/there are the following 10 parameters
>  4. Section 2.6. (Operational Considerations) "A parameter set for an
>     MPL domain SHOULD NOT be updated more often than two times of
>     expected refresh interval.”  I’m assuming that the “expected refresh
>     interval” is Information Refresh Time, right?  If so, please call it
>     what it is.

Thanks for pointing it out.

Best Regards,

Yusuke

---

From: Ines Robles <[email-masked]>
Date: Wed, 17 Jun 2015 23:01:09 +0300

Hi Yusuke,
you could update the document in a couple of days.
Thank you very much
On 17 Jun 2015 19:44, "Yusuke DOI" <[email-masked]> wrote:

> time (the first condition is not met). If there are a manual configuration,
> implementation may consider it's overriding the DHCPv6 Option.
>
> Is this clear?:
>
> """
> without configuration for the MPL domain, unless it has overriding external
> configuration on the MPL domain.
> """
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 18 Jun 2015 16:49:17 +0000

On 6/17/15, 1:43 PM, "Yusuke DOI" <[email-masked]> wrote:

Yusuke:

Hi!

. . .
>>     have a DHCP server to configure network parameters.²  How common is
>>     the use of DHCP?  ³Some..may² doesn¹t sound like this extension will
>>       I¹m assuming manually..
. . .
>>       * "the node MAY join the MPL domain given by the option²  Why

The use of ³MAY² above gives the impression that joining is optional.  But
you¹re saying that even if the node wants to join it may not be able to,
which is different.

Suggestion:

OLD>

   If a DHCPv6 client requests and receives MPL Parameter Configuration
   Option, the node MAY join the MPL domain given by the option and act
   as an MPL forwarder.

NEW>

   If a DHCPv6 client requests and receives MPL Parameter Configuration
   Option, the node SHOULD join the MPL domain given by the option and act
   as an MPL forwarder.  Note that there may be cases in which a node may
   fail is to join a domain (or domains) due to local resource constraints.

I¹m not sure if you/the WG want to add something else to that paragraph..

>>       * "A node MAY leave from an MPL domain..²  The conditions seem to

How about this instead:

NEW>

   A node SHOULD leave an MPL domain if it receives an updated
   MPL Parameter Configuration Option without a configuration for the
   MPL domain, unless it has overriding external configuration.

I¹m not sure if ³external² is the right word..or if ³manual² might be
better.  Look at the point #1 above about how other nodes may be
configured.

In this section (2.3) there¹s a priority of configuration shown:

   The priority of MPL Parameter Configuration applied for an MPL Domain
   is as follows (high to low).

   o  Specific MPL Parameter Configuration to the MPL Domain (optlen=34)

   o  Wildcard MPL Parameter Configuration (optlen=18)

   o  Default configuration given in the MPL specification.

But there is no mention anywhere in the document to external/manual
configuration.  Where in that priority list should it fit?

Thanks!

Alvaro.