Could you give your summary experience of implementing DFF and which network was it deployed/tested in and the summary result? I think this information will help other users and also the IESG to make future decisions :-)
AB On Mon, Feb 25, 2013 at 11:01 PM, Thomas Heide Clausen < i...@thomasclausen.org> wrote: > 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/ > >> >
