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

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

Hi all,

using link-local scope on the outer header is OK with me.
I have no ideas about using something else than HbH MPL option.
As long as a MPL message created on a host within the MPL domain with 
the MPL option can be forwarded wihin the zone without encapsulation,
my concern about payload size is minimized.(last case of Robert's 
HbHTunnelMcast-v7 cases).

Can some text be added in section 5.3 like:
When the multicast destination address in the original MPL message is a 
unicast prefix multicast address and the
  the unicast prefix of the forwarder is not a prefix of the unicast 
prefix of the MC address, the forwarder ignores the message.

I think that would limit the forwarding to a subnet identified by a 
prefix while routers to the subnet continue to forward the message.

Apologies for confusing things.

peter

Jonathan Hui (johui) schreef op 2012-11-01 04:54:
> Hi Dario,
>
> You've made good points on why restricting to link-local scope would
> be simpler overall. Except for point 2, non-MPL aware routers will 
> not
> simply forward encapsulated multicast datagrams as long as the MPL
> Option type has the highest order bits set to indicate that the
> processing node discard the packet if it does not recognize the
> option.
>
> However, restricting to link-local scope does not solve Peter's use
> case of limiting the multicast dissemination to a subset of devices.
> Having a non-link-local MPL scope is one method to solve his problem.
> Granted, the devices within each MPL scope zone needs to be 
> configured
> with an MPL multicast address that identifies the MPL multicast scope
> zone. One way forward is to have the draft explicitly indicate that 
> is
> a necessary configuration, and leave the actual configuration method
> out of scope. Of course, there are many ways one could configure an
> interface (including manual configuration), so that is one argument
> for leaving it out of scope.
>
> Another possible solution is to include an "MPL domain" identifier
> within the Hop-by-Hop Option itself rather than using the IPv6
> Destination Address. Still requires some way to configure devices 
> with
> an MPL domain.
>
> Yet another solution that was discussed is to include some kind of 
> Hop
> Limit field in the Hop-by-Hop Option. But that brought up
> complications with what happens with a devices first receives a
> messages with different Hop Limit values.
>
> One final point, if we restrict MPL scope to link-local, then we 
> could
> use a Destination Option instead of a Hop-by-Hop Option.
> Alternatively, we could even encapsulate using UDP.
>
> Thoughts (from Dario, Peter, and the rest of the WG)?
>
> --
> Jonathan Hui
>
> On Oct 31, 2012, at 4:22 PM, Dario Tedeschi <[e-mail] [1]>
> wrote:
>
>> Yes, I'd like to try clarify why link-local scope was suggested for
>> the *outer* header. The reasons were:
>>
>> * Link-local scope is the only scope where the boundaries are well
>> defined (i.e. on the link). Higher scopes are not well-defined and
>> can cover wide domains depending on network configuration and
>> administration.
>> * With a higher scope, there is a chance that non-MPL aware routers
>> may simply forward encapsulated multicast datagrams (MPL HbH option
>> and all). We wouldn't want MPL datagrams to leak outside of an MPL
>> domain.
>> * A higher scope complicates the forwarding logic that needs to be
>> implemented in an MPL router. The complication comes when a router
>> receives an MPL datagram and needs to figure out whether to
>> decapsulate or not. Granted, the use of an MPL group would mitigate
>> this problem to a degree, but link-local scope would make the
>> decision to decapsulate very obvious and simple.
>>
>> * In conjunction with 3. Link-local scope also makes it easier for
>> an MPL router to determine if the inner multicast address is one
>> that a higher layer (or an app) may be interested in.
>>
>> Hopefully I haven't made things more confusing.
>>
>> - Dario
>>
>> On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote:
>>
>>> 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
>
>
>
> Links:
> ------
> [1] mailto:[e-mail]