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

[Abdussalam Baryun <[e-mail]>]

Hi Jonathan,

Why MPL forwarder have no knowledge of neighbors, then how does it
forward to other forwarders,

AB

On 1/28/13, Jonathan Hui (johui) <[e-mail]> wrote:
>
> Trickle does not utilize any knowledge of neighboring nodes.
>
> --
> Jonathan Hui
>
> On Jan 26, 2013, at 8:58 AM, Abdussalam Baryun <[e-mail]>
> wrote:
>
>> The draft does not clarify how the MPL forwarding knows its neighbors,
>> or the MPL neighbor is not defined in the doc, please advise,
>>
>> AB
>>
>> On 1/25/13, 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/
>>>>>
>>>>>
>>>>
>>>
>
>