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

[Ralph Droms <[e-mail]>]

On Oct 17, 2013, at 8:21 AM 10/17/13, peter van der Stok <[e-mail]> wrote:

> 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.

This idea is interesting.  I don't know if the WG considered it.  

However, I'm not sure it's a simplification.  There are two functions in a MPL forwarding node: forwarding multicast traffic on to other nodes in the MPL domain and delivering traffic to local applications.  The former function requires that the node stack receive and forward all multicast traffic while the latter function uses the list of locally subscribed multicast addresses for local delivery.

I suppose there's no difference between a node accepting all multicast traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer header, and then delivering only subscribed traffic based on the inner header.

> 
> 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.

If I've got it right, you support publication of a very short RFC that gives the definition of IEEE802.15.4 scope 3 as the list of all interfaces that share the same PAN ID.

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

Agreed.

- Ralph

> 
> Hope this may help.
> 
> Peter
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll