Bruno, Lots of thanks for a prompt response. I have looked up the -05 version, and it addresses all concerns I've raised in my review.
Regards, Sasha On May 2, 2017 12:09, <[email protected]> wrote: > Hi Sasha, > > > > Many thanks for your careful review. > > Your comments have been constructive, useful and helped clarifying the > draft. Thanks for this. > > > > We have updated the draft as per your comments. We believe that -05 > address all your comments. If it does not, please comment back. > > Draft: https://tools.ietf.org/html/draft-ietf-rtgwg-backoff-algo-05 > > Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtgwg- > backoff-algo-05.txt > > > > > > --Bruno, on behalf of all authors. > > > > *From:* rtg-dir [mailto:[email protected]] *On Behalf Of *Alexander > Vainshtein > *Sent:* Thursday, April 27, 2017 2:25 PM > *To:* [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected]; Jonathan Hardwick ( > [email protected]); [email protected] > *Subject:* [RTG-DIR] Early RTG-DIR review of > draft-ietf-rtgwg-backoff-algo-04 > > > > Hello, > > > > I have been selected as the Routing Directorate as an early reviewer for > this draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG review, > and sometimes on special request. In this case an early review has been > requested by Jeff Tantsura – one of the co-chairs of the RTGWG. > > The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > *Document*: draft-ietf-rtgwg-backoff-algo-04 > > *Reviewer*: Alexander (“Sasha”) Vainshtein > > *Review Date*: 27-Apr-17 > > *IETF LC End Date*: N/A > > *Intended Status*: Standards Track > > > > *Summary*: > > I have some minor concerns about this document that, from my POV, should > be resolved before publication. > > > > *Comments*: > > The draft is very well written, and, with one notable exception, easy to > understand. > > It represents an attempt to standardize one aspect of behavior of > link-state routing protocols: delay between the first IGP event that > triggers new SPF computation and the SPF calculation. Until now, this been > left for the implementers to play with freely. The resulting differences > have been known for quite some time to result in some case in transient > micro-loops. > > > > The resolution proposed in this draft includes a well-defined FSM and a > full set of tunable parameters (timers) used in this FSM. > > The range and granularity of all the tunable parameters are explicitly > defined in the document so that the operator would be able to tune its > network to use exactly the same SPF delay algorithm with exactly the same > parameters. (The default values are not defined because one size does not > fit all in this case). > > > > It should be noticed that the draft does not intend to provide a > comprehensive solution of the micro-loop problems. > > Rather, it provides a common baseline upon which specific solutions for > these problems can be built (e.g., see draft-ietf-rtgwg-uloop-delay > <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/?include_text=1> > ). > > > > *Major Issues*: None found. > > > > *Minor Issues*: > > 1. The exception to good readability of the draft refers to the > term “*proximate* failures/IGP events” that appears 4 times in the draft. > English is not my mother tongue, and the reference > <https://www.merriam-webster.com/thesaurus/proximate> I’ve looked up did > not help much. “Temporally close” (or something along these lines) looks > like a suitable alternative. (Does this comment run strictly against the > recommendation for the RTG-DIR reviewers “to avoid raising esoteric > questions of English usage”?) > > 2. Section 5 mentions starting the SPF_TIMER (with one of the 3 > values defined for it) as part of the response to some FSM events if it was > not already running - but *it does not specify what happens when this > timer expires*. I assume that its expiration leaves the FSM in its > current state and results in running the SPF computation – if this is > correct, it would be nice to say that explicitly. > > 3. Section 7 recommends that, in order to mitigate micro-loop > problems using the proposed algorithm, “all routers in the IGP domain, or > at least all the routers in the same area/level, have exactly the same > configured values” of the relevant timers . However, the draft does not > specify whether these timers should be configured just at the protocol > instance level or also at the level of each specific area/level. From my > POV, the *granularity of configuration* should be defined in this draft – > one way or another. > > 4. The latest versions of the YANG data model drafts for IS-IS and > OSPF already define the timers introduced in this draft. But *there are > no references to these drafts in the document*. From my POV such > references (Informational and therefore non-blocking) would be useful for > the readers, and I suggest to add them. > > 5. I have some concerns regarding *incremental introduction and > activation of the proposed algorithm*. The operator that runs a > well-tuned network may experience transient problems when some of its > routers are already upgraded and use the proposed back-off algorithm while > some others still cannot do that. Some text explaining potential issues in > this scenario and, if possible, their mitigation, would be most helpful. > > 6. The explanatory text in the draft seems to strongly suggest > that *SPF_INITIAL_DELAY <= SPF_SHORT_DELAY <= SPF_LONG_DELAY *– but > this is not formalized as a requirement anywhere in the text. From my POV > satisfying this relationship should be RECOMMENDED to the operators. > > > > *NITS*: > > 1. Section 3 lists 3 possible values for the SPF_DELAY variable > called INITIAL_SPF_DELAY, SHORT SPF_DELAY and LONG_SPF_DELAY. Then, in the > last para, it refers to *a previously undefined value, INITIAL_WAIT*. > This is an obvious typo and should be replaced with INITIAL_SPF_DELAY > > 2. One of the parameters of the algorithm is called > *HOLD_DOWN_INTERVAL* (in Section 3 and Section 6) vs. *HOLDDOWN_INTERVAL* > in Section 5. This also looks like an obvious typo, and the same name > should be used across the document. > > > > I have discussed my concerns about the draft with the authors who have > been most cooperative. > > I believe that we have reached an agreement on acceptable resolution of > all concerns listed above. > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: [email protected] > > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > _________________________________________________________________________________________________________________________ > > 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
