Re: Last Call: <draft-cardenas-dff-09.txt> (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC

[Thomas Heide Clausen <[e-mail]>]

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 <[e-mail]> 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
> [e-mail] mailing lists by 2013-02-24. Exceptionally, comments may be
> sent to [e-mail] 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/
> 
> 
>