Subject: Re: [Roll] Seed Set use across MPL Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 4 Feb 2013 13:17:03 +0000

> Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple in Section 7.3.
That sounds also good to me. For some of the text on "Seed Set" the notion of MPL Domain needs to be included, in that case.
For example in 10.3
	"If a Seed Set entry exists for the MPL Seed ..." 
of course a Seed Set entry for the MPL Seed *for a specific MPL Domain* should be checked. (Since a Seed ID could be in use across multiple Domains, only one of which is to be considered in the processing indicated in the quoted text.)

Esko

-----Original Message-----
From: Jonathan Hui (johui) [mailto:[email-masked]] 
Sent: Wednesday 30 January 2013 23:13
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: Seed Set use across MPL Domains (was: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

Hi Esko,

Thanks again for your review.  See below:

On Jan 30, 2013, at 5:14 AM, "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?

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 participates in. Is this the solution? Peter already remarked the problem for sections 4.1/11.3.

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

I can add that to the next revision.

--
Jonathan Hui

> 
> 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
> 
> 
> 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:
> 
>> 
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> 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.
>

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 4 Feb 2013 13:34:39 +0000

Hello,

> 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
That's possible, if we have some 'typical' use case for which reasonable Trickle parameters are known.
On second thought: in practice the SEED_SET_LIFETIME selection may be linked to the Imin/Imax selection. So giving a default for only SEED_SET_LIFETIME may not work. E.g. SEED_SET_LIFETIME = 100 ms, and Imin=5 sec., would not really work well I assume.

regards,
Esko

-----Original Message-----
From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Thursday 31 January 2013 17:32
To: Dijk, Esko
Cc: Jonathan Hui (johui); [email-masked] WG
Subject: Re: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

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

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

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.
>   (Interface ID, AddressSet)

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.
>
> Section 7.2
> - Shouldn't the Domain Address be the first component of the MPL
> Domain Tuple?
>   (Domain Address, MPLInterfaceSet)

don't think so,

> The present text already suggests of course that Domain Address is
> stored here so I'd expect it in the tuple too.

Yes, me too,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Feb 2013 17:49:35 +0000

Hi Esko,
comments inline,
On Mon, Feb 4, 2013 at 1:34 PM, Dijk, Esko <[email-masked]> wrote:

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

My concerns are the parameters mentioned in the draft, and the questions of
any reader or implementor are 1) what will be my start values for these
parameter. 2) Is there any recommendations from the authors or the group?

> On second thought: in practice the SEED_SET_LIFETIME selection may be
> linked to the Imin/Imax selection. So giving a default for only
> SEED_SET_LIFETIME may not work. E.g. SEED_SET_LIFETIME = 100 ms, and Imin=5
> sec., would not really work well I assume.
>

There was one test for the MPL and I would like to know what was their
parameters' values if possible, however, if not giving by the draft
any example or default for parameters, should that mean that it does not
matter any value will work.

AB