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

["Dijk, Esko" <[e-mail]>]

Hi,

> the Option Type to '01', which indicates the receiver must drop the packet
My mistake - I had the version -00 draft opened, hence looking at '00' bits.

There's still the case that multicasts from non-MPL nodes are received by MPL-forwarder-nodes (presumably). Should there be guidelines here? Example: if an application on my MPL-forwarder node joins multicast group FF05::1234, will the application then receive IP multicasts sent with destination FF05::1234, or will it only receive those IP multicasts to FF05::1234 that were delivered encapsulated in an FF0X::MPL packet ?

That decision could be out of scope; but on the other hand may lead to different implementers making different choices here.

Esko

-----Original Message-----
From: Jonathan Hui (johui) [mailto:[e-mail]]
Sent: Wednesday 31 October 2012 17:19
To: Dijk, Esko
Cc: [e-mail] WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt


Hi Esko,

On Oct 31, 2012, at 8:37 AM, "Dijk, Esko" <[e-mail]> wrote:

> 1. Selection of the link-local all-nodes MPL forwarders multicast address.
> When IPv6-in-IPv6 encapsulation is applied, the "all-MPL-forwarders" MC address will be used a lot. A typical use case of MPL is in 6LoWPAN networks. It has best header compression of link-local IP multicast destination address when the multicast Group ID is in the range 0x00-0xFF. Therefore we should put in the IANA allocation request (and in the IANA section in the I-D too) that we urgently request an allocation in this range. Going outside this range to Group IP 0x100 and up, will incur 4 bytes extra overhead. (An example of a successful earlier registration in the 00-FF range is mDNS FF0X::FB).

Agree.  Will include in the next revision.

> 2. Warn against mixing MPL-forwarders with non-MPL-nodes in the same LLN.
> Mixing MPL-forwarders with non-MPL-nodes (that e.g. listen to specific multicast traffic) may lead to unpredictable behavior. For example, an MPL node N1 application sends to FF05::1234, and a non-MPL neighbor node N2 listens to FF05::1234. If MPL does use encapsulation, then node N2 will never receive the packet from N1 (because N1 will send to either FF02::MPL or FF05::MPL). If MPL happens to not use encapsulation, node N2 will receive the packet from N1.
> So depending on the encapsulation decision different nodes may get/not get the packet - is this intentional?
> If not we should warn for this situation, perhaps?

In both cases, the MPL multicast packet must contain the MPL Option.  The current draft sets the highest-order bits in the Option Type to '01', which indicates the receiver must drop the packet if it does not understand the MPL Option.  So non-MPL-nodes should not receive MPL Multicast packets.

> 3. Motivation for requiring encapsulation: MPL vs RPL
>   " 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."
> It seems RPL does not use IPv6-in-IPv6 encapsulation but just states that the RPL router can remove the HbH option. (RFC 6550 Section 11.2.2.1, "A router that forwards a packet outside the RPL network MUST remove the RPL Packet Information.") Is there a reason that MPL cannot do it the RPL way?

RFC 6553, which specifies the RPL Option, requires the use of IPv6-in-IPv6 encapsulation, unless the source and destination are known to be within the same RPL Instance.

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