Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

Don Sturek <> Thu, 01 November 2012 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 855D521F8230 for <>; Thu, 1 Nov 2012 06:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.086
X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v0Y1TVS91bCl for <>; Thu, 1 Nov 2012 06:14:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E46B521F86F3 for <>; Thu, 1 Nov 2012 06:14:46 -0700 (PDT)
Received: from [] by with NNFMP; 01 Nov 2012 13:14:46 -0000
Received: from [] by with NNFMP; 01 Nov 2012 13:14:46 -0000
Received: from [] by with NNFMP; 01 Nov 2012 13:14:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1351775686; bh=S2sx+NNDYwrGriNjlSAZ8SopRyagywVU9eT2Cf493aQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=PCkBXpX83I2qNj9c8zwQsr3qjEq+uJPTivY1dVBQ0A/JmythaSqH0kPw4/qaL6abjTaTUK10Ff04FV+Te4JdfreQJVoG4bDmzMHYRvGRRLYL1Gdap9nROOELv9d6/KQx/liWfzy98kzVobdVAe3OmN6W9xiKnOOuwPhgxpRZzUI=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 76tAW1YVM1nHe49uoN8OG9KRnSfxIaWJAkLMt0vzqSwqglK 0eQe6T0y_3LrZHf1UuzkgCGJgYM28wB9fHEMM2lECBxGVOF_SNPlMxiDpOgi _TO4Z8h79V__LvUHUpk31gCqKa4Xk0WBTDeTGJ2GkfHv1SWth6NvQxokM37n LCIM7qe7Pq6mCMHBzr8Yg4NZ2U.MyDX2kj8bKaIbWxA3WeSC0UHTCk86pxXL qmce2TWRZmdDZdvL0fc9Sh0cCTL_tWTEbETRsnjjho_zkuW.RHreBadbXMHZ fGDlaDi0D6JYNOCdBbl3JLKBvL3tljhWECnsEpdxVlea9lSiXBqzEShdG0K9 ZWtAFKT2qbtfvPqq.cMu1mfC9CGHR.sDKP3sA.aimtuuuG11_c_wEoCq6I6Y N8A2FK_K_Dk5.a92Y0sGJsdUG7IL10GbmZCA5dCdCX5X2bvdXJynVD0vIwLI Cq2wGSMnEIcMvIQ6LCEYX9ax_38X.UXnffkmG
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [] (d.sturek@ with login) by with SMTP; 01 Nov 2012 06:14:46 -0700 PDT
User-Agent: Microsoft-MacOutlook/
Date: Thu, 01 Nov 2012 06:13:26 -0700
From: Don Sturek <>
To: "Dijk, Esko" <>, "" <>, "" <>
Message-ID: <>
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3434595284_109971"
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Nov 2012 13:15:01 -0000

Hi Esko,

I think much of what you write about below should be the subject of a
different I-D.

Back at an IETF a few years ago, we submitted a draft to v6ops that became
part of the problem statement for homenet.   One topic that I have not seen
addressed is how to determine the boundaries of a site scope multicast
(related to your point on configuring the border router for multicast
traffic).   I still think such a draft would be useful.

Also, the second paragraph might also be the subject of another interesting
I-D (perhaps for homenet).


From:  "Dijk, Esko" <>
Date:  Thursday, November 1, 2012 5:26 AM
To:  "" <>,
"" <>
Subject:  Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

Hi Robert,
these are very useful diagrams.  I just wanted to point out for page 6,
³Site local multicast originating externally², that there is probably also
configuration required (in the BR) of what multicast traffic is allowed by
the BR onto the LLN.  I assume that not all multicast traffic from the
high-speed backbone network should be forwarded onto the LLN into the MPL
domain as that could lead to congestion?
As  a side note, this configuration would not be needed if we would have an
equivalent of the MLD protocol , to let LLN nodes announce their interest in
specific multicast groups.  One specific solution (in case the BR is also an
RPL DODAG root) is for nodes to use standard RPL DAOs containing multicast
addresses of interest, to advertize the multicast groups of interest to the
BR which can then automatically set up the Œfiltering rules¹. But this is
probably beyond the current MPL spec ;-)

From: [] On Behalf Of
Robert Cragie
Sent: Thursday 1 November 2012 9:31
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully
help to illustrate some of the thought processes we went through when
implementing and testing between the ZigBee IP vendors (comments welcome).
Apologies in advance for the PDF format but ASCII art would have been
difficult :-)


On 31/10/2012 11:22 PM, Dario Tedeschi wrote:
> Yes, I'd like to try clarify why link-local scope was suggested for the
> *outer* header. The reasons were:
> 1. Link-local scope is the only scope where the boundaries are well defined
> (i.e. on the link). Higher scopes are not well-defined and can cover wide
> domains depending on network configuration and administration.
<RCC>I agree and made essentially the same comment re. higher scopes.</RCC>

1. With a higher scope, there is a chance that non-MPL aware routers may
simply forward encapsulated multicast datagrams (MPL HbH option and all). We
wouldn't want MPL datagrams to leak outside of an MPL domain.
<RCC>Which is why I think the encapsulation rules do need to be pretty
specific. If link-local encapsulation is always used then providing the MPL
forwarder rules are clear, the MPL domain is then entirely bounded by the
MPL forwarders and there is no question regarding address scope and
administration thereof. This cleanly covers Peter's case as well where he
wants to forward into another PAN - it would be processed internally as an
original non-MPL packet and then be "launched" into the other PAN using LL
encapsulation for that PAN. Using other scopes for the outer header would
still work but then there is the issue of administering the scope. However,
this would need to be done in the case where no encapsulation is done

1. A higher scope complicates the forwarding logic that needs to be
implemented in an MPL router. The complication comes when a router receives
an MPL datagram and needs to figure out whether to decapsulate or not.
Granted, the use of an MPL group would mitigate this problem to a degree,
but link-local scope would make the decision to decapsulate very obvious and
<RCC>I think it would have to be effectively decapsulated at every router
anyway irrespective of the scope of the outer header to see if it needs to
be processed - it is the inner header which counts there and the comments
about multicast groups come into play in that discussion. But I agree using
link-local makes that decision easy and somewhat clearer</RCC>

1. In conjunction with 3. Link-local scope also makes it easier for an MPL
router to determine if the inner multicast address is one that a higher
layer (or an app) may be interested in.
<RCC>Agree that the rules are clearer for link-local</RCC>

Hopefully I haven't made things more confusing.

<RCC>Perish the thought ;-)</RCC>

- Dario

On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote:
Hi Peter,
The current draft does not place any restrictions on the MPL multicast
If the LLN border router is an MPL forwarder, it can forward MPL multicast
packets between different MPL multicast scope zones.  To be explicit, if the
original multicast packet's destination address has link-local scope, the
MPL forwarder should not forward the packet again.  If the original
multicast packet's destination has a scope larger than the MPL multicast
scope, then the MPL forwarder needs to forward the packet to other MPL
multicast scope zones (which may or may not involve different interfaces).
Does that address your question?
Jonathan Hui
On Oct 31, 2012, at 3:54 AM, peter van der Stok <>
<>  wrote:
> Hi Jonathan,
> To be absolutely sure: the MPL multicast scope can be link-local, ULA or
> site-local? meaning the LLN border router can be a MPL forwarder?
> In the latter case the LLN border router can forward link-local multicast from
> one interface to another?
> Greetings,
> peter
> Jonathan Hui (johui) schreef op 2012-10-30 18:27:
>> Yes, a goal of the current draft is to support both cases (use of
>> IPv6-in-IPv6 encapsulation or not).
>> The intent is as follows:
>> 1) If the source of the multicast packet is within the MPL forwarding
>> domain and the destination has a scope equal to or smaller than the
>> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.
>> 2) If the source of the multicast packet is outside the MPL
>> forwarding domain or the destination has scope greater than the MPL
>> multicast scope, then IPv6-in-IPv6 encapsulation is required.  When
>> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
>> multicast address with scope = MPL multicast scope is used as the
>> destination address in the outer header.
>> As mentioned in my other email, IPv6-in-IPv6 encapsulation is
>> required if you want to use the IPv6 Destination Address to identify
>> MPL forwarding scope zones.
>> Of course, this brings up Dario's practical point of how to configure
>> the MPL multicast scope if we allow that to dynamically change.  He
>> proposes a simplifying suggestion of requiring IPv6-in-IPv6
>> encapsulation for all non-link-local multicasts.  In other words,
>> setting the MPL multicast scope to link-local.
>> Thoughts?
>> --
>> Jonathan Hui
>> On Oct 30, 2012, at 4:46 AM, Don Sturek <>
>> <>  wrote:
>>> Hi Peter,
>>> I still need to read the latest draft so take what I say here with that in
>>> mind......
>>> I was hoping that we could support not using IP in IP tunneling if the
>>> scope of the multicast transmission was only within the multi-link subnet
>>> managed by the border router.   I was hoping that only transmission
>>> emanating from outside the multi-link subnet, received at the border
>>> router, with scope that includes the devices in the multi-link subnet
>>> would require IP in IP tunneling (and vice versa in terms of multicasts
>>> generated in the multi-link subnet with scope outside).  I haven't yet
>>> read the draft carefully to know if this is possible.
>>> Don
>>> On 10/30/12 1:34 AM, "peter van der Stok" <>
>>> <>  wrote:
>>>> Hi Don,
>>>> and more specifically under which conditions. That gives the
>>>> possibility to choose the conditions such that the encapsulation is not
>>>> needed.
>>>> Don Sturek schreef op 2012-10-29 16:56:
>>>>> Hi Peter,
>>>>> I think your suggested changes to the Trickle Multicast draft point
>>>>> out
>>>>> why IP in IP tunneling is needed.
>>>>> Don
>>>>> On 10/29/12 3:44 AM, "peter van der Stok" <>
>>>>> <>  wrote:
>>>>>> Dear WG,
>>>>>> Attached my suggestions for text modifications including some nits. I
>>>>>> used the facilities of word to edit and comment text with traces.
>>>>>> When writing text about MC scope and MC domain, I was puzzled by the
>>>>>> all MPL forwarders multicast address which removes the possibility to
>>>>>> address a given multicast group. We expect multiple (possibly
>>>>>> disjunct)
>>>>>> MC groups in our wireless networks.
>>>>>> Also I failed to understand why encapsulation was necessary once the
>>>>>> message was received by the seed.
>>>>>> To make it possible to configure the interface with one MC scope I
>>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast
>>>>>> Addresses (RFC 3306).
>>>>>> Probably, I overlooked many aspects which make the suggestions
>>>>>> impractical, but I hope that the intention is clear.
>>>>>> Peter van der Stok
>>>>>> Michael Richardson schreef op 2012-10-25 23:30:
>>>>>>> I suggest that you propose specific text to the list to modify the
>>>>>>> document.
>>>>>> _______________________________________________
>>>>>> Roll mailing list
>>> _______________________________________________
>>> Roll mailing list
Roll mailing list

Roll mailing list

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.
_______________________________________________ Roll mailing list