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

"Jonathan Hui (johui)" <> Thu, 01 November 2012 04:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E74821F85DA for <>; Wed, 31 Oct 2012 21:59:38 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7MT60vpRHDWt for <>; Wed, 31 Oct 2012 21:59:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C2D121F85D2 for <>; Wed, 31 Oct 2012 21:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3057; q=dns/txt; s=iport; t=1351745977; x=1352955577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mC8KaBVWTNYPSqlz0Z+Yi15EHdgwUfJMHLAv3QLMpbg=; b=ThELkhhfp3eauGhaPzoF5mItOvjo3BYdVPxN5dlyiQfkgKpD83YzBUWZ 38YSUDmclXzNg47L/lzMm58QtCdSQBUzt7VjQNuVx4pQyla4uiQBBe0S7 JVjqv/yQcNcOt5+9ojjIoGT8gOYTFt9b6lW+OMn1bHcCqobTE5qGTOuvY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAIMAklCtJXG8/2dsb2JhbAA6CsNlgQiCHgEBAQMBEgEnPwULAgEIIhQQMiUCBA4FCBMHh14GmxegIot7EIVKYQOkToFrgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,691,1344211200"; d="scan'208";a="137657485"
Received: from ([]) by with ESMTP; 01 Nov 2012 04:59:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qA14xa8e027813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 04:59:36 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 23:59:36 -0500
From: "Jonathan Hui (johui)" <>
To: "Reddy, Joseph" <>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: AQHNt+2vRb5TlPk7pUqtIMGVkE0DSw==
Date: Thu, 01 Nov 2012 04:59:35 +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--31.032300-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: "" <>
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: Thu, 01 Nov 2012 04:59:38 -0000

Hi Joseph,

Comments below:

On Oct 31, 2012, at 5:00 PM, "Reddy, Joseph" <> wrote:

> Here are some comments on the trickle multicast draft rev-02
> 1. MPL multicast scope:
> I think fixing it to link-local is too restrictive as it will force encapsulation even when it is not needed. 
> Regarding the practical aspects of determining the MPL scope, I think that can be left to "administrative configuration". Other multicast details (e.g., the zone boundaries for scopes greater than link local) have to be administratively configured anyway.

I agree that it is desirable to avoid encapsulation when possible.

There is an important difference depending on whether encapsulation is used:

1) With encapsulation, the IPv6 Destination Address of the outer header explicitly identifies the MPL scope zone.

2) Without encapsulation, the IPv6 Destination Address identifies the endpoints that should process the IPv6 payload.  However, the IPv6 Destination Address may not explicitly identify the MPL scope zone.  Instead, the IPv6 Source Address identifies the MPL scope zone.  It is easy to determine the scope zone if we require the separation to occur across interface boundaries (just observe what interface the message came in on).  However, it is not so easy to determine the scope zone if we want a single interface to service more than one MPL scope zone.  I believe the latter case is what Peter is looking for.  One solution is to require the IPv6 Destination Address to also identify MPL forwarders that will forward the message.  Another solution is to include an MPL domain/instance identifier in the MPL Option.  Yet another solution is to eliminate this case and always require encapsulation.

> 2. Supporting different Trickle parameter sets:
> I think this is a useful feature and should be included even if it is a single flag (2 parameter sets). Typical use cases for multicast in LLN's try to achieve either high reliability or low latency and having two sets of trickle parameters for each of them should help

Any feedback from others in the WG on this?  Should we include support for selecting 1, 2, or more parameter sets?

> 3. Version field:
> I think adding an explicit version field ( 2 bits should be enough) will help.

OK.  Any additional inputs from the WG?

> 4. Destination address:
> Is there a reason to restrict the destination address of the MPL packet to the "all-MPL-forwarders" multicast address? Nodes that receives an MPL packet but don't understand the MPL option will discard it anyway.

I think the most compelling reason is to remove yet another configuration parameter.  But allowing arbitrary multicast addresses to identify MPL forwarders would be necessary to support multiple MPL scope zones using the IPv6 Destination Address.  If we require encapsulation with link-lcoal multicast, then an all-MPL-forwarders address would be ok.


Jonathan Hui