Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt

Activity on this draft has been dormant for far too long.  We've resubmitted the draft with no substantive changes in attempt to move this work forward.

>From my perspective, there are a number of areas to improve on this draft:

1) Format of the HBH Option.

- The HBH Option does not currently have any version field.  I know the ZigBee folks are anxious to lock the format down, yet I don't believe we are at a point where we can (given the issues below and other issues that we have yet to find).  Finding a way to version the HBH Option will give us a path forward not only as we work on the initial specification but for future specifications as well.

- The SeedID is limited to 2 or 16 bytes.  That seems a bit constrained.  First, I have seen use cases where only a single multicast seed is used within a network, and it would be beneficial to completely elide the SeedID (with an assumed value of zero).  Second, different applications have different upper bounds on the number of seeds and/or how the SeedIDs are allocated/configured, which can dictate what size  the SeedID should actually be.  One thought is to allow the SeedID to vary between 0 and 16 bytes.

- The Sequence field is 15 bits.  I would be nice to have a Sequence field that is a multiple of 8 bits to make Serial Number Arithmetic more convenient.

- I'm aware of one technical bug with the HBH Option when trying to utilize a sliding window larger than 1.  In particular, a device processing the HBH Option does not know if the Sequence value represents the largest sequence value received by the neighboring node or an older message that it happens to be retransmitting.  Ideally, a device only resets its Trickle timer when receiving indication that a neighboring device has not yet received a message yet.  I propose adding a flag to the HBH Option that indicates whether the Sequence value is the latest.

2) Format of the ICMPv6 Message

- The format of the ICMPv6 message is not as compact as it could be.  Currently it explicitly lists each sequence value within a sliding window.  An alternative is to have a field that indicates the base and length, then use a bit vector to indicate what sequence values are buffered.

3) Use of IPv6-in-IPv6 Tunneling

- This draft was written before the RPL Option and RPL Source Route Header drafts went through extensive review.  What we learned from doing the RPL Option and Source Route Header is that IPv6-in-IPv6 encapsulation is necessary whenever adding/removing fields from an IPv6 packet en-route.  It is especially necessary when adding to ensure that we don't break Path MTU discovery.  It is convenient when removing to ensure that the original packet remains unmodified.

4) In general, a lot of work needs to be done to the draft to make the forwarder behavior rules more explicit.

Thoughts?

--
Jonathan Hui

On Jul 13, 2012, at 9:55 AM, <internet-drafts@ietf.org>
 <internet-drafts@ietf.org> 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 Forwarding Using Trickle
> 	Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
> 	Filename        : draft-ietf-roll-trickle-mcast-01.txt
> 	Pages           : 19
> 	Date            : 2012-07-13
> 
> Abstract:
>   Low power and Lossy Networks (LLNs) are typically composed of
>   resource constrained nodes communicating over links that have dynamic
>   characteristics.  Memory constraints coupled with temporal variations
>   in link connectivity makes the use of topology maintenance to support
>   IPv6 multicast challenging.  This document describes the use of
>   Trickle to efficiently forward multicast messages without the need
>   for topology maintenance.
> 
> 
> 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-01
> 
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll