[Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03

[Abdussalam Baryun <[e-mail]>]

Dear I-D Authors,

I done a little review so far and need answers to continue, as the
ROLL chair asked for some discussion on our WG draft, which I will try
to do so far.

I see that the draft's applicability statement does not include
*shared medium*, but the *trickel algorithm* works for shared medium,
which in RFC6206 states that in the abstract. So if this MPL uses
trickel do you think it still will work in a non-shared communication
medium LLN, Please advise?

otherwise I recommend to add the words as in trickel: *lossy shared medium*
As in the appplicability statement section 3

AB> Recommend Amend to>
This protocol is an IPv6 multicast forwarding protocol for nodes in
shared medium within the low-power and lossy network domain. By
implementing a controlled dissemination using the Trickle algorithm,
this protocol is designed for networks that
communicate using low-power and lossy links with widely varying
topologies in both the space and time dimensions.

AB> question on section 3> I am not sure I understand *the space and
time dimensions*, Do you mean that the topology or multicast-nodes
is/are changing in space, please give me an example use-case?

Regards

AB

>> On 1/22/13, Michael Richardson <[e-mail]> wrote:
>>
>> http://trac.tools.ietf.org/wg/roll/trac/report/8
>> contains the list of open tickets.  There are some threads
>> linked in each ticket.
>>
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103
>>   trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS
>>   http://www.ietf.org/mail-archive/web/roll/current/msg07424.html
>>
>>   This ticket has had no significant discussion.  Is there an issue
>>   here?
>>
>>
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104
>>   security considerations.
>>   We need to have a discussion about what are the implications
>>   of this protocol.  See next message.
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105
>> trickle-mcast: how to determine scope of MPL domain
>>   We have several options from Robert Craigie in the ticket system.
>>   Alternatives 3 and 4 were discussed, and I think that we preferred
>>   option 4 with the multicast option always present.
>>   Please post if you disagree.
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106
>> trickle-mcast: always use 6in6 encapsulation for non-link-local multicast
>>   no clear resolution, but ticket #105 suggests answer.
>>
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108
>> trickle-mcast: should there be an explicit version field?
>>   suggested answer was YES.
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107
>> trickle-mcast: should multiple parameter sets be supported
>>   my conclusion: There is has been little discussion about this
>>      issue. My inclination is to not include multiple sets at this
>>      time.
>>
>>
>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109
>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders
>>
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>>
>>
>