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

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 25 Jan 2013 23:50:54 +0100

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 <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>>
>>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 26 Jan 2013 16:09:22 +0100

I understand that all the MPL messages are Trickel messages,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 26 Jan 2013 17:58:17 +0100

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

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 15:51:14 +0000

While RFC 6206 is particularly concerned about communication over shared media, Trickle is not specific to communication over shared media.

--
Jonathan Hui

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 15:51:59 +0000

Trickle does not utilize any knowledge of neighboring nodes.

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 17:21:40 +0100

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) <[email-masked]> wrote:
>
> While RFC 6206 is particularly concerned about communication over shared
> media, Trickle is not specific to communication over shared media.
>
> --
> Jonathan Hui
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 17:24:07 +0100

Hi Jonathan,

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

AB

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:33:44 +0000

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

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:34:35 +0000

MPL uses multicast.

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 17:38:31 +0100

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) <[email-masked]> 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 25, 2013, at 2:50 PM, Abdussalam Baryun
>>> <[email-masked]>
>>> wrote:
>>>
>>>> Dear I-D Authors,
>>>>
>>>>>> IETF ROLL WG co-chair.
>>>>>> http://datatracker.ietf.org/wg/roll/charter/
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 17:45:33 +0100

> MPL uses multicast.

Do you mean; MPL uses IP multicast?

I understand that the MPL is already the multicast protocol for our
network, I thought that MPL  does not need to use IP multicast. I may
misunderstood, please advise,

AB

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:46:48 +0000

Yes, MPL will work for both shared and non-shared media.

--
Jonathan Hui

On Jan 28, 2013, at 8:38 AM, Abdussalam Baryun <[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:48:27 +0000

MPL forwards IPv6 multicast messages using IPv6 multicast messages (hence the IPv6-in-IPv6 encapsulation).

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 17:53:47 +0100

Hi Jonathan,

So if MPL works in both, then I am confused, because Trickel RFC6206
that this I-D depends on works only for shared communication mediums.
Does this I-D depend on the RFC6206 or it is not the only algorithm
that MPL uses.

AB

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:59:53 +0000

Again, while Trickle targets operation over shared media, Trickle can work over non-shared media.  RFC 6206 does not have any text that restricts Trickle to shared media.

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 18:01:19 +0100

> the IPv6-in-IPv6 encapsulation).

So I understand from your reply that MPL uses always IPv6 multicast
encapsulation for its data. I thought before it was only outside the
MPL domains, that it will use IP-in-IP

AB

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 17:06:38 +0000

IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination Address is the MPL Domain Address.

But whether or not encapsulation is used, Section 10.1 specifies:

     The IPv6 Destination Address MUST be set to the MPL Domain Address
      corresponding to the MPL Domain.

And as Section 2 specifies, the MPL Domain Address is a multicast address.

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 18:11:20 +0100

Ok so my understanding before was correct. Therefore, inside the MPL
domain there is no need for IP multicast, just MPL multicast using its
forwarders, is this correct?

AB

On 1/28/13, Jonathan Hui (johui) <[email-masked]> wrote:
>>> MPL forwards IPv6 multicast messages using IPv6 multicast messages
>>> (hence
>>> the IPv6-in-IPv6 encapsulation).
>>>
>>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 17:14:34 +0000

Correct.  An MPL Forwarder forwards a message to its next hop using link-layer multicast (which many LLN technologies map to link-layer broadcast).

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 19:48:25 +0100

On 1/28/13, Jonathan Hui (johui) <[email-masked]> wrote:
>
> Correct.  An MPL Forwarder forwards a message to its next hop using
> link-layer multicast (which many LLN technologies map to link-layer
> broadcast).
>

I understand from reply and previous one, as MPLhas no knowledge of
neighbors, so that MPL is not multicasting by itself within the
domain, it is broadcasting, but because using Trickel not always all
nodes in the domain receive the message, therefore, MPL is
multicasting.

Overall, now I think I got to read the draft again, to prepare my
review, thanks alot for your help,

AB

>>> IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination
>>> Address
>>> is the MPL Domain Address.
>>>
>>> On Jan 28, 2013, at 9:01 AM, Abdussalam Baryun