Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

[Kerry Lynn <[e-mail]>]

Greetings,

Apart from the fact that this draft is introduced in ROLL to address a problem
inherent in multi-link subnets, I see nothing in the proposal that
limits it to such
networks.  It seems to me that trickle multicast could be considered in other
applications, e.g. homenet, if it compares favorably with PIM-xM in complexity.

In reading trickle multicast in this more general way, I'd like to see
additional
clarification regarding the use of Proactive Forwarding.  Section 4.2 reads:

   Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
      schedules transmissions of MPL Data Messages using the Trickle
      algorithm, without any prior indication that neighboring nodes
      have yet to receive the message.  After transmitting the MPL Data
      Message a limited number of times, the MPL Forwarder may terminate
      proactive forwarding for the MPL Data Message message.

I think the final sentence should read:

     After transmitting the MPL Data Message a limited number of times, the
     MPL Forwarder MUST terminate forwarding of the MPL Data Message.

This eliminates the possible interpretation that both Proactive and Reactive
Forwarding may be used by the same MPL Forwarder for the same MPL
Data Message within the same MPL Domain.  I believe the intent is that
Proactive and Reactive Forwarding should be mutually exclusive within
the same MPL Domain?

In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
Parameter".  I believe this should be set (or not) on a MPL Domain basis
(and therefore as an attribute of the Local Interface).  Again, it should be
made clear that Proactive and Reactive Forwarding are mutually exclusive,
e.g. by adding a sentence to the end of the first paragraph in section 5.4:

     If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
     is in use.

This ties it to section 5.1, which mandates MPL Control Messages on an
interface where Reactive Forwarding is in use.

I believe that section 5.5 should also be clarified with respect to the meaning
of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
read:

   This specification defines a fourth Trickle configuration parameter,
   TimerExpirations, which indicates the number of Trickle timer
   expiration events that occur before terminating the forwarding of a
   given MPL Data Message.

This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
number of times" statement in section 4.2.  Similarly, the definition of
DATA_MESSAGE_TIMER_EXPIRATIONS should read:

   DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
      expirations that occur before terminating the Trickle algorithm's
      re-transmission of a given MPL Data Message.
      DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.

This eliminates the possible interpretation that the Trickle algorithm may
not be used for subsequent MPL Data Messages.


Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
to suggest that this parameter should be described as the number of
doublings of Imin: "For example, a protocol might define Imax as 16."
If this interpretation is correct, then DATA_MESSAGE_IMAX should be
set to 0 in order to limit Imax to Imin.

Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
number of doublings, or at least specified in terms of worst-case link-
layer latency if my interpretation of RFC 6202 is incorrect.

The implication of specifying Imax = Imin seems to be that the dithering
interval for MPL Data Message re-transmission will *always* be [Imin/2,
Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
which is presumably the point for specifying the default values as they are.


Regarding the definition of MPL Domains, section 8 states:

   By default, an MPL Forwarder SHOULD participate in an MPL Domain
   identified by the ALL_MPL_FORWARDERS multicast address with a scope
   value of 3 (subnet-local).

As Ralph Droms indicated in
http://www.ietf.org/mail-archive/web/roll/current/msg07829.html, "something
has to be done to allow MPL to use scope 0x03."  In the most expedient
scenario, 0x03 is re-defined from "reserved" to "undefined" and the proposal
then gets to define how 0x03 is used by trickle multicast.

Assuming the desired use of 0x03 multicast scope is to indicate
ALL_MPL_FORWARDERS within a given prefix, the question is how to
indicate the prefix in question?  RFC 6282 allows for the stateful compression
of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section 4.2
allows for the assignment of "Permanent IPv6 Multicast Group Identifiers"
for use with RFC 3306 multicast addresses.  Therefore it seems prudent to
also request from IANA a Permanent IPv6 Multicast Group Identifier
http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xml
to allow for the possibility of specifying the desired prefix in the MPL Domain
Address.


Lastly, to improve the clarity of section 11.2, the first bullet should read:

   o  This document defines a "consistent" transmission as receiving an
      MPL Control Message that results in a determination that neither the
      receiving nor transmitting node has any new MPL Data Messages to offer.

(The transmission indicates nothing about state at the receiver.)  Similarly,
the second bullet should read:

   o  This document defines an "inconsistent" transmission as receiving
      an MPL Control Message that results in a determination that either the
      receiving or transmitting node has at least one new MPL Data Message
      to offer.

It might be helpful to add a penultimate sentence to section 11.2:

      The Trickle timer is reset in response to external "events".

Regards, -K-


On Fri, Mar 15, 2013 at 7:34 AM, JP Vasseur (jvasseur)
<[e-mail]> wrote:
>
> Dear all,
>
> All issues raised during the previous WG LC have been successfully addressed in draft-ietf-roll-trickle-mcast-04.
> That said, since we made several changes, this starts a 2-week WG LC that will end on March 29 at noon ET.
> Thanks.
>
> JP.
>
> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>
> Dear all,
>
> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list and during WG meeting a number of time; the document is stable and
> has been implemented. Thus this starts a 2-week WG Last call ending on Nov 9 at noon ET. Please send your comments to the authors
> and copy the mailing list and the co-chairs.
>
> Thanks.
>
> JP.
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>