Re: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain

[Abdussalam Baryun <[e-mail]>]

+1

AB

On 1/31/13, Dijk, Esko <[e-mail]> wrote:
> 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:[e-mail]]
> Sent: Wednesday 30 January 2013 23:10
> To: Dijk, Esko
> Cc: [e-mail] 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" <[e-mail]> 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.)
>
> Yes, having the same Trickle parameters for all MPL Domains is overly
> restrictive.
>
>> 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"
>
> 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, allowing this does
>> not seem to break the protocol in any way (unless I overlook
>> something.)
>
> 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
>
>>
>> regards,
>> Esko
>>
>> -----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.
>>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>