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

[Don Sturek <[e-mail]>]

Hi Kerry,

The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
occurs in route-over mesh routing.  I don't believe Homenet has such
routing solutions in their charter.  It is possible to see how a group
like Manet might use the draft but the only concrete forwarding solution
proposed is over ROLL RPL instances (certainly, provision was left in for
other multicast address usage and attendant forwarding rules but those
were out of scope for this draft).

I would propose that we move forward with the draft, within ROLL, and not
wait for input from other groups since the scope of the initial draft
(absent extensions that other groups could propose in the future) is
focused on ROLL RPL.

Don



On 3/29/13 7:20 AM, "Kerry Lynn" <[e-mail]> wrote:

>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.xm
>l
>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
>>
>_______________________________________________
>Roll mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll