Hello folks,
I'd humbly like to encourage publication of this document.
I have been aware of DFF for a while, and we have implemented & tested the
mechanisms specified therein fairly exhaustively.
1) Testing DFF conjointly with a variety of (IETF and non-IETF)
routing, introducing
DFF yielded - in our tests - moderate to impressive performance
improvements.
2) We did not see any negative performance impacts, in our tests,
from the use of DFF.
3) During our implementation & tests, I've been providing
occasional feed-back & reviews
to the authors (clarifications, mainly), which has been well
reflected by the authors
(thanks!)
4) Having reviewed this -09 version of the specification, I find
it to be very clearly and
concisely written, and sufficiently detailed to permit
straight-forward implementation.
(Kudos!).
5) A couple of nits remain; I'll ad those to the end of this
email. They are exclusively
of editorial nature, so please do not hold up the document on
behest of those.
Concluding the above, I encourage that this document be published as RFC. It
seems to be a very good idea, which is well documented.
I understand the motivation for this document being published on the
Experimental track is, that we need more operational data. I also understand
from Ralph's emails to various WGs that he is AD sponsoring this document,
since it doesn't seem to fit anywhere, at the moment, in the IETF.
If I may be so bold, I would like to suggest that a path be identified for if
and when progressing towards std.track - it was coincidental that I came across
the document (and I'm glad that I did).
Now, my few *editorial* nits from reviewing -09:
Notation and Terminology:
There is some inconsistency in the use of colon's, dash'es or
spaces after the term and
before its definition, for example:
Foo: The definition of Foo
Bar - The definition of Bar
Foobar This specification uses Foobar
Information Base Overview:
Suggest the first sentence be something of the form:
"The information base required on each router contains a single
set, the Processed Set"
Or something, since otherwise the term "Information Base" seems
orphaned.
Also, the document later (section 6) calls it "Information Sets".
Suggest that section 6
be "Information Base" instead (or otherwise rendering the terminology
consistent
there)
Section 8, would it be worth calling out if these parameters can be
varied, and need
not be the same on all routers in a given network? I.e., if
heterogeneous parameters
across a network does not impede on interoperability?
Section 16:
"implies that any headers specific to DFF do not traverse the
boundaries
of the routing domain"
Should that not be "...specific to DFF MUST NOT traverse the
..." to be prescriptive?
That's all!
Best,
Thomas
Sent from my iPad
On 7 févr. 2013, at 14:21, The IESG <iesg-secretary(_at_)ietf(_dot_)org> wrote:
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(_at_)ietf(_dot_)org mailing lists by 2013-02-24. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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/