Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops
draft-ietf-rtgwg-spf-uloop-pb-statement-10

Thank you for writing this -- I found it a really interesting and useful read, and so I'm balloting Yes.

Thank you for this clear and thoughtful document!  I only have nit-level
editorial suggestions, which you should feel free to accept or ignore as
you desire.

Section 1

   For non standardized timers, implementations are free to implement
   them in any way.  For some standardized timers, we can also see that
   rather than using static configurable values for such timer,
   implementations may offer dynamically adjusted timers to help
   controlling the churn.

nit: "help control"

   This document will present why it sounds important for service
   providers to have consistent implementations of Link State protocols
   across vendors.  [...]

nit: "why it sounds important" has a connotation that it's not actually
important, which I don't think is the position of anyone here.  So maybe
"why it is important" or "will present reasons for service providers to".

   [RFC8405] defines a solution that satisfies this problem statement
   and this document captures the reasoning of the provided solution.

nit: maybe this is just my personal background, but I am used to seeing
"satisfy" used with requirements but "address" with problems.  It was also
unclear to me that 8405 is a complete solution; if I remember correctly it
is only claiming to reduce the number of micro-loops and not to completely
eliminate them.  In that case, maybe "partially addresses" is better.

Section 2

   o  the delay of failure notification: the more E is advised of the
      failure later than S, the more a micro-loop may have a chance to
      appear.

nit: I'd suggest "the greater the time gap between E and S being advised of
the failure"

   o  the SPF computation time: mostly a matter of CPU power and
      optimizations like incremental SPF.  If S computes its SPF faster
      than E, there is a chance for a micro-loop to appear.  CPUs are
      today fast enough to consider SPF computation time as negligible
      (on the order of milliseconds in a large network).

side note: this makes me realize my own ignorance -- about how long would a
micro-loop typically be active for?  Also milliseconds?

   o  the SPF computation order: an SPF trigger can be common to
      multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for

nit: My first time reading this I misread it to mean scaling or distance,
as in "first-order"/"second-order"/etc.  Perhaps it's clearer to use
"ordering".

   plays a significant role.  As the number of IGP events increase, the
   delta between SPF delay values used by routers becomes significant
   and the major part (especially when one router increases its timer

nit: I offer "dominating factor" as a potential alternative for "major
part".

   However, for micro-loops, what's matter is not the total time, but

nit: "what matters"

Section 3

   may only run IP reachability computation instead) if the advertised

nit: "an IP reachability computation"

Section 4.2

Isn't the base of the exponent also a parameter that needs to be specified
(or is 2 the universally chosen base)?

Section 7

I suppose that things like "micro-loops can cause out-of-order delivery"
are universally-enough known that we don't need to be tempted to abuse this
document as a general dumping ground for security-relevant statements about
micro-loops.

Thanks for doing!