Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

[Dario Tedeschi <[e-mail]>]

I don't understand what benefit is gained by allowing the use of 
non-link-local in the outer header, if encapsulation is required. 
Supporting both link-local and higher in the outer header just servers 
to complicate the forwarder.

Is item 2 a requirement that a subset of devices in the LLN participate 
in MPL forwarding and others don't, or is it that there are two MPL 
domains, or is it that one subset of devices are listening on multicast 
address A while others are listening on multicast address B? In any 
case, I don't see how the use of link-local scope in the *outer* header 
would not work.

As for encapsulation, using an MPL multicast address of the from 
FF02::00XX, in the outer header, would only add three bytes to the 
packet after 6lowpan compression.

- Dario

On 01/11/2012 8:56 AM, Jonathan Hui (johui) wrote:
> [attempting to move the discussion to this ticket thread]
>
> Peter has two concerns:
> 1) Encapsulation when the source and destination of a multicast packet are within the same MPL domain.
> 2) Limiting the physical extent of an MPL domain to a connected subset of devices within an LLN.
>
> Restricting the MPL scope to link-local and requiring encapsulation for non-link-local multicast does not address either of Peter's concerns.
>
> I think we can solve (2) by allowing the MPL scope to be non-link-local but still require encapsulation.  The outer IPv6 header's IPv6 Destination Address then serves to identify the MPL domain, with the IPv6 Destination Address carrying the IPv6 multicast group address for the MPL domain.  Of course, MPL interfaces would need to be configured with the appropriate IPv6 multicast group(s), but the actual configuration method can be left out-of-scope for this draft.
>
> I think we can also solve (1) and (2) simultaneously if we require the IPv6 Destination Address to identify both the MPL domain and application endpoints.  Said differently, if the IPv6 Destination for the packet corresponds to the IPv6 multicast group address for an MPL domain, then no encapsulation is required.
>
> Thoughts?
>
> --
> Jonathan Hui
>
> On Oct 31, 2012, at 7:37 AM, roll issue tracker<[e-mail]>  wrote:
>
>> #105: trickle-mcast: how to determine scope of MPL domain
>>
>> There's no explanation on how a node would determine what scope
>> corresponds
>> to a MPL domain. How would it do that without being given some additional
>> information from the edge-router/s. I think what is needed, here, is some
>> multicast routing information from the edge-router/s.
>>
>> -- 
>> -----------------------------+---------------------------------------------
>> Reporter:  mcr@…            |      Owner:  draft-ietf-roll-trickle-mcast@…
>>      Type:  defect           |     Status:  new
>> Priority:  major            |  Milestone:
>> Component:  trickle-mcast    |    Version:
>> Severity:  In WG Last Call  |   Keywords:
>> -----------------------------+---------------------------------------------
>>
>> Ticket URL:<http://trac.tools.ietf.org/wg/roll/trac/ticket/105>
>> roll<http://tools.ietf.org/wg/roll/>
>>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll