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

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

Hi Jonathan,

besides the points you mentioned, I see 3 more topics which are not yet discussed:

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

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?

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?

regards,
Esko


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jonathan Hui (johui)
Sent: Friday 19 October 2012 19:32
To: [e-mail]
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt


ROLL WG,

This update includes the new text that was sent out during the last IETF meeting and incorporates comments received since then (special thanks to Robert Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter van der Stok).

The following are some open discussion items that were raised in the comments.  Would be great to hear your thoughts.

1) MPL multicast scope.  The current draft allows the MPL multicast scope to be link-local scope or something larger.  On one hand, fixing the MPL multicast scope to be link-local reduces the number of options, makes things simpler, and improves interoperability. On the other hand, doing so will make IPv6-in-IPv6 encapsulation a MUST even when the source and destinations are all in the MPL domain.

2) The S field.  The current draft includes an S field in the MPL Hop-by-Hop Option to indicate the length of the seed identifier.  On one hand, the length of the seed identifier may be inferred by the Opt Data Len field.  On the other hand, if any future specification wants to define additional fields following the seed identifier field, that specification would need some way to indicate the length of the seed identifier.  The S field was originally included to allow the possibility of something like sub-TLVs, that are extensively used throughout RPL.

3) Supporting different Trickle parameter sets.  The latest draft removes a flag that indicates which of two parameter sets to use when disseminating MPL multicast packets.  We removed the flag in attempt to simplify the draft.  Furthermore, it wasn't clear that a single flag (2 parameter sets) was sufficient.

4) Version number field.  The current draft does not include a version field in the MPL Hop-by-Hop Option.  Instead, it sets all reserved bits to zero and requires all devices that implement this draft to drop the message if any of those bits are non-zero.

--
Jonathan Hui

On Oct 19, 2012, at 10:19 AM, [e-mail] wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.
>
>       Title           : Multicast Protocol for Low power and Lossy Networks (MPL)
>       Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
>       Filename        : draft-ietf-roll-trickle-mcast-02.txt
>       Pages           : 24
>       Date            : 2012-10-19
>
> Abstract:
>   This document specifies the Multicast Protocol for Low power and
>   Lossy Networks (MPL) that provides IPv6 multicast forwarding in
>   constrained networks.  MPL avoids the need to construct or maintain
>   any multicast forwarding topology, disseminating messages to all MPL
>   forwarders in an MPL domain.  MPL uses the Trickle algorithm to drive
>   packet transmissions for both control and data-plane packets.
>   Specific Trickle parameter configurations allow MPL to trade between
>   dissemination latency and transmission efficiency.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll

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