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

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 3 Aug 2012 17:48:11 +0000

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 27 Aug 2012 13:45:42 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui (johui)
Sent: Friday 3 August 2012 19:48
To: [email-masked]
Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text)

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.

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 31 Aug 2012 07:41:12 -0700

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:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 31 Aug 2012 10:37:58 -0700

I have several comments listed below:

1. Why is the S field needed when the seed's length can be determined by 
the Opt Data Len field?

2. Nodes that do not understand the Trickle Multicast option should 
*not* process the packet further. This is to ensure those nodes do not 
cause packet storms or pass multiple copies of the same multicast 
datagram to higher layers.

3. Consider setting the two high order bits in the option type to b01 
(discard the packet). This would be consistent with RFC 6553 and satisfy 
my comment 2.

4. Using the source IPv6 address as the seed won't work for hop-by-hop 
"tunneling", because the outer source address changes at each hop.

5. Exactly how is consistency/inconsistency used in the proactive mode? 
It doesn't seem to be explained anywhere.

6. For consistency, interoperability and implementation simplicity 
consider stipulating one scope used for the outer header (i.e. 
link-local scope).

7. Ideally, a link-local multicast group assigned to MPL should be used 
in the outer destination to ensure that only MPL aware nodes receive MPL 
encapsulated datagrams. An MPL multicast group would clearly define the 
boundaries of an MPL domain.

- Dario