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

From: "Reddy, Joseph" <[email-masked]>
Date: Thu, 1 Nov 2012 00:00:49 +0000

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)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Message-ID:
	<[email-masked]>
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

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 04:59:35 +0000

Hi Joseph,

Comments below:

> 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…

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.

> 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 latenc…

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

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

OK.  Any additional inputs from the WG?

> 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 dis…

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