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
|