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

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

Hi Jonathan,

things becone very clear for me by this explicit operational 
explanation.
Could some text like this be added to the document?

I think my important issues have been addressed. Looking forward to the 
new text.

Many thanks,

Peter

Jonathan Hui (johui) schreef op 2012-10-31 15:53:
> Hi Peter,
>
> The current draft does not place any restrictions on the MPL 
> multicast scope.
>
> If the LLN border router is an MPL forwarder, it can forward MPL
> multicast packets between different MPL multicast scope zones.  To be
> explicit, if the original multicast packet's destination address has
> link-local scope, the MPL forwarder should not forward the packet
> again.  If the original multicast packet's destination has a scope
> larger than the MPL multicast scope, then the MPL forwarder needs to
> forward the packet to other MPL multicast scope zones (which may or
> may not involve different interfaces).
>
> Does that address your question?
>
> --
> Jonathan Hui
>
> On Oct 31, 2012, at 3:54 AM, peter van der Stok <[e-mail]> 
> wrote:
>
>> 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
>>