Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt

From: [email-masked]
Date: Thu, 24 Jan 2013 08:09:07 -0800

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/

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 24 Jan 2013 16:13:36 +0000

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, <[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 19:58:49 +0100

Hi Jonathan,

I thank you and the authors for the update, looking forward to review,

AB

On 1/24/13, Jonathan Hui (johui) <[email-masked]> wrote:
> Ticket 103: MPL Control Messages may be disabled by setting
> CONTROL_MESSAGE_TIMER_EXPIRATIONS to zero.
>
> Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when
> multicast destination does not match MPL Domain Address.
>
> 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
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 28 Jan 2013 12:43:25 +0100

Hi Jonathan and Richard,

many thanks for the updated draft. It has enormously improved.
In particular I appreciate the way MPL domain is defined and 
implemented.

After a first reading, I do have some questions about the draft. 
Possibly I misinterpret the text.

If I understand correctly a node can be member of several MPL domains 
and subscribe to as many MPL Domain addresses.
Consequently a node can be seed to messages to more than one MPL 
domain.
This implies that a node can receive messages for different MPL domains 
coming from the same seed?

If that is possible (at page 6, sec 4.1) the seed set records and the 
buffered message records should record information about received MPL 
data messages received from an MPL seed << for a given MPL-domain. >>.   
within << xxx  >> my addition.

section 8 page 17.

an MPL forwarder MUST participate in an MPL domain identified by the 
ALL_MPL_FORWARDERS multicast address with scope value 3 (subnet local)
For each MPL domain Address that an MPL interface subscribes to, the 
MPL interface MUST also subscribe to the same MPL domain address with a 
scope vaule of 2 (link-local)

This implies?
<< an MPL forwarder MUST participate in an MPL domain identified by the 
ALL_MPL_FORWARDERS multicast address with scope value 2 (link local)>>

page 19 sec 10.1
first bullit: ..... be valid within the MPL Domain (what does that 
mean?) I thought this could be removed given the text below.

when the source address is in the AddressList of an MPL Interface 
corresponding << substitute with subscribed>> to the MPL ......

section 10.2, page 20, first bullit

This document does not define any external "events"
Remove of replace document by section, because 11.2 does.

section 10.3 page 21
last two bullits discuss Control messages and timers should these not 
be data messages and their timers?

section 11.3
as earlier, should this not be per domain?

looking forward to your reaction,

peter

Jonathan Hui (johui) schreef op 2013-01-24 17:13:
> 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

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 28 Jan 2013 15:47:33 +0000

Hi Peter,

Thanks for your review.  See below:

On Jan 28, 2013, at 3:43 AM, peter van der Stok <[email-masked]> wrote:

> In particular I appreciate the way MPL domain is defined and implemented.
> 
> After a first reading, I do have some questions about the draft. Possibly I misinterpret the text.
> 
> If I understand correctly a node can be member of several MPL domains and subscribe to as many MPL Domain addresses.
> Consequently a node can be seed to messages to more than one MPL domain.
> This implies that a node can receive messages for different MPL domains coming from the same seed?

Correct.

> If that is possible (at page 6, sec 4.1) the seed set records and the buffered message records should record information about received MPL data messages received from an MPL seed << for a given MPL-domain. >>.   within << xxx  >> my addition.

That is the intent, as Section 9 states:

   Each MPL Seed maintains a sequence number for each MPL Domain that it
   serves.

I'll be sure to make this more clear in the next revision.

> section 8 page 17.
> 
> an MPL forwarder MUST participate in an MPL domain identified by the ALL_MPL_FORWARDERS multicast address with scope value 3 (subnet local)
> For each MPL domain Address that an MPL interface subscribes to, the MPL interface MUST also subscribe to the same MPL domain address with a scope vaule of 2 (link-local)
> 
> This implies?
> << an MPL forwarder MUST participate in an MPL domain identified by the ALL_MPL_FORWARDERS multicast address with scope value 2 (link local)>>

Correct.  The intent here is to make the use of ALL_MPL_FORWARDERS the default behavior, but not required if you want to use something else.  Maybe we need to have more careful usage of "By default" and "MUST".

> page 19 sec 10.1
> first bullit: ..... be valid within the MPL Domain (what does that mean?) I thought this could be removed given the text below.

The Source Address needs to be valid within the scope zone of the MPL Domain, otherwise responses to the message (e.g. ICMP errors) cannot be returned.

> when the source address is in the AddressList of an MPL Interface corresponding << substitute with subscribed>> to the MPL ...…

The referenced text is addressing the case when IP-in-IP encapsulation is not needed.  The first bullet is intended cover the cases with and without encapsulation.

> Remove of replace document by section, because 11.2 does.

Section 10.2 specifies Trickle timer rules for MPL Data Messages while Section 11.2 specifies Trickle timer rules for MPL Control Messages.  The former does not define any external events while the latter does.

> section 10.3 page 21
> last two bullits discuss Control messages and timers should these not be data messages and their timers?

The rules on page 21 define the interaction between MPL Data Messages and MPL Control Messages.  In particular, these rules define when to start the MPL Control Message Trickle timer upon receiving an MPL Data Message.

> as earlier, should this not be per domain?

Correct.  As mentioned above, I will make this more clear in the next revision.

--
Jonathan Hui

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 30 Jan 2013 13:14:31 +0000

Thanks Jonathan and Richard for this major update to the draft. The option to allow multiple MPL Domains to co-exist is a very useful addition. On this topic some questions / remarks:

1. adding "Seed Identifier" to the section 2 Terminology could help to clarify that a single MPL Forwarder/Seed has a single Seed Identifier. This SeedID remains identical across multiple MPL Domains it participates in, right?

2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3, 11.X e.g. - any text where Seed Set is used in fact) there needs to be a separate Seed Set per MPL Domain a Forwarder participates in. Is this the solution? Peter already remarked the problem for sections 4.1/11.3.

Note that the Buffered Message Set already contains information on MPL Domain, somewhat hidden in the 'DataMessage' object in the tuple (Section 7.4). (The IPv6 Destination Address of this MPL Data Message identifies the MPL Domain). So for this data structure, there's perhaps no need to add an explicit "Domain identifier" to the tuple. But it would clarify the text to add such element to the tuple.

regards,
Esko

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

--
Jonathan Hui

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 30 Jan 2013 13:45:15 +0000

In Section 5.4, Trickle parameters are (implicitly?) forced to be equal for all MPL Domains that an MPL Forwarder participates in, because only 2 sets are supported per MPL Forwarder. Isn't this overly restrictive? Given that the MPL Domains don't interact with each other, it would be fine if a set of parameters is equal only within one and the same MPL Domain (so, that means an MPL Forwarder could have different Trickle parameters for each MPL Domain it is in.)

The final sentence of section 5.4 confirms this view, that only within-Domain parameter equality is important:
"It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the same values for the Trickle Parameters above"

Since a configuration method for Trickle parameters is out of scope of the I-D, it doesn't add any extra complexity here to allow different Trickle parameters for different MPL Domains. Also, allowing this does not seem to break the protocol in any way (unless I overlook something.)

regards,
Esko

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

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 30 Jan 2013 21:53:43 +0100

Hi Esko,

comments in line,

On 1/30/13, Dijk, Esko <[email-masked]> wrote:
> In Section 5.4, Trickle parameters are (implicitly?) forced to be equal for
> all MPL Domains that an MPL Forwarder participates in, because only 2 sets
> are supported per MPL Forwarder. Isn't this overly restrictive? Given that
> the MPL Domains don't interact with each other, it would be fine if a set of
> parameters is equal only within one and the same MPL Domain (so, that means
> an MPL Forwarder could have different Trickle parameters for each MPL Domain
> it is in.)

I think having more than one domain per forwarder makes success of
multicast complicated. If different trickel parameters for domains,
the drafts should explain more about this issue,
>
> The final sentence of section 5.4 confirms this view, that only
> within-Domain parameter equality is important:

So it is recommended, so it can be different in one domain, which
gives flexibility to the protocol in one domain,

> Since a configuration method for Trickle parameters is out of scope of the
> I-D, it doesn't add any extra complexity here to allow different Trickle
> parameters for different MPL Domains. Also, allowing this does not seem to
> break the protocol in any way (unless I overlook something.)

You cannot just make every thing out of scope to avoid complexity. If
the protocol allows same forwarder with different domains, I think it
is important at least to identify a parameter for different domains or
explain how forwards, then its config can be out of scope, but just
mentioning that the protocol can allow multi-domains per forwarder, I
think there should be an answer of how forwarder does such activity,

My thoughts. I may be missing something because not completed my review,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 30 Jan 2013 22:11:34 +0100

Hi Esko,

comments below

On 1/30/13, Dijk, Esko <[email-masked]> wrote:
> Thanks Jonathan and Richard for this major update to the draft. The option
> to allow multiple MPL Domains to co-exist is a very useful addition. On this
> topic some questions / remarks:
>
> 1. adding "Seed Identifier" to the section 2 Terminology could help to
> clarify that a single MPL Forwarder/Seed has a single Seed Identifier. This
> SeedID remains identical across multiple MPL Domains it participates in,
> right?

I think each domain has its different seedID increment, otherwise, we
are not multicast within domains, if you mix incrementing you have
considered all domains, but this is conflict with the condition that
if outside domain we use IP-in-IP encapsulation.
>
> 2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3,
> 11.X e.g. - any text where Seed Set is used in fact) there needs to be a
> separate Seed Set per MPL Domain a Forwarder participates in. Is this the
> solution? Peter already remarked the problem for sections 4.1/11.3.
>

I think that is good but still needs more, not sure :(

> Note that the Buffered Message Set already contains information on MPL
> Domain, somewhat hidden in the 'DataMessage' object in the tuple (Section
> 7.4). (The IPv6 Destination Address of this MPL Data Message identifies the
> MPL Domain). So for this data structure, there's perhaps no need to add an
> explicit "Domain identifier" to the tuple. But it would clarify the text to
> add such element to the tuple.

Why not, I think it is important parameter,

AB

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Wed, 30 Jan 2013 22:09:50 +0000

Hi Esko,

See below:

> In Section 5.4, Trickle parameters are (implicitly?) forced to be equal for all MPL Domains that an MPL Forwarder participates in, because only 2 sets are supported per MPL Forwarder. Isn't this ov…

Yes, having the same Trickle parameters for all MPL Domains is overly restrictive.

> "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the same values for the Trickle Parameters above"

Correct.  That was the intention.

> Since a configuration method for Trickle parameters is out of scope of the I-D, it doesn't add any extra complexity here to allow different Trickle parameters for different MPL Domains. Also, allow…

How about the following change:

Original from 5.4:

   Each MPL forwarder maintains a separate Trickle parameter set for MPL
   Data Message and MPL Control Message transmissions.  The Trickle
   parameters are listed below:

Change to:

   Each MPL Forwarder uses the following Trickle parameters for MPL Data Message
   and MPL Control Message transmissions.

Then keep the last sentence of 5.4 to indicate that one may use different parameters for different MPL Domains.

--
Jonathan Hui

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Wed, 30 Jan 2013 22:13:27 +0000

Hi Esko,

Thanks again for your review.  See below:

> 1. adding "Seed Identifier" to the section 2 Terminology could help to clarify that a single MPL Forwarder/Seed has a single Seed Identifier. This SeedID remains identical across multiple MPL Domai…

An MPL Forwarder may use a single Seed Identifier across all MPL Domains or different Seed Identifiers for different MPL Domains.

> 2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3, 11.X e.g. - any text where Seed Set is used in fact) there needs to be a separate Seed Set per MPL Domain a Forwarder parti…

Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple in Section 7.3.

> Note that the Buffered Message Set already contains information on MPL Domain, somewhat hidden in the 'DataMessage' object in the tuple (Section 7.4). (The IPv6 Destination Address of this MPL Data…

I can add that to the next revision.

--
Jonathan Hui

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 31 Jan 2013 08:04:07 +0000

Hi Jonathan,

agree with your suggestion. Reading again , I think the last sentence of 5.4 would be even better like this:

It is RECOMMENDED that all MPL Forwarders use the
same values within an MPL Domain for the Trickle Parameters above, as specified in
[RFC6206].

Because the original text one could interpret as follows: if an MPL Forwarder F1 uses parameter set P1 in a Domain D1; F1 SHOULD also use P1 in a Domain D2.
The above sentence does not have this interpretation.

regards,
Esko

-----Original Message-----
From: Jonathan Hui (johui) [mailto:[email-masked]] 
Sent: Wednesday 30 January 2013 23:10
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain

Hi Esko,

See below:

On Jan 30, 2013, at 5:45 AM, "Dijk, Esko" <[email-masked]> wrote:

> In Section 5.4, Trickle parameters are (implicitly?) forced to be 
> equal for all MPL Domains that an MPL Forwarder participates in, 
> because only 2 sets are supported per MPL Forwarder. Isn't this overly 
> restrictive? Given that the MPL Domains don't interact with each 
> other, it would be fine if a set of parameters is equal only within 
> one and the same MPL Domain (so, that means an MPL Forwarder could 
> have different Trickle parameters for each MPL Domain it is in.)

> Since a configuration method for Trickle parameters is out of scope of 
> the I-D, it doesn't add any extra complexity here to allow different 
> Trickle parameters for different MPL Domains. Also, allowing this does 
> not seem to break the protocol in any way (unless I overlook 
> something.)

Original from 5.4:

Change to:

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 Jan 2013 11:55:40 +0100

+1

AB

On 1/31/13, Dijk, Esko <[email-masked]> wrote:
> Because the original text one could interpret as follows: if an MPL
> Forwarder F1 uses parameter set P1 in a Domain D1; F1 SHOULD also use P1 in
> a Domain D2.
>> "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the
>> same values for the Trickle Parameters above"
>
>> should receive all packets destined to that address whether or not they
>> were received in an MPL Data Packet.
>>
>> --
>> Jonathan Hui
>>
>> 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.
>>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 Jan 2013 12:06:02 +0100

> Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple in

Yes agree the alternative is a MUST, if we want to make MPL allow
multi-domain forwarding, but still think an explaination of such
activity will be helpful for reader/implementors,

AB

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 31 Jan 2013 15:39:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui (johui)
Sent: Thursday 24 January 2013 17:14
To: [email-masked] WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 Jan 2013 17:32:27 +0100

Hi Esko, and Jonathan,

comments in line;

On 1/31/13, Dijk, Esko <[email-masked]> wrote:
> - 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?)

Why not having a default and/or initial values of both the constants
and parameters for MPL, as protocols usually have stated within its
I-D

> - just wondering if default values here would be appropriate?

Yes, I think so,

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

Agree, so we need to know initial MPL states, or define
>
> 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.

I agree with you if MPL is doing multicast, but when discussing with
authors they inform me that MPL only broadcast to interfaces, but by
using Trickel the multicast is done. However, I prefer that we can put
your suggestion as a second mode of  MPL multicast.
>   (Domain Address, MPLInterfaceSet)

don't think so,

> here so I'd expect it in the tuple too.

Yes, me too,

AB