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

[<[e-mail]>]

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]
Cell:      [phone]
Email:   [e-mail]<mailto:[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.