Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text)

> The IPv6-in-IPv6 is needed so that the Trickle Multicast hop-by-hop option can be removed
> or inserted when a site-local (or higher) scoped multicast datagram leaves or enters a RPL domain.
Without encapsulation, also the hop-by-hop option can be inserted or removed into the header. In that case the IP destination address is indeed site-local or global scope, but I don't see a problem there - is there? (RPL takes this approach and also the current Trickle Multicast draft.)
Besides the benefit of this approach is that non-router nodes can also receive the multicast at the correct address (e.g. a global scope multicast address X they are listening for).

> Secondly,  IPv6-in-IPv6 should compress quite well using 6LoWPAN, because the IPv6 addresses 
> in the inner packet are elided from the IPv6 addresses in the outer header.
True, the outer (encapsulating) header can be small e.g. the 4 bytes I mentioned. But with the proposed encapsulation the IP source address (in the encapsulated, inner header) is not usable anymore to indicate Seed ID so that's an additional 16 bytes lost. 

Esko

-----Original Message-----
From: Dario Tedeschi [mailto:dat@exegin.com] 
Sent: Friday 31 August 2012 16:41
To: Dijk, Esko
Cc: Jonathan Hui (johui); roll@ietf.org
Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text)

The IPv6-in-IPv6 is needed so that the Trickle Multicast hop-by-hop option can be removed or inserted when a site-local (or higher) scoped multicast datagram leaves or enters a RPL domain. If a device doesn't require or expect highly scoped multicasts to leave the RPL domain it could choose to originate a multicast datagram with a Trickle Multicast option and need not encapsulate. However, in the interest of consistency, it would be better if all nodes handled multicasts in the same way. Otherwise you end up with routers having to support both tunnelled and non-tunneled multicasts, which gets a bit complicated.

Secondly,  IPv6-in-IPv6 should compress quite well using 6LoWPAN, because the IPv6 addresses in the inner packet are elided from the IPv6 addresses in the outer header.

-Dario

On 2012-08-27, at 6:45 , Dijk, Esko wrote:

> Hello Jonathan,
> 
> great to see that this draft includes many improvements. However the added overhead of the newly introduced IPv6-in-IPv6 encapsulation and the removal of the 0-byte "seed-id==IPv6-source-address" option is worrying. For example in a typical use in a 6LoWPAN 802.15.4 network, an extra 6LoWPAN IPHC header is included (+4 bytes) and a seed-id (+16 bytes) field compared to the same situation using the 'old' Trickle Multicast.
> 
> That's 20 bytes more overhead and space is already scarce. (With 2-byte seed-ids we can get this 20 down to 6 bytes, but that implies some seed-id assignment process is needed which was not needed in Trickle Multicast.)
> 
> The reason is given as follows:
>> IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery when the MPL
>>   forwarder is not the source of the original multicast packet.  IPv6-
>>   in-IPv6 encapsulation also allows an MPL forwarder to remove the MPL
>>   Option when forwarding the original multicast packet over a link that
>>   does not support MPL.
> Why is Path MTU discovery necessary here? (Isn't it optional?) Sensible applications would stay far, far away from the MTU size e.g. 1280 bytes in 6LoWPAN, especially for multicast.
> And why is encapsulation needed to support it? (Maybe there is a reference that explains this?)
> 
> Is it possible to 'fix' the problem and use the compactness of the 'old' (v00) packet format in the new draft?
> 
> best regards,
> Esko
> 
> 
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui (johui)
> Sent: Friday 3 August 2012 19:48
> To: roll@ietf.org
> Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text)
> 
> 
> We've been working on an update to draft-ietf-roll-trickle-mcast.  I've attached a draft of the proposed text.  Note that we will *not* be presenting this draft at the ROLL WG meeting.
> 
> In a prior mail, I noted some deficiencies with the initial draft that was posted.  We will discuss some of these deficiencies at the ROLL WG meeting today.  The purpose of this mail is to give you some insight into solving those deficiencies as well as incorporating suggestions that were brought up on the list.  If you get a chance to glance through before the WG meeting, great.  In either case, let's continue the discussion on the list.
> 
> Always looking for your feedback, especially from implementors.
> 
> Thanks!
> 
> --
> Jonathan Hui
> 
> 
> ________________________________
> 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.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll