Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

[Kerry Lynn <[e-mail]>]

Hi Michael,

On Fri, Sep 13, 2013 at 10:03 AM, Michael Richardson
<[e-mail]>wrote:

>
> Don Sturek <[e-mail]> wrote:
>     > 1) "- I have argued that to increase MPL's applicability,
>     > PROACTIVE_FORWARDING should be a per-interface and not a
> per-forwarder
>     > setting.  I can imagine, for example, a router that has both LLN and
>
> I think that the IETF *functional requirements* question is really:
>   Can an implementer make it per-interface without having an impact on
>   the implementation in other nodes?
>
> If the answer is, there is no impact, then it really doesn't matter.
> Other "ip-forwarding" settings have been described as per-router and
> generalized into per-interface many times before.
>
> Experience shows that tuning parameters are not always exposed by a
given implementation and even when they are, they are most likely left
at their default value.

My concern is that the suggested default for this parameter may lead to
suboptimal behavior on non-LLN links (by ensuring straight flooding for
some number of intervals).

Even if there is "room for interpretation" on considering this a
per-interface
parameter, the correct default needs to be specified in this draft or else a
BCP or something will be necessary.

It would be good to hear Jonathan's opinion...

I have added your comments to ticket #103, which I re-opened.
> I will close it again today --- I would appreciate comments in the mailing
> list as to whether there is anything to fix here.
>
>     > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is
>     > administratively defined and used to define the boundaries of
> multicast
>     > message dissemination by MPL."  This begs the question, why don't we
>     > just use scope = 0x04?  We probably need more discussion on if and
> how
>     > a scope 0x03 zone boundary is automatically defined (i.e. without
> human
>     > intervention) and how forwarding works for scope 0x03.  One suggested
>     > definition is that Realm-Local applies to links where a single
>     > interface may belong to multiple Link-Local scopes."
>
> I have added your text to ticket #132, and re-opened it.
> I would like to close it today.
>
> I think that we are not using scope 4 because we are able to automatically
> define the edge.  Can you suggest some text would permit MPL to
> automatically
> define the scope based upon the flood of the prefix found in the DIO PIO?
> Is that what you had in mind?
>
> Let me try to be more clear.  Perhaps I'm reading too literally, but there
seems
to be a conflict between the "administratively configured" language of this
draft
and the "automatically configured" language of Ralph's draft.  I'd just
like to
remove the contradiction (if indeed there is one).

A link-local zone boundary, for example, occurs at the router because of
the way
forwarding rules are defined in [RFC 4291, sect. 2.5.6]. If we have similar
clarity
around defining the boundary of a realm-local zone, then it seems to me the
"administratively defined" language can be removed from MPL as it relates to
realm-scope.


>     > not needed.  When using FF03::FC (defined for forwarding within a MPL
>     > Domain) then all members of the MPL Domain are forwarded a copy of
> the
>     > multicast transmission.  Section 7.2 especially makes this clear, by
>     > interface, by defining:
>
> I think that you haven't answer the question, just swapped "Real-Local
> scope"
> for "MPL Domain"
>
> That was Don's comment to my comment.


>     > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters
>     > described in section 5.5 will ultimately have to be expressed in
> units
>     > of time (either in this document or elsewhere) for a given link-layer
>     > in order to avoid the "Mismatched min" issues discussed in [RFC 6206,
>     > sect. 6.2].  The same reference states: "a protocol SHOULD set k and
>     > Imin such that Imin is at least two to three times as long as it
> takes
>     > to transmit k packets."
>
> I'm suffering from unclosed quotes here.
>

The first one is spurious.


> I don't see section 5.5 as redefining the parameters at all. It seems
> to just re-iterate them.  What is the suggested remedy here?
>
> [RFC 6206, sect. 5] says "the default value of Imin SHOULD be specified in
terms
of the worst-case latency of a link-layer transmission."  I'm simply asking
where
one goes to find, e.g., the worst-case link-layer latency of 802.15.4.
Perhaps the
remedy is to include this value in Applicability Statements as has been
agreed for
hop limit values.  I think it's important that all forwarders in a MPL
Domain agree
on this value but I was wrong in my earlier comment about the reason.  It's
not
RFC 6206, sect. 6.2] that applies, but [RFC 6206, sect. 6.3] (since Imax is
equal
to Imin).

Regards, -K-


> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>