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

["Jonathan Hui (johui)" <[e-mail]>]

Hi Joseph,

Comments below:

On Oct 31, 2012, at 5:00 PM, "Reddy, Joseph" <[e-mail]> 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