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

[Kerry Lynn <[e-mail]>]

Hi Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <[e-mail]> wrote:

> I don't agree with the proposed technical changes below, specifically:
> 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 traditional interfaces and
> proactive
>   forwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone
>   boundaries cut through nodes, not links."  Suggested wording in section
> 5.4
>   could be "PROACTIVE_FORWARDING has a default value of TRUE on links
>   where Realm-Local scope is defined, and FALSE otherwise."
>
>     Given how forwarding is defined in the draft, I don't see how the
> scenario above is possible unless the links on the "traditional interfaces"
> happen to be members of the same MPL Domain as the LLN
>

I am looking at section 3, Applicability Statement, which says: "This
protocol
may also be used in environments where only a subset of links are considered
Low-Power and Lossy links."  The change I proposed is minimal and would
improve dynamic protocol behavior on non-LLN links.

>
> 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."
>
>       This argument was made some time ago and rejected.   The purpose in
> defining and using a realm scoped address is to allow for automatic
> definition.
>

I think I'm just confused about the desire for automatic definition of the
Realm-Local
scope and the several statements in the draft that it's administratively
configured.
Asking as an implementer, how do I determine whether an interface is in a
Realm-
Local zone?  Is it particular to LLN links?

I'm not sure whether the draft is intending to reserve the ability to
configure which
links are in the MPLInterfaceSet.  However it seems that Realm-Local scope,
like
other multicast scopes, must have a consistent definition for any and all
protocols
that use it.


> The forwarding definition in the Trickle Multicast draft is by MPL Domain
> so the definition at the end of the paragraph above is 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:
>
>    MPLInterfaceSet  - a set of MPL Interfaces that subscribe to the MPL
>           Domain Address that identifies the MPL Domain.
>
>
> 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."
>
>      Since we are using these parameters as defined in RFC 6206 (Trickle
> Algorithm) we should not attempt to redefine them here in this draft.
>

Do the terms "expected link-layer latency" and "worst-case link-layer
latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have commonly defined definitions, e.g. in 802.15.4?  If so,
what are they?  I couldn't seem to determine this from the 802.15.4 spec.

Thanks, -K-


>
> Don
>
>
> From: Kerry Lynn <[e-mail]>
> Reply-To: Routing Over Low power and Lossy networks <[e-mail]>
> Date: Friday, September 13, 2013 5:10 AM
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] WGLC - Working Group Last Call -
> draft-ietf-roll-trickle-mcast-05
>
> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <[e-mail]>wrote:
>
>>
>> A number of issues were raised this past spring by IESG and other
>> reviewers
>> on draft-ietf-roll-trickle-mcast.  You can review them using the custom
>> query:
>>
>>
>> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority
>>
>> The chairs, Document Shephard and Document Authors believe that current
>> issues are closed in the -05 revision at:
>>        https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
>> A diff is available at:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05
>>
>> We are starting another WG Last Call.
>> It will run until Friday 2013-09-13 at 9am EST.
>>
>> Please read the document.  Do you concur that it is done?
>> Please post any and all comments.
>>
>
> The draft is looking good, but I have a few comments.
>
> Editorial:
>
> - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message
> message"
>   is redundant and should be "MPL Data Message".
>
> - In the last paragraph of section 4.3 the phrase "a new MPL Data messages"
>   should be "a new MPL Data Message".
>
> - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to
> 14.2.
>
>
> Technical:
>
> - 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 traditional interfaces and
> proactive
>   forwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone
>   boundaries cut through nodes, not links."  Suggested wording in section
> 5.4
>   could be "PROACTIVE_FORWARDING has a default value of TRUE on links
>   where Realm-Local scope is defined, and FALSE otherwise."
>
> - 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.
>
> - 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."
>
> Regards, -K-
>
>
>
>> If there is something you do not like, please provide a suggestion (a
>> diff)
>> about what to fix.
>>
>> Thank you.
>>
>> Michael and JP.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
> _______________________________________________ Roll mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>