Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

From: Ralph Droms <[email-masked]>
Date: Mon, 1 Apr 2013 11:13:00 -0400

I apologize for the late feedback...

Section 8 seems somewhat out of place, as well as redundant with the definition of "MPL Domain" in section 2 and the contents of section 5.1.

Multicast scope 0x03 has never been formally defined as "subnet-local".  Delete the references to "subnet-local" in sections 5.1 and 8, leaving just "scope value of 3".  Note that scope value 3 is currently defined as "reserved" in RFC 4291.  I am working on publication of an RFC that will re-define scope value 3 as "(unassigned)" so it can be used as specified in draft-ietf-roll-trickle-mcast-04.

In section 10.1, "the MPL Domain Address" is a little confusing.  Does a device belong to just a single MPL Domain, in which case it might be clearer to write "the MPL Domain Address to which the source interface belongs".  Otherwise - and I don't think I see any text in the document that explicitly constrains an interface to belonging to one MPL domain - the text should read "an MPL Domain Address to which the source interface belongs".

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 1 Apr 2013 12:08:26 -0400

Following up on my previous feedback - lacking a definition for scope 3, the document should include a definition for scope 3 as used in MPL; e.g., "all interfaces connected to a single mesh network".

- Ralph

---

From: Philip Levis <[email-masked]>
Date: Sat, 6 Apr 2013 12:23:14 -0700

On Mar 15, 2013, at 4:34 AM, JP Vasseur (jvasseur) wrote:

> Dear all,
> 
> All issues raised during the previous WG LC have been successfully addressed in draft-ietf-roll-trickle-mcast-04.
> That said, since we made several changes, this starts a 2-week WG LC that will end on March 29 at noon ET.
> Thanks.

I missed the last call, but this is a comment rather than a suggested change.

I worry a bit about the default value for DATA_MESSAGE_IMAX. Setting IMAX to the same as IMIN misses one very useful property of exponentially increasing timers, which is that they quickly find the right randomization interval under heavy congestion. The original motivation for the exponential timer in Trickle was to find the right randomization interval (much as, say, Ethernet CSMA/CD does). The challenge with having IMAX equal IMIN is that if IMIN is too small, you'll end up with a lot of congestion and link-layer collisions.

I don't think this needs any change to the document because it's just a default. If experience and practice shows that you don't want IMAX to be equal to IMIN, then I'm sure people will adjust best practices and recommendations appropriately. Just wanted to point out that keeping an eye on this might be valuable.

Phil

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Apr 2013 08:56:18 +0200

I agree with the below message proposal, and to add that I think this
I-D should define the trickle parameters not leaving them for open
test. I think IMAX should not equal IMIN [1] for this protocol, but
mostly tests will proof best. IMO, the use of trickle parameter to
make change in MPL forwarding is better than enabling transit node to
change option content [2], Could transit nodes change trickle
parameter value when that chg bit is 1, but not change option content?

[I-D>Abstract] Different Trickle parameter configurations allow MPL to
trade between dissemination latency and transmission efficiency.
[AB] The I-D does not show parameter values/relations/equations, how
can I test their consistency with the protocol?

[1] http://www.ietf.org/mail-archive/web/roll/current/msg07887.html
[2] http://www.ietf.org/mail-archive/web/roll/current/msg07880.html

Just thoughts, if not reasonable please ignore.

Regards
AB

If you think didn't understand the protocol - I already know that, you
don't need to remind me :-)

On 4/1/13, Ralph Droms <[email-masked]> wrote:
> Section 8 seems somewhat out of place, as well as redundant with the
> definition of "MPL Domain" in section 2 and the contents of section 5.1.
>
> Multicast scope 0x03 has never been formally defined as "subnet-local".
> Delete the references to "subnet-local" in sections 5.1 and 8, leaving just
> "scope value of 3".  Note that scope value 3 is currently defined as
> "reserved" in RFC 4291.  I am working on publication of an RFC that will
> re-define scope value 3 as "(unassigned)" so it can be used as specified in
> draft-ietf-roll-trickle-mcast-04.
>
> In section 10.1, "the MPL Domain Address" is a little confusing.  Does a
> device belong to just a single MPL Domain, in which case it might be clearer
> to write "the MPL Domain Address to which the source interface belongs".
> Otherwise - and I don't think I see any text in the document that explicitly
> constrains an interface to belonging to one MPL domain - the text should
> read "an MPL Domain Address to which the source interface belongs".
>
> - Ralph
>
> _______________________________________________
> Roll mailing list
> [email-masked]

On 4/1/13, Ralph Droms <[email-masked]> wrote:
> Section 8 seems somewhat out of place, as well as redundant with the
> definition of "MPL Domain" in section 2 and the contents of section 5.1.
>
> Multicast scope 0x03 has never been formally defined as "subnet-local".
> Delete the references to "subnet-local" in sections 5.1 and 8, leaving just
> "scope value of 3".  Note that scope value 3 is currently defined as
> "reserved" in RFC 4291.  I am working on publication of an RFC that will
> re-define scope value 3 as "(unassigned)" so it can be used as specified in
> draft-ietf-roll-trickle-mcast-04.
>
> In section 10.1, "the MPL Domain Address" is a little confusing.  Does a
> device belong to just a single MPL Domain, in which case it might be clearer
> to write "the MPL Domain Address to which the source interface belongs".
> Otherwise - and I don't think I see any text in the document that explicitly
> constrains an interface to belonging to one MPL domain - the text should
> read "an MPL Domain Address to which the source interface belongs".
>
> - Ralph
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>