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

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

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