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

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

Hi Jonathan,

To be absolutely sure: the MPL multicast scope can be link-local, ULA 
or site-local? meaning the LLN border router can be a MPL forwarder?
In the latter case the LLN border router can forward link-local 
multicast from one interface to another?

Greetings,

peter

Jonathan Hui (johui) schreef op 2012-10-30 18:27:
> Yes, a goal of the current draft is to support both cases (use of
> IPv6-in-IPv6 encapsulation or not).
>
> The intent is as follows:
> 1) If the source of the multicast packet is within the MPL forwarding
> domain and the destination has a scope equal to or smaller than the
> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.
> 2) If the source of the multicast packet is outside the MPL
> forwarding domain or the destination has scope greater than the MPL
> multicast scope, then IPv6-in-IPv6 encapsulation is required.  When
> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
> multicast address with scope = MPL multicast scope is used as the
> destination address in the outer header.
>
> As mentioned in my other email, IPv6-in-IPv6 encapsulation is
> required if you want to use the IPv6 Destination Address to identify
> MPL forwarding scope zones.
>
> Of course, this brings up Dario's practical point of how to configure
> the MPL multicast scope if we allow that to dynamically change.  He
> proposes a simplifying suggestion of requiring IPv6-in-IPv6
> encapsulation for all non-link-local multicasts.  In other words,
> setting the MPL multicast scope to link-local.
>
> Thoughts?
>
> --
> Jonathan Hui
>
> On Oct 30, 2012, at 4:46 AM, Don Sturek <[e-mail]> wrote:
>
>> Hi Peter,
>>
>> I still need to read the latest draft so take what I say here with 
>> that in
>> mind......
>>
>> I was hoping that we could support not using IP in IP tunneling if 
>> the
>> scope of the multicast transmission was only within the multi-link 
>> subnet
>> managed by the border router.   I was hoping that only transmission
>> emanating from outside the multi-link subnet, received at the border
>> router, with scope that includes the devices in the multi-link 
>> subnet
>> would require IP in IP tunneling (and vice versa in terms of 
>> multicasts
>> generated in the multi-link subnet with scope outside).  I haven't 
>> yet
>> read the draft carefully to know if this is possible.
>>
>> Don
>>
>>
>> On 10/30/12 1:34 AM, "peter van der Stok" <[e-mail]> 
>> wrote:
>>
>>> Hi Don,
>>>
>>> and more specifically under which conditions. That gives the
>>> possibility to choose the conditions such that the encapsulation is 
>>> not
>>> needed.
>>>
>>> Don Sturek schreef op 2012-10-29 16:56:
>>>> Hi Peter,
>>>>
>>>> I think your suggested changes to the Trickle Multicast draft 
>>>> point
>>>> out
>>>> why IP in IP tunneling is needed.
>>>>
>>>> Don
>>>>
>>>>
>>>>
>>>> On 10/29/12 3:44 AM, "peter van der Stok" <[e-mail]> 
>>>> wrote:
>>>>
>>>>>
>>>>> Dear WG,
>>>>>
>>>>>
>>>>> Attached my suggestions for text modifications including some 
>>>>> nits. I
>>>>> used the facilities of word to edit and comment text with traces.
>>>>>
>>>>> When writing text about MC scope and MC domain, I was puzzled by 
>>>>> the
>>>>> all MPL forwarders multicast address which removes the 
>>>>> possibility to
>>>>> address a given multicast group. We expect multiple (possibly
>>>>> disjunct)
>>>>> MC groups in our wireless networks.
>>>>> Also I failed to understand why encapsulation was necessary once 
>>>>> the
>>>>> message was received by the seed.
>>>>> To make it possible to configure the interface with one MC scope 
>>>>> I
>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast
>>>>> Addresses (RFC 3306).
>>>>>
>>>>>
>>>>> Probably, I overlooked many aspects which make the suggestions
>>>>> impractical, but I hope that the intention is clear.
>>>>>
>>>>> Peter van der Stok
>>>>>
>>>>> Michael Richardson schreef op 2012-10-25 23:30:
>>>>>> I suggest that you propose specific text to the list to modify 
>>>>>> the
>>>>>> document.
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll