From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Jonathan Hui (johui)" <johui@cisco.com>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: AQHNrh4EBfIsegKOz0GvSDMMHJeV6pfA4wQAgBKnvHA=
Date: Wed, 31 Oct 2012 15:37:52 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B09936@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <20121019171938.9893.94358.idtracker@ietfa.amsl.com>
 <B50D0F163D52B74DA572DD345D5044AF0F6B0E7C@xmb-rcd-x04.cisco.com>
In-Reply-To: <B50D0F163D52B74DA572DD345D5044AF0F6B0E7C@xmb-rcd-x04.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Precedence: list

Hi Jonathan,

besides the points you mentioned, I see 3 more topics which are not yet dis=
cussed:

1. Selection of the link-local all-nodes MPL forwarders multicast address.
When IPv6-in-IPv6 encapsulation is applied, the "all-MPL-forwarders" MC add=
ress 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 addre=
ss when the multicast Group ID is in the range 0x00-0xFF. Therefore we shou=
ld put in the IANA allocation request (and in the IANA section in the I-D t=
oo) that we urgently request an allocation in this range. Going outside thi=
s range to Group IP 0x100 and up, will incur 4 bytes extra overhead. (An ex=
ample 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 mult=
icast 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 rece=
ive the packet from N1 (because N1 will send to either FF02::MPL or FF05::M=
PL). If MPL happens to not use encapsulation, node N2 will receive the pack=
et 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 t=
he RPL router can remove the HbH option. (RFC 6550 Section 11.2.2.1, "A rou=
ter that forwards a packet outside the RPL network MUST remove the RPL Pack=
et Information.") Is there a reason that MPL cannot do it the RPL way?

regards,
Esko


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon=
athan Hui (johui)
Sent: Friday 19 October 2012 19:32
To: roll@ietf.org
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 me=
eting and incorporates comments received since then (special thanks to Robe=
rt Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter v=
an der Stok).

The following are some open discussion items that were raised in the commen=
ts.  Would be great to hear your thoughts.

1) MPL multicast scope.  The current draft allows the MPL multicast scope t=
o be link-local scope or something larger.  On one hand, fixing the MPL mul=
ticast scope to be link-local reduces the number of options, makes things s=
impler, and improves interoperability. On the other hand, doing so will mak=
e IPv6-in-IPv6 encapsulation a MUST even when the source and destinations a=
re all in the MPL domain.

2) The S field.  The current draft includes an S field in the MPL Hop-by-Ho=
p Option to indicate the length of the seed identifier.  On one hand, the l=
ength 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 fie=
lds following the seed identifier field, that specification would need some=
 way to indicate the length of the seed identifier.  The S field was origin=
ally 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 draf=
t.  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 fiel=
d 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, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Routing Over Low power and Lossy network=
s Working Group of the IETF.
>
>       Title           : Multicast Protocol for Low power and Lossy Networ=
ks (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=3Ddraft-ietf-roll-trickle-mcast-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.