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

[David Culler <[e-mail]>]

Hi Don,
   It is pretty hard to see how you come to the sweeping statement, "The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only occurs in route-over mesh routing [sic]."  That is the purview of the draft and sufficient for it to address that domain, but your statement is quite another thing.  

David


On Mar 29, 2013, at 7:37 AM, Don Sturek wrote:

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