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

[Don Sturek <[e-mail]>]

Hi Jonathan,

I agree with the approach you outlined below (ie, 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).

Don



On 11/1/12 8:56 AM, "Jonathan Hui (johui)" <[e-mail]> 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