[Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

["Dijk, Esko" <[e-mail]>]

Hi Jonathan,

please find below my further review comments for the new MPL-03 draft. None of these would affect current implementations, with the exception maybe of the comment for Section 6.3 page 14.
I hope this helps to improve the text.

Esko


Section 2.
- "Seed Identifier" could be added here (as I noted before). I'm wondering whether one MPL Forwarder incorporates multiple Seeds (for different Domains); or that there's only one Seed per Forwarder but with this Seed storing potentially multiple Seed IDs. (At most one Seed ID per Domain it participates in in a Seed role.) For an implementation this definition issue may not be even relevant, though...

Section 4.2
- the first bullet could mention that the generated MPL Data Message is also multicast. Rationale: other bullets also explicitly mention when messages are multicast (i.e. transmitted).

Section 4.3, pg. 8
- "minimum threshold maintained in the Seed Set." ->
It seems "minimum threshold" should be "minimum sequence number"? If not, what is the threshold?

Section 5
- title: would  be better "MPL Parameters" or "MPL Parameters and Constants" since most of the definitions are not constants. If updated, also the intro text should be updated.
- the MPL Seed Identifiers could be added , e.g. to 5.1. Each MPL Domain needs to have a Seed ID configured in case the MPL Forwarder acts as a Seed for that Domain.
- maybe to add that setting of parameters is out of scope (since RFC 6206 RECOMMENDS to define such mechanisms - a reader may expect such mechanisms in MPL?)

Section 5.3
- both parameters are defined but their syntax/name not further used in the protocol description. To be fixed?
- just wondering if default values here would be appropriate?
- do we allow PROACTIVE_FORWARDING and SEED_SET_LIFETIME to be set per MPL Domain, or not? (there seems to be no reason to disallow per-domain setting as Domains are cleanly separated)

Section 6.1
- editorial "MPL Options received in which this flag is 1 MUST be dropped" ->
  "Received Messages with MPL Option in which this flag is 1 MUST be dropped"?

Section 6.2
- The MLP Seed Info array must contain at least one MPL Seed Info entry. This can be a problem for MPL Forwarders that just started up with empty message buffers. When the Trickle timer fires, such Forwarder may need to send an MPL Control Message with 'empty' information in case it has no messages buffered yet.

Section 6.3, pg 13
- editorial "minimum sequence number for the MPL Seed maintained" ->
 "minimum sequence number for an MPL Seed maintained" ?
- "Data Messages generated by the MPL Seed within the Buffered Message Set" ->
  "Data Messages generated by the MPL Seed that are stored within the Buffered Message Set"

Section 6.3, pg 14
- S field text: "0 indicates that the seed-id value is the IPv6 Source Address" ->
  that would be a link-local address for a Control message, hence not usable as a SeedID in practice. For an MPL Data Message, a Forwarder would typically need to use its global IPv6 address as the IPv6 Source, hence also as the SeedID (when S flag is 0); so Seed IDs are defined in terms of global IPv6 addresses. Is this a spec error? I don't see how the S=0 for a MPL Control message could be made useful right now.

- editorial: text for 'buffered-mpl-messages' could (should?) point forward to section 11.1 where the meaning of 0/1 bits is specified.

Section 7.1
- Shouldn't the Local Interface Tuple contain an identifier of each interface? or was this left out because format of such IDs is implementation specific.
  (Interface ID, AddressSet)

Section 7.2
- Shouldn't the Domain Address be the first component of the MPL Domain Tuple?
  (Domain Address, MPLInterfaceSet)
  at least the Domain Address information should be stored somewhere per Domain, and it's not implementation-specific.
The present text already suggests of course that Domain Address is stored here so I'd expect it in the tuple too.

Section 7.3
- "Lifetime  - indicates the minimum lifetime of the Seed Set entry." ->
  "Lifetime  - indicates the minimum remaining lifetime of the Seed Set entry." ?
(since the minimum lifetime itself would be always equal to SEED_SET_LIFETIME?)

Section 10.1
- "when they enter" -> "when these messages enter" (otherwise ambiguous)

Section 11.2
- editorial "receiving nor transmitting node has new MPL Data Message." ->
  "receiving nor transmitting node has any new MPL Data Message to offer."



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jonathan Hui (johui)
Sent: Thursday 24 January 2013 17:14
To: [e-mail] WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt


This update addresses all of the open tickets in the following manner:

Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSAGE_TIMER_EXPIRATIONS to zero.

Ticket 104: Added security considerations text.

Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data Packet.

Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when multicast destination does not match MPL Domain Address.

Ticket 107: Multiple parameter sets are not supported at this time.

Ticket 108: Added explicit 1-bit version field.

Ticket 109: All MPL packets must be destined to the MPL Domain Address that identifies the MPL Domain.

Ticket 110: Not in scope.  If an application subscribes to an address, it should receive all packets destined to that address whether or not they were received in an MPL Data Packet.

--
Jonathan Hui

On Jan 24, 2013, at 8:09 AM, <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.
>
>       Title           : Multicast Protocol for Low power and Lossy Networks (MPL)
>       Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
>       Filename        : draft-ietf-roll-trickle-mcast-03.txt
>       Pages           : 29
>       Date            : 2013-01-24
>
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.