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

[Robert Cragie <[e-mail]>]

Hi Jonathan,

I see some of my comments to the authors were incorporated but not all. 
I still think the packet definitions are too vague and lead to confusion 
and there is still some clarity required regarding address scope and MPL 
scope and domain. Maybe the 'zone' language will help. Attached are my 
comments, bracketed by <RCC></RCC>.

Robert

On 31/10/2012 4:21 PM, Jonathan Hui (johui) wrote:
> 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
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>