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

["Jonathan Hui (johui)" <[e-mail]>]

Hi Peter,

Yes, I will attempt to clarify this point in the next revision.

Thanks.

--
Jonathan Hui

On Oct 31, 2012, at 8:01 AM, peter van der Stok <[e-mail]> wrote:

> 
> 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
>>> 
>