Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones

"Jonathan Hui (johui)" <> Fri, 02 November 2012 03:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04DE321F86A5 for <>; Thu, 1 Nov 2012 20:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wrYbLls-I6S8 for <>; Thu, 1 Nov 2012 20:18:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 18D9221F86A3 for <>; Thu, 1 Nov 2012 20:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2227; q=dns/txt; s=iport; t=1351826307; x=1353035907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Q2RaN8ve7ju0HfLTkUfCbbs6IZjJbsF4M0EWWGeXWo=; b=lcz1lgUuhXU0e9ARwTcHLeDvkNE+JdV7jxirfUlWRoX9YEcPR7VDe9W3 phriNTjUY+PEUJ8J8YXD0twJvwBVBXug65nubqSfgLRc8VKriBrCiVUjj UzVi37N/h0tAIIb7HeDz4lDpQDo+ozU0LADaTAFqGWEaAQCVfZ+c93Zt0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,696,1344211200"; d="scan'208";a="137986396"
Received: from ([]) by with ESMTP; 02 Nov 2012 03:18:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qA23IQ55027609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 03:18:26 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 22:18:26 -0500
From: "Jonathan Hui (johui)" <>
To: "<>" <>
Thread-Topic: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones
Thread-Index: AQHNuEspMgZUiTBCAUyZhLDpCxipTQ==
Date: Fri, 2 Nov 2012 03:18:25 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--33.713900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " WG" <>
Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones
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: Fri, 02 Nov 2012 03:18:28 -0000

Hi Robert,

On Nov 1, 2012, at 6:04 PM, Robert Cragie <>; wrote:

> On 01/11/2012 6:51 PM, Jonathan Hui (johui) wrote:
>> I'm not sure I follow you.  If we require MPL forwarders to drop packets sent to FF0X::MPL and do not contain an MPL Option, how do we expect one to encapsulate it for forwarding within the MPL domain?
> <RCC>I wasn't suggesting that. If you look at the definitions I suggested, any original non-MPL multicast packet is always encapsulated, not dropped, irrespective of its destination address (unless link local, which is never likely to happen).</RCC>

Ah, OK.  I believe we are in agreement.  That is consistent with what I meant in my original statement: "if any device sends a packet to FF0X::MPL, it should be delivered to and processed by all devices subscribed to that address."  And to further clarify my statement, the delivery occurs with encapsulation if the source did not include an MPL Option.

>> I suggested in another email that encapsulation be required unless the IPv6 Destination Address be equal to FF0X::MPL.  If it is anything else, then encapsulation is required.
> <RCC>I was saying that the FF0X::MPL address should also have an accompanying MPL option otherwise if a MPL forwarder encountered an original non-MPL multicast packet with destination address FF0X::MPL, it would (probably) end up encapsulating it.</RCC>

In agreement here as well.

>> Also, since Peter would like to use unicast prefix-based multicast addresses, there is a one-to-one mapping between the MPL domain and the (address scope, group identifier) tuple.
> <RCC>That seems to make sense but I would like to see some more details on that proposal</RCC>

How about defining an MPL domain in this manner:

1) MPL multicast address: An IPv6 multicast address of arbitrary scope used by MPL forwarders to communicate with other MPL forwarders in the same scope zone of the IPv6 multicast address.

2) MPL domain: A connected set of interfaces subscribed to the same MPL multicast address within the scope zone of that IPv6 multicast address.


Jonathan Hui