Jiazi, thank you very much for your review. I am glad that the latest revision addresses your previous concerns. As to your suggestion, I agree that having some constraints is useful. To your suggestion considering the number of routers in the DFF domain, I think this would be difficult to use normative language, as the number of routers may not be known (e.g. when not using a proactive routing protocol). DFF does not mandate to have this information at hand. Another example of setting the value would be to depend on the expected path length (e.g. based on information from the routing protocol). It may, e.g., be reasonable to set a MAX_HOP_LIMIT that is, say, 50% longer than the distance in hops indicated by a routing protocol. I think that it would be very interesting to find out appropriate values as experiments for the protocol (given that the document is Experimental). How about adding the following text to MAX_HOP_LIMIT: ----- added text ------ Finding optimal values for MAX_HOP_LIMIT is part of experiments that can be performed with the protocol proposed in this document. For example, one possible experiment would be to set MAX_HOP_LIMIT to different factors of the expected path length to the destination in number of hops if provided by a routing protocol. --------------------- Best regards Ulrich On Mon, Feb 11, 2013 at 10:47 AM, Jiazi Yi <ietf@xxxxxxxxxxx> wrote: > > Dear all, > > I had a through review of dff-07 with detailed comments. In the new revision, my questions and concerns have been properly addressed -- thanks to all the authors. > > The mechanism is well documented, and I have tested the protocol in the scenarios described in the applicability statement, which brings interesting performance improvement. > > Therefore, I would like to encourage the publication of it. > > Just one more comment: > > o In section 8 Protocol Parameters, it would be better to have some limitations or recommendations for those parameters. For P_HOLD_TIME, I think it's OK by saying "at least be MAX_HOP_LIMIT times the expected time to send a Packet to a router on the same link.". It would be event better to give such limitations to MAX_HOP_LIMIT. A regular value related to NET_DIAMETER won't work, because DFF can have significant higher hop count and result in packet drop. Maybe we can have something like "it MUST NOT be higher than the number of routers in the DFF routing domain. If the number of routers is greater than 255, it is set to 255 by default." > > best > > Jiazi > > > On Feb 8, 2013, at 7:22 PM, Ralph Droms <rdroms.ietf@xxxxxxxxx> wrote: > > > draft-cardenas-dff is under consideration for publication as an AD-sponsored individual submission Experimental RFC. I agreed to sponsor it for publication because it doesn't really fit in any existing working groups and the requested publication status is Experimental. As part of the review process, the document is in a 2-week IETF last call. The last call announcement is included below. To ensure the quality of the document, it would be helpful to get reviews from manet WG participants (posted to the ietf@xxxxxxxx discussion list). > > > > Thanks. > > > > - Ralph > > > > > > ===== > > > > > > The IESG has received a request from an individual submitter to consider > > the following document: > > - 'Depth-First Forwarding in Unreliable Networks (DFF)' > > <draft-cardenas-dff-09.txt> as Experimental RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@xxxxxxxx mailing lists by 2013-02-24. Exceptionally, comments may be > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document specifies the "Depth-First Forwarding" (DFF) protocol > > for IPv6 networks, a data forwarding mechanism that can increase > > reliability of data delivery in networks with dynamic topology and/or > > lossy links. The protocol operates entirely on the forwarding plane, > > but may interact with the routing plane. DFF forwards data packets > > using a mechanism similar to a "depth-first search" for the > > destination of a packet. The routing plane may be informed of > > failures to deliver a packet or loops. This document specifies the > > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > > addition also for LoWPAN "mesh-under" networks (as specified in > > RFC4944). > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-cardenas-dff/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1645/ > > http://datatracker.ietf.org/ipr/1646/ > > > > > > _______________________________________________ > > manet mailing list > > manet@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/manet >