Note, I am not an author of this particular document, but I've got some experimental and operational experience with it - having implemented DFF and built deployments including it.
On 25 févr. 2013, at 06:59, Abdussalam Baryun <abdussalambar...@gmail.com> wrote: > Reply to your request dated 07/02/2013 > Draft Reviewed By: Abdussalam Baryun (AB) Dated: 24/02/2013 > > Reviewer Comment #AB3: Related to Processing and interaction with others. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > In section 11 > AB>The DFF MUST contain the next hop of RIB, but in section 5 it mentions MAY. > AB>suggest> please amend both should be same requirement for protocol. > > AB> the way it determines the next hop does not show that this > protocol is sensitive to other parameters in the RIB, it just takes > the addresses without considering the routing protocol strategy in its > RIB. IMHO, this may make the DFF make mistakes in taking the right > next hop What you say above doesn't make any sense. DFF considers the content of the RIB, among other information, and recommends following the "next hop" indicated in the RIB first - i.e., DFF explicitly takes the "right next hop" according to "the routing protocol strategy" as expressed in the RIB. Of course, if you happen to know more about what the routing protocol does (e.g., have access to internal state of the routing protocol), you could do something more clever - DFF doesn't prohibit that either, so I think that the authors struck a nice middle ground here. > Section 12 > AB> is not understood, it seems a general not specific, I suggest more > explaining how this interaction with routing protocol is occured? It seems pretty clear to me what's expected here: signal to the routing protocol (and then, whatever the routing protocol does with that signal depends on what routing protocol it is). It's, IMO, hard to be any clearer here. > Section 13 > AB> who creates the sequence number is it the DFF or the routing > protocol. It seems the DFF, so please specify how it will > maintain/save such sequence number in this section. > AB> suggest this section to be : DFF Sequence Number. > [befuddled] Section 13 is already very clear on this. > Section 14 > AB> again do you mean that both modes can work together. I don't think > that you mean that, so you should specify that each routing domain > MUST have one mode, and specify how to maintain that mode in such > protocol. Eh, here too I am befuddled. I do not see anywhere that the authors indicate that the two "modes can work together" - actually, the document doesn't talk about "modes" at all, and the protocol doesn't have "modes". Rather, this section describes how one would use DFF, depending on what other choices are made in the network deployment. In other words: DFF doesn't specify a "mode", but rather says "if your network is of this kind, then do like that". So, I think that there's strictly nothing to change here, no need to maintain a "mode" etc. > Overall> about processing> > AB> this protocol needs to be discussed more how it will interact with > the routing protocols in MANET, 6LowPAN, ROLL. The documents ignore > alot of work done in the IETF which is not fiting the general > applicability it is offering. No, it doesn't. DFF is completely orthogonal to routing protocols DFF can (logically) layer below any routing protocol, without modifications to that routing protocol. DFF can use a RIB and can provide signals to a routing protocol (or not - if the routing protocol doesn't want them) Thomas > +++++++++++++The END+++++++++++ > > Regards > AB > --------------------------------------------------------------------------------------- > This message and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > This message is in compliance with the IETF regulations. > --------------------------------------------------------------------------------------- > > >>> On 2/7/13, The IESG <iesg-secret...@ietf.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@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may >>>> be >>>> sent to i...@ietf.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/ >>
