Re: [RTG-DIR] Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04

[Alexander Vainshtein <[e-mail]>]

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, <[e-mail]> 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:[e-mail]] *On Behalf Of *Alexander
> Vainshtein
> *Sent:* Thursday, April 27, 2017 2:25 PM
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Jonathan Hardwick (
> [e-mail]); [e-mail]
> *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: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
>
> ____________________________________________________________
> _______________
>
> 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.
>
>