Mike, Many thanks for your review and very useful comments. We agree with them and we’ll obviously take them into account in the next revision. Please see 2 comments inline. [Bruno]
From: rtgwg [mailto:[email protected]] On Behalf Of Mike Shand Sent: Thursday, May 07, 2015 12:15 PM To: [email protected] Cc: [email protected] Subject: Mail regarding draft-decraene-rtgwg-backoff-algo I have been assigned as Routing Directorate QA reviewer for this document. The following web page contains a briefing on the QA process. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa The document is clear and concise and succinctly describes a proposed standardised SPF backoff algorithm. This seems a useful step forward. The algorithm is not overly complex. While suggested values for the various parameters are given, what is not clear to me is whether the intention is that these (or at least an agreed set) of these values are intended to be standardised as well as the algorithm. It would seem that different values might be suitable for different networks, but presumably the intention is that all the routers in a particular network SHOULD have the same values. Some discussion of this would be helpful. [Bruno] Good point. Acee had already pointed this to me and my local version has a new paragraph about this. The paragraph is a bit too long to copy past here, but I think we are in sync. In short: - “This document does not propose default values for the parameters because these values are expected to be context dependent. Implementations are free to propose their own default values.” - timers must be configurable. - the section discuss some aspects that should be taken into account when setting such values. I assume that "rib computation time" is the time that a RIB computation is to be (or was) STARTED? Obviously the FIB will not be updated for some time after this, in some cases for quite a long time after this! Does this delay need to be taken into account? [Bruno] Definitely a valid question. So far the document takes the simple option of only considering SPF delay and not considering FIB update. That’s much simpler, especially considering that we are not seeking to remove all micro-loops, but trying to avoid unnecessary contributions due to different SPF delays. Note that the timers being configurable, one could (try to) play with different timer value to (partially) take into account different in FIB updates durations. Thanks again, /Bruno I appreciate that in many cases it is difficult to ascertain reliably exactly when a FIB update has been completed. In reading the document I spotted the following nits. Intro para 3 "some back-off algorithm have" presumably algorithms and "to enforce that all routers triggers their SPF presumably trigger Bottom of page 3 "SPF_DELAY back to INITAL_WAIT. e.g. 5 seconds." obviously should be INITIAL_WAIT 4. Principle of SPG algorithm 3rd para "and the while waiting for its stability," "and while waiting" would be better. 6 Impact on micro-loops "FIB are installed" The FIB is installed or FIBs are installed Mike _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
