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

[Abdussalam Baryun <[e-mail]>]

I don't mean to mix between the network and protocol. This MPL does it
use both work for shared medium and non-shared medium. Does its
forwarding functions can work for both or not, this is my concerns not
concerned about the LLNs?

AB

On 1/28/13, Jonathan Hui (johui) <[e-mail]> wrote:
>
> MPL targets LLNs (as the L in MPL indicates).  Today's LLNs typically
> communicate over shared media, but I don't see any reason why LLNs (and MPL)
> should be limited to shared media.
>
> --
> Jonathan Hui
>
> On Jan 28, 2013, at 8:21 AM, Abdussalam Baryun <[e-mail]>
> wrote:
>
>> Hi Jonathan
>>
>> so do you mean the MPL is for both shared and non shared mediums, and
>> using Trickel for the mulicast purpose
>>
>> AB
>>
>> On 1/28/13, Jonathan Hui (johui) <[e-mail]> wrote:
>>>
>>> While RFC 6206 is particularly concerned about communication over shared
>>> media, Trickle is not specific to communication over shared media.
>>>
>>> --
>>> Jonathan Hui
>>>
>>> On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun
>>> <[e-mail]>
>>> wrote:
>>>
>>>> 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/
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>