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

[Don Sturek <[e-mail]>]

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

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

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&st
> atus=new&status=reopened&component=trickle-mcast&group=component&col=id&col=su
> mmary&col=component&col=status&col=type&col=priority&col=milestone&order=prior
> ity
> 
> 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] <mailto:[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