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

From: peter van der Stok <[email-masked]>
Date: Mon, 03 Feb 2014 11:23:30 +0100

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 <[email-masked]> 
> 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
>> [email-masked] mailing lists by 2014-02-07. Exceptionally, comments may 
>> be
>> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Axel Colin de Verdière <[email-masked]>
Date: Sat, 8 Feb 2014 01:26:50 +0100

Hello,

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.

- 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).

- 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?

Thank you,

Axel

Le 3 févr. 2014 à 11:23, peter van der Stok <[email-masked]> a écrit :

> raised during the WG last call concerning our applications, have been addressed adequately.
> 
> peter van der stok
> 
>> On Jan 24, 2014, at 3:16 PM 1/24/14, The IESG <[email-masked]> wrote:
>>> The IESG has received a request from the Routing Over Low power and Lossy
>>> 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
>>> [email-masked] mailing lists by 2014-02-07. Exceptionally, comments may be

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Feb 2014 20:40:05 -0000

Hi Axel,

Some slight rolling of eyes as this I-D has been through plenty of reviews and
last calls, but in the end we appreciate all review comments however and
whenever.

Hoping the authors will generate an answer for you soon.

Thanks,
Adrian

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Axel Colin de Verdière
> Sent: 08 February 2014 00:27
> To: [email-masked]; Routing Over Low power and Lossy networks
> Subject: Re: [Roll] Last Call: <draft-ietf-roll-trickle-mcast-06.txt>
(Multicast
> Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard
> 
> Hello,
> 
> 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.
> 
> - 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).
> 
> - 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?
> 
> Thank you,
> 
> Axel
> 
addressed
> adequately.

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:03:00 +0000

Hi Axel,

Thanks for your review and comments.  See my comments below:

> - 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…

Good point.  If there are no objections, I can remove this RECOMMENDED statement.

> - 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 forwarde…

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 recei…

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

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 10 Feb 2014 14:44:36 -0500

Hi Jonathan,

I apologize for the fact that these comments/questions are late but offer
them anyway...

3. Applicability Statement

OLD:

   Operationally, the scope of this protocol is administratively
   determined.  In other words, the scope of dissemination is determined
   by routers configured to disallow transmission or reception of MPL
   messages on a subset of interfaces.

This language predates the alignment with I-D.ietf-6man-multicast-scopes
and I suspect
it is no longer generally true.  I recommend deleting it.

4.1.  MPL Domains

OLD:

   When MPL is used in deployments that use administratively defined
   scopes that cover, for example, multiple subnets based on different
   underlying network technologies, Admin-Local scope (scop value 4) and
   /or Site-Local scope (scop value 5) SHOULD be used.

I'm not clear on whether, in deployments where scop values 4 and/or 5 are
in use, a node
should participate in the ALL_MPL_FORWARDERS multicast address for each
multicast
scope in use or just the highest scope in use.

5.4  MPL Forwarder Parameters

OLD:

   PROACTIVE_FORWARDING  A boolean value that indicates whether the MPL
      Forwarder schedules MPL Data Message transmissions after receiving
      them for the first time.  It is RECOMMENDED that all MPL
      Interfaces attached to the same link of a given MPL Domain use the
      same value for PROACTIVE_FORWARDING and has a default value of
      TRUE.  The mechanism for setting PROACTIVE_FORWARDING is not
      specified within this document.

   SEED_SET_ENTRY_LIFETIME  The minimum lifetime for an entry in the
      Seed Set.  SEED_SET_ENTRY_LIFETIME has a default value of 30
      minutes.  It is RECOMMENDED that all MPL Forwarders use the same
      value for SEED_SET_ENTRY_LIFETIME for a given MPL Domain and has a
      default value of 30 minutes.  The mechanism for setting
      SEED_SET_ENTRY_LIFETIME is not specified within this document.

NEW:

      ...
      PROACTIVE_FORWARDING has a default value of TRUE.

      ...
      It is RECOMMENDED that all MPL Forwarders use the same
      value for SEED_SET_ENTRY_LIFETIME for a given MPL Domain and *use* a
      default value of 30 minutes.

I think you were already planning to delete the RECOMMEND that all MPL
Interfaces
on the same link use the same value for PROACTIVE_FORWARDING.  The second
suggestion is just grammatical.

Regards, -K-

---

From: Ines Robles <[email-masked]>
Date: Tue, 11 Feb 2014 11:00:01 -0200

Thank you Kerry for your comments,

It will be addressed by the authors.

Kind Regards,

---

From: Axel Colin de Verdière <[email-masked]>
Date: Wed, 12 Feb 2014 01:05:18 +0100

Hi Jonathan,

Thank you for your reply. See inline:

> 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 un…

Alright, got it, thanks.

> 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 t…

I understand that, I just did not fully grasp the formulation in the draft. In clear, I don't get why this text:

When transmitting an MPL Data Message, the MPL Forwarder MUST either
   set the M flag to zero or set it to a level that indicates whether or
   not the message's sequence number is the largest value that has been
   received from the MPL Seed.

Is not simply formulated this way:

When transmitting an MPL Data Message, the MPL Forwarder MUST
   set the M flag to a level that indicates whether or
   not the message's sequence number is the largest value that has been
   received from the MPL Seed.

The text from the draft seems to indicate that the M flag can be arbitrarily set to zero, or set to the proper value indicating the state of the forwarder.

Axel

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Wed, 12 Feb 2014 09:45:36 +0000

Hi Axel, see below:

On Feb 12, 2014, at 1:05 AM, Axel Colin de Verdière <[email-masked]<mailto:[email-masked]>> wrote:

Le 10 févr. 2014 à 15:03, Jonathan Hui (johui) <[email-masked]<mailto:[email-masked]>> a écrit :

On Feb 8, 2014, at 1:26 AM, Axel Colin de Verdière <[email-masked]<mailto:[email-masked]>> wrote:

The text is written to allow one to reduce MPL to a simple flood with packet caching to avoid receiving a packet more than once.  In this case, there is no real need to maintain the largest sequence number.

—
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Wed, 12 Feb 2014 13:31:50 +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

> 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>