Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

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

Hi Michael,

It is related to the scope of the multicast, but not in the 
administrative sense, but in an operational sense when wireless 
forwarders receive MPL messages and they should be able to filter only 
those messages that are targeted to the subnet of which they are part.


I explained the case earlier with an example.

Two border routers are connected to two 802.15.4 networks, N1 and N2. 
The nodes of N1 have a different unicast prefix from the nodes of N2.
The nodes of N1 receive packets coming from nodes of N2 and vice versa 
because the groups are closely spaced.
A node A1 in group N1 wants to send a multicast to a group G1 of nodes 
in N1.
The group members of G1 share a Unicast prefix multicast address with 
the unicast prefix belonging to group N1 nodes.
Node A1 uses this MC address when sending a message.
To my current understanding, MPL passes the message without 
encapsulation on to all forwarders in networks N1 and N2.
My hope was to limit the reception to forwarders in group N1 only.
That suggests a filter at reception on the unicast prefix, when the 
multicast address is a unicast prefix multicast address.

Michael Richardson schreef op 2012-11-01 15:15:
>>>>>> "peter" == peter van der Stok <[e-mail]> writes:
>     peter> As long as a MPL message created on a host within the MPL
> domain with the MPL
>     peter> option can be forwarded wihin the zone without 
> encapsulation,
>     peter> my concern about payload size is minimized.(last case of 
> Robert's
>     peter> HbHTunnelMcast-v7 cases).
>
>     peter> Can some text be added in section 5.3 like:
>
>     peter> When the multicast destination address in the original MPL
> message is a
>     peter> unicast prefix multicast address and the
>     peter> the unicast prefix of the forwarder is not a prefix of the
> unicast prefix of
>     peter> the MC address, the forwarder ignores the message.
>
> Peter, I want to capture this into a ticket somewhere, but I'm 
> unclear
> if this relates to determining the scope of the MPL domain, or if 
> it's
> related to another problem that I don't yet understand.