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

[Yoshihiro Ohba <[e-mail]>]

I don't see much benefit of dynamically allocating an MPL domain address 
and advertising it via a routing protocol, as each node can be 
pre-configured to a member of an MPL domain.

Isn't it simpler if we can register a fixed MPL domain address with IANA 
(for each multicast scope that uses MPL)?

Yoshihiro Ohba


(2012/11/03 2:22), Dario Tedeschi wrote:
> 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
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>