From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Jonathan Hui (johui)" <johui@cisco.com>, "Reddy, Joseph" <jreddy@ti.com>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: Ac23wx9aBfIsegKOz0GvSDMMHJeV6gAKpCOAABDebyA=
Date: Thu, 1 Nov 2012 13:17:10 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B09C5B@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <2AA5AC69E924D149A8D63EB676AF87DB2CAE2DB8@DLEE10.ent.ti.com>
 <B50D0F163D52B74DA572DD345D5044AF0F6ED2FA@xmb-rcd-x04.cisco.com>
In-Reply-To: <B50D0F163D52B74DA572DD345D5044AF0F6ED2FA@xmb-rcd-x04.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Precedence: list

> Any feedback from others in the WG on this?  Should we include support fo=
r selecting 1, 2, or more parameter sets?

Having two parameter sets is useful to support two main uses of multicast i=
n 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 tr=
iggered by sensors or smartphones)
-> "fast" Trickle parameter set

Esko

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon=
athan 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 encap=
sulation even when it is not needed.
> Regarding the practical aspects of determining the MPL scope, I think tha=
t can be left to "administrative configuration". Other multicast details (e=
.g., the zone boundaries for scopes greater than link local) have to be adm=
inistratively 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 exp=
licitly identifies the MPL scope zone.

2) Without encapsulation, the IPv6 Destination Address identifies the endpo=
ints that should process the IPv6 payload.  However, the IPv6 Destination A=
ddress may not explicitly identify the MPL scope zone.  Instead, the IPv6 S=
ource Address identifies the MPL scope zone.  It is easy to determine the s=
cope 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 servic=
e 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 a=
lso identify MPL forwarders that will forward the message.  Another solutio=
n is to include an MPL domain/instance identifier in the MPL Option.  Yet a=
nother 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 s=
ingle 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 t=
rickle 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 t=
o the "all-MPL-forwarders" multicast address? Nodes that receives an MPL pa=
cket but don't understand the MPL option will discard it anyway.

I think the most compelling reason is to remove yet another configuration p=
arameter.  But allowing arbitrary multicast addresses to identify MPL forwa=
rders would be necessary to support multiple MPL scope zones using the IPv6=
 Destination Address.  If we require encapsulation with link-lcoal multicas=
t, 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 p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.