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

"Jonathan Hui (johui)" <> Wed, 31 October 2012 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39D7921F8668 for <>; Wed, 31 Oct 2012 09:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.294
X-Spam-Status: No, score=-8.294 tagged_above=-999 required=5 tests=[AWL=-2.305, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8, SARE_URGBIZ=0.725, URG_BIZ=1.585]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xGlzjC6iwKYB for <>; Wed, 31 Oct 2012 09:18:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 720CB21F8667 for <>; Wed, 31 Oct 2012 09:18:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2644; q=dns/txt; s=iport; t=1351700333; x=1352909933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e+H4jeRjFB8uDtNWDX4ZFl53y3SGybP1BFPKa4iHNSY=; b=PCfTHFAhi9cDJvCqMw4owi2kk8ki1zWjBz+0Rg1ZK+x1jAv+HMZiIdoE QxjMPm0vSxiDEzOWt3NCGMJAPVGiat0ths3kNvaik/0cKyhV0QvWh90xy CzpTtFE36xiFdWPVcWXXpJHQh5tqoWBUNgEprZWpyowQ2udjnSNjKvRf/ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANdOkVCtJXG8/2dsb2JhbAA/BcNvgQiCHgEBAQMBEgEnPwULAgEIIhQQMiUCBA4FCBqHXgacSKAVi3gohTJhA5JEkgmBa4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137373292"
Received: from ([]) by with ESMTP; 31 Oct 2012 16:18:53 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q9VGIqAg003568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:18:53 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:18:52 -0500
From: "Jonathan Hui (johui)" <>
To: "Dijk, Esko" <>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: AQHNrh+gRb5TlPk7pUqtIMGVkE0DSw==
Date: Wed, 31 Oct 2012 16:18:52 +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--32.406400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " WG" <>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
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: Wed, 31 Oct 2012 16:18:54 -0000

Hi Esko,

On Oct 31, 2012, at 8:37 AM, "Dijk, Esko" <> 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, "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