Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - separate MPL from 0x3 scope definition

[peter van der Stok <[e-mail]>]

Dear all,


Looking at the discussion there seem to be two issues:
-1 tunnelling MC messages through MPL domain
-2 Sending multicast to all members of a mesh

I suggest to separate them to make the progress of MPL draft independent 
of 0x3 scope definition

Ad 1)
I understand that on reception by a seed of a MC message without MPL 
option, the wish is to encapsulate the message with a header which 
contains the MPL option to distribute the message over the mesh using 
MPL.
At reception of the message each receiver still needs to check whether 
the MC address in the original message is destined to the receiving 
node.
Therefore I think that the encapsulating header does not need the 
ALL_MPL_FORWARDERS multicast address but can be equal to the MC address 
of the original message.
This means that receiving nodes need to enable their interfaces to the 
MC-address stored in the header of the original message.
Given that the node needs to know this address anyway, I don't think 
this complicates the use of MPL.

This also works for a message leaving the MPL domain.

Any mistakes in my reasoning? Putting this text in section 5.1, and 
removing the text in section 4.1 can help the progress of MPL draft.

Ad 2)
There is a clear wish to distribute a MC message to all members of a 
mesh network, for example to distribute mdns messages or to learn lowpan 
start-up information like address of border router.
Making that the subject of IP_over_Foo drafts seems very reasonable to 
me.
The 6lo WG can provide an addendum to the 6lowpan RFC to provide an 
algorithm that makes it possible that all mesh members learn the same 
0x3 scope address, and enable the address.
Although MPL forwarders need to forward the message, the destinations 
are not necessarily MPL forwarders.
Identifying the MC address with the PAN-ID (given the PAN-ID does not 
change in spite of coordinator failures) of the mesh seems logical for 
IEEE802.15.4.

Sending a multicast to all members to a heterogeneous multi-link network 
looks like a different problem to me.

Hope this may help.

Peter