Re: [Roll] Last Call: <draft-ietf-roll-trickle-mcast-06.txt> (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard

Robert Cragie <robert.cragie@gridmerge.com> Wed, 12 February 2014 13:31 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC591A0086 for <roll@ietfa.amsl.com>; Wed, 12 Feb 2014 05:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ8G1jIDfZ6u for <roll@ietfa.amsl.com>; Wed, 12 Feb 2014 05:31:51 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5456F1A00EE for <roll@ietf.org>; Wed, 12 Feb 2014 05:31:51 -0800 (PST)
Received: from host86-156-114-191.range86-156.btcentralplus.com ([86.156.114.191] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WDZun-0005HM-DX for roll@ietf.org; Wed, 12 Feb 2014 13:31:49 +0000
Message-ID: <52FB77C6.4020800@gridmerge.com>
Date: Wed, 12 Feb 2014 13:31:50 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: roll@ietf.org
References: <20140124201637.988.3372.idtracker@ietfa.amsl.com> <4C62FB50-C8E8-4CEA-BD42-B64076883379@gmail.com> <0d753074c679b2f79f1ba4acb18cd7f3@xs4all.nl> <001AF5D9-5760-42D5-8BA9-4F421B39ACDA@axelcdv.com> <47541D76-F545-4088-A7D9-4D4E15061224@cisco.com>
In-Reply-To: <47541D76-F545-4088-A7D9-4D4E15061224@cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020707090803050803030704"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Subject: Re: [Roll] Last Call: <draft-ietf-roll-trickle-mcast-06.txt> (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 13:31:54 -0000

Isn't PROACTIVE_FORWARDING now a parameter per MPL Interface (based on 
the contested statement mentioned below, i.e. "It is RECOMMENDED that 
all MPL Interfaces ... use the same value for PROACTIVE)? Therefore 
section 5.4 should just be SEED_SET_ENTRY_LIFETIME and there should be a 
new section "MPL Interface Parameters"

Other comments inline.

Robert

On 10/02/2014 2:03 PM, Jonathan Hui (johui) wrote:
> Hi Axel,
>
> Thanks for your review and comments.  See my comments below:
>
> On Feb 8, 2014, at 1:26 AM, Axel Colin de Verdière <axel-ietf@axelcdv.com> wrote:
>
>> I've reviewed the draft, and I have a couple comments/questions if that's not too late:
>>
>> - I don't see why MPL forwarders on the same link should have the same value for PROACTIVE_FORWARDING. It is now RECOMMENDED to make it so, but I don't see the rationale for this recommendation: on the opposite, I think it would allow some forwarders with less power restrictions to be more proactive than others.
> Good point.  If there are no objections, I can remove this RECOMMENDED statement.
<RCC>
I agree it is not strictly necessary but there are certain combinations 
of parameters which won't work. For example, if proactive forwarding is 
used and the CONTROL_MESSAGE_TIMER_EXPIRATIONS is 0 then a MPL 
Forwarder's MPL Interface which doesn't use proactive forwarding may 
never forward a MPL Data Message on that interface as none of its 
neighboring MPL Forwarders will be sending MPL Control Messages.

I know Kerry had some concerns earlier regarding mutual exclusivity of 
proactive and reactive forwarding strategies. Introduce the wider scope 
through multiple interfaces and thus per-MPL Interface parameter sets 
makes sense but it brings in a new concept of grouping a strategy across 
a common set of MPL Interfaces to ensure forwarding applies correctly on 
those MPL Interfaces.
</RCC>
>
>> - Isn't there a risk that only specifying SEED_SET_ENTRY_LIFETIME without any kind of hysteresis mechanism lead to old Data messages being reinjected in the network? For example, if an MPL forwarder A resets its Control Message trickle timer with a seed (S) close to expiration, there is a risk that a neighbor forwarder that has expired that seed interprets the Control Message as A having new Data messages from seed S, thus resetting its timer for this seed and potentially retransmitting the corresponding Data message(s).
> The hysteresis is controlled using the DATA/CONTROL_MESSAGE_TIMER_EXPIRATIONS parameters.  The SEED_SET_ENTRY_LIFETIME should be much longer than these to help ensure that devices maintain state until the propagation has completed.
>
>> - In section 9.2, it is unclear when the M flag should be cleared or set: why would it be arbitrarily cleared and not indicate whether or not this message's sequence number is the largest one received?
> The M flag helps indicate whether a receiving node should reset its Trickle timer.  If the M flag is not set and the sequence number is lower than what is already known, there is no need to reset the Trickle timer.
>
> —
> Jonathan Hui
>
>> Thank you,
>>
>> Axel
>>
>> Le 3 févr. 2014 à 11:23, peter van der Stok <stokcons@xs4all.nl> a écrit :
>>
>>> I've reviewed draft-ietf-roll-trickle-mcast-06.txt.  The issues
>>> raised during the WG last call concerning our applications, have been addressed adequately.
>>>
>>> peter van der stok
>>>
>>> Ralph Droms schreef op 2014-01-27 16:58:
>>>> I've reviewed draft-ietf-roll-trickle-mcast-06.txt.  The issues I
>>>> raised during the WG last call have been addressed and, in my opinion,
>>>> the document is now ready for publication.
>>>> - Ralph
>>>> On Jan 24, 2014, at 3:16 PM 1/24/14, The IESG <iesg-secretary@ietf.org> wrote:
>>>>> The IESG has received a request from the Routing Over Low power and Lossy
>>>>> networks WG (roll) to consider the following document:
>>>>> - 'Multicast Protocol for Low power and Lossy Networks (MPL)'
>>>>> <draft-ietf-roll-trickle-mcast-06.txt> as Proposed Standard
>>>>> This is a second last call, the first one having been abandoned to send
>>>>> the document back to the working group. But the latest revision addresses
>>>>> comments that were received during the first last call.
>>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>>> final comments on this action. Please send substantive comments to the
>>>>> ietf@ietf.org mailing lists by 2014-02-07. Exceptionally, comments may be
>>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>>> beginning of the Subject line to allow automated sorting.
>>>>> 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
>>>>> manage message transmissions for both control and data-plane
>>>>> messages.  Different Trickle parameter configurations allow MPL to
>>>>> trade between dissemination latency and transmission efficiency.
>>>>> The file can be obtained via
>>>>> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
>>>>> IESG discussion can be tracked via
>>>>> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/
>>>>> The following IPR Declarations may be related to this I-D:
>>>>> http://datatracker.ietf.org/ipr/1858/
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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
>