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

[Dario Tedeschi <[e-mail]>]

Ok, so an entire multicast address defines an MPL domain. Sending to a 
multicast address, that does not match an MPL domain's address, requires 
encapsulation. So if an MPL domain had been assigned an address 
FF05::1234 and a device sends to FF05::1235 or FF04::1234, it must 
encapsulate.

This would work, but we've also added the need for devices in the 
network to be told what addresses are MPL addresses (i.e. routing 
information). In my example above, devices would have to be told that 
FF05::1234 is an MPL domain adddress. If we take this approach, I think 
we should also define how this information is disseminated.

In one of my previous emails, I suggested adding a RIO to RPL DIO 
advertisements. If we also allow prefix lengths less than 128, multiple 
MPL addresses could be aggregated by one RIO. So instead of a simple 
address match, a device would use longest-prefix match, just like it 
would for unicast forwarding/sending.

- Dario

On 01/11/2012 6:13 PM, Jonathan Hui (johui) wrote:
> Hi Dario,
>
> Unicast-prefix-based multicast addresses also contain a scope identifier.  So while the prefix does bound the scope, the scope of a prefix can contain multiple scopes.
>
> In any case, I don't think I properly articulated what I had in mind in my email below.  It seems that we are converging on a definition where an MPL domain is defined by the IPv6 multicast address that interfaces subscribe to.  In other words, an IPv6 multicast address identifies an MPL domain.  All MPL multicast packets containing an MPL Option must have the IPv6 Destination Address set to the MPL domain that they are being transported in.  If an MPL forwarder wants to forward a multicast packet within an MPL domain and that multicast packet does not have an IPv6 Destination Address corresponding to the domain's IPv6 multicast address, then the forwarder MUST encapsulate it.  So now it becomes a simple address match rather whether an IPv6 address is within the scope zone.
>
> Does that solve the issue?
>
> --
> Jonathan Hui
>
> On Nov 1, 2012, at 5:59 PM, Dario Tedeschi<[e-mail]>  wrote:
>
>> I'm not so sure. What if, for example, I connected my BR to an existing network that already had say scope 4 (admin-scope) configured to cover a wider domain than just the PAN. I then could not configure the BR to report 4 as the scope of the PAN (the "MPL scope"). Yes, one could use scope 3, but it is currently reserved. Besides, it wouldn't really solve the problem, if you consider that scope 3 could quite easily also cover a wider domain than just the PAN.
>>
>> This is where unicast-prefix-based multicast addressing would become useful. It would remove the need for an "MPL scope", since the MPL domain would be defined by the PAN's prefix.
>>
>> - Dario
>>
>>
>> On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote:
>>> If the draft indicates that the MPL domain scope is a required configuration parameter, would that be sufficient?
>>>
>>> --
>>> 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