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

["Reddy, Joseph" <[e-mail]>]

Hi Jonathan,

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.

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

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

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.

-Regards, Joseph



------------------------------

Date: Fri, 19 Oct 2012 17:31:52 +0000
From: "Jonathan Hui (johui)" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="us-ascii"


ROLL WG,

This update includes the new text that was sent out during the last IETF meeting and incorporates comments received since then (special thanks to Robert Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter van der Stok).

The following are some open discussion items that were raised in the comments.  Would be great to hear your thoughts.

1) MPL multicast scope.  The current draft allows the MPL multicast scope to be link-local scope or something larger.  On one hand, fixing the MPL multicast scope to be link-local reduces the number of options, makes things simpler, and improves interoperability. On the other hand, doing so will make IPv6-in-IPv6 encapsulation a MUST even when the source and destinations are all in the MPL domain.

2) The S field.  The current draft includes an S field in the MPL Hop-by-Hop Option to indicate the length of the seed identifier.  On one hand, the length of the seed identifier may be inferred by the Opt Data Len field.  On the other hand, if any future specification wants to define additional fields following the seed identifier field, that specification would need some way to indicate the length of the seed identifier.  The S field was originally included to allow the possibility of something like sub-TLVs, that are extensively used throughout RPL.

3) Supporting different Trickle parameter sets.  The latest draft removes a flag that indicates which of two parameter sets to use when disseminating MPL multicast packets.  We removed the flag in attempt to simplify the draft.  Furthermore, it wasn't clear that a single flag (2 parameter sets) was sufficient.

4) Version number field.  The current draft does not include a version field in the MPL Hop-by-Hop Option.  Instead, it sets all reserved bits to zero and requires all devices that implement this draft to drop the message if any of those bits are non-zero.

--
Jonathan Hui