Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt

> Any feedback from others in the WG on this?  Should we include support for selecting 1, 2, or more parameter sets?

Having two parameter sets is useful to support two main uses of multicast in LLNs for the building control domain;

1) Device/service discovery, such as mDNS and CoAP's /.well-known/core.
Latency is less important here; avoiding high network load due to discovery traffic is also a goal if other more time-critical application are running at the same time.
-> "slow" Trickle parameter set

2) Building Control involving groups of devices
Latency can be important (e.g. lighting control, or any device operation triggered by sensors or smartphones)
-> "fast" Trickle parameter set

Esko

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui (johui)
Sent: Thursday 1 November 2012 6:00
To: Reddy, Joseph
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt

Hi Joseph,

Comments below:

On Oct 31, 2012, at 5:00 PM, "Reddy, Joseph" <jreddy@ti.com> wrote:

> Here are some comments on the trickle multicast draft rev-02
>
> 1. MPL multicast scope:
> I think fixing it to link-local is too restrictive as it will force encapsulation even when it is not needed.
> Regarding the practical aspects of determining the MPL scope, I think that can be left to "administrative configuration". Other multicast details (e.g., the zone boundaries for scopes greater than link local) have to be administratively configured anyway.

I agree that it is desirable to avoid encapsulation when possible.

There is an important difference depending on whether encapsulation is used:

1) With encapsulation, the IPv6 Destination Address of the outer header explicitly identifies the MPL scope zone.

2) Without encapsulation, the IPv6 Destination Address identifies the endpoints that should process the IPv6 payload.  However, the IPv6 Destination Address may not explicitly identify the MPL scope zone.  Instead, the IPv6 Source Address identifies the MPL scope zone.  It is easy to determine the scope zone if we require the separation to occur across interface boundaries (just observe what interface the message came in on).  However, it is not so easy to determine the scope zone if we want a single interface to service more than one MPL scope zone.  I believe the latter case is what Peter is looking for.  One solution is to require the IPv6 Destination Address to also identify MPL forwarders that will forward the message.  Another solution is to include an MPL domain/instance identifier in the MPL Option.  Yet another solution is to eliminate this case and always require encapsulation.

> 2. Supporting different Trickle parameter sets:
> I think this is a useful feature and should be included even if it is a single flag (2 parameter sets). Typical use cases for multicast in LLN's try to achieve either high reliability or low latency and having two sets of trickle parameters for each of them should help

Any feedback from others in the WG on this?  Should we include support for selecting 1, 2, or more parameter sets?

> 3. Version field:
> I think adding an explicit version field ( 2 bits should be enough) will help.

OK.  Any additional inputs from the WG?

> 4. Destination address:
> Is there a reason to restrict the destination address of the MPL packet to the "all-MPL-forwarders" multicast address? Nodes that receives an MPL packet but don't understand the MPL option will discard it anyway.

I think the most compelling reason is to remove yet another configuration parameter.  But allowing arbitrary multicast addresses to identify MPL forwarders would be necessary to support multiple MPL scope zones using the IPv6 Destination Address.  If we require encapsulation with link-lcoal multicast, then an all-MPL-forwarders address would be ok.

Thoughts?

--
Jonathan Hui

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.